Documento in formato ppt 669Kb

La gestione dei flussi documentali dal Regio
Decreto n°35 del 1900
al DPR n.428 del 20.12.10.1998
Antonio Massari
Autorita’ per l’Informatica nella Pubblica
Amministrazione
[email protected]
0685264363
Normativa tecnica di riferimento
2
Gestione documentale: possibili scenari
• quattro variabili rilevanti:
– 1. Flusso in entrata
– 2. Sistema interno di
gestione
– 3. Sistema di archiviazione
– 4. Flusso in uscita
1
2
4
3
3
Flusso entrata/uscita
• Flusso cartaceo
• Flusso informatico
– Solo con firma digitale
• conforme al 513
• di altro tipo
– Senza firma digitale, con altri
accorgimenti per garantire
autenticita’, integrita’ ecc.
4
Sistema interno di gestione
• Solo cartaceo
• Totalmente informatico
• Misto
– Dati di controllo informatici, ma flusso manuale
– Dati di controllo informatici e flusso parzialmente
informatico
attività B
attività F
attività A
attività C
attività D
attività E
attività H
attività G
5
Sistema di archiviazione
• Solo cartaceo
• Cartaceo per fini legali / Informatico per
accesso
• Cartaceo ed informatico per fini legali /
informatico per accesso
• Solo Informatico
3
6
Quale soluzione?
•
Nessuna “pallottola d’argento” non ci saranno soluzioni
fotocopia imposte per legge
•
Necessario affrontare innanzitutto i problemi organizzativi
•
Fondamentale promuovere il riuso delle esperienze
– favorendo lo scambio di informazioni prodotte durante il ciclo
di vita di un sistema di protocollo informatico
– indirizzando le amministrazioni verso soluzioni modulari ed
aperte creando, così, favorevoli condizioni per una risposta
competitiva del mercato
7
Programma di attività avviato da AIPA
8
Programma di attività avviato da AIPA (1/2)
• Gruppo di lavoro per la stesura delle regole tecniche
del DPR 428/98
– luglio 99 bozza su web, ottobre-novembre entrata in vigore
• Sezione specifica sul protocollo nel piano triennale
– in corso di svolgimento
• Istituzione di un organismo di coordinamento
– attivo da giugno per un periodo di almeno un anno
• Avvio di un progetto di formazione
– attualmente in fase di progettazione, erogazione corsi
prevista entro il 2000
9
Programma di attività avviato da AIPA (2/2)
• Documento di indirizzo: “GEDOC 2”
– metodologia per la conduzione degli studi di fattibilità e la
progettazione
– classificazione dei sistemi e delle possibili realtà
amministrative
– quadro unitario della tematica relativa a: protocollo, documento
informatico, archiviazione ottica
– valutazione prodotti e piattaforme
– entro il 1999
• Realizzazione di un Web Server per la diffusione delle
informazioni
– attualmente operativo in forma preliminare, entro ottobre in
forma estesa
10
I Progetti
Pianificazione
Valutazione
Analisi rischio
Progetti
Modello evolutivo a “spirale”
11
Progetti finanziati su fondi RUPA (L.400-96)
• Dipartimento della Funzione Pubblica
– informatizzazione di base,
– gestione semi-automatica del routing dei documenti,
• Ministero dell’Interno
– informatizzazione del protocollo delle prefetture
– alta ripetibilita’ e diffusione
• Ministero delle Finanze
– protocollo “federato”, segnatura strutturata
• Ministero del Tesoro
– connessione con il workflow
• AIPA
– realizzazione di un sistema avanzato
12
DPR 428/98
13
Principi generali del DPR 428/98
le indicazioni fondamentali
Aggiornamento della normativa esistente
(RD n.35 1900) facendo salvi i principi
generali e cogliendo le opportunità che le
vengono offerte dalle nuove tecnologie
(documento elettronico, DBMS, reti).
Esplicita indicazione di migliorare
l’efficienza dei processi di gestione
documentale attraverso l’eliminazione
della frammentazione dei sistemi di
protocollo.
Collegare il sistema di protocollo
alla gestione dei flussi
documentali
14
Principi generali del DPR 428/98
cosa si intende per “sistema di protocollo informatico”
• Nucleo minimo obbligatorio per legge
– tenuta di un registro informatico che
tiene traccia degli eventi di transito di
documenti
– sistema di certificazione
• Attorno al nucleo minimo molteplici
possibilità di estensione, o meglio,
integrazione (non obbligatorie)
– procedimenti, controllo di gestione...
Protocollo
in entrata
Protocollo
in uscita
Amministrazione o
Area Organizzativa Omogenea
15
DPR 428/98
“nucleo minimo”
16
Nucleo minimo come servizio di
certificazione
• L'inserimento di un elemento nel registro di protocollo corrisponde
alla assunzione delle seguenti responsabilità
– certificare l'esistenza del documento almeno a partire da una
certa data. Questo significa:
• nel caso di documenti ricevuti, l'amministrazione non può negare, a fronte
della richiesta di esibizione del contenuto di una registrazione, che un
documento sia esistito,
• nel caso di documenti prodotti dall'amministrazione, la stessa può
"provare" che un proprio documento è stato formato prima di una certa
data;
– nel caso di documenti ricevuti, certificare il fatto che il documento
è entrato nei confini dell'amministrazione e che sarà trattato.
17
Approccio del DPR
• Dettare le regole organizzative interne e le caratteristiche dei
sistemi tecnologici che ciascuna amministrazione deve adottare
per essere in grado di fornire i servizi di certificazione.
– Manutenzione di un registro informatico,
– Istituzione di un servizio e nomina di un responsabile,
– Assicurare che le modalità di registrazione di protocollo e segnatura
avvengano secondo certi criteri
– Gestione delle emergenze secondo alcune modalità
18
Registrazione e Segnatura di protocollo
Firma
Numero
1224
1225
1226
Oggetto Data
data, progressivo di protocollo,
oggetto, mittente o destinatario,
impronta
Firma
data, progressivo di
protocollo, indicazione AOO
19
Registrazione di protocollo
•
(Art. 4 co 1) “La registrazione di protocollo per ogni documento ricevuto o
spedito dalle Pubbliche amministrazioni è effettuata mediante la
memorizzazione in un archivio informatico delle seguenti informazioni:
• numero di protocollo del documento
• data di registrazione
• mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatari
per i documenti spediti,;
• oggetto del documento,
• l’impronta del documento informatico”
20
Segnatura di protocollo
•
(Art.1 lett. d) “La segnatura di protocollo è l’apposizione o l'associazione,
all'originale del documento, in forma permanente e non modificabile, delle
informazioni riguardanti il documento stesso”
•
(Art. 6 co. 1) “Le informazioni da apporre od associare ad ogni documento
attraverso l’operazione di segnatura di protocollo consentono di individuare
ciascun documento in modo inequivocabile. Le informazioni minime
previste sono:
• il numero di protocollo;
• la data di protocollo;
• l'identificazione in forma sintetica dell’amministrazione o dell’area
organizzativa omogenea.”
21
Modalità di esecuzione delle operazioni di registrazione e
segnatura
•
(Art. 4 co. 3) “L'assegnazione delle informazioni nelle operazioni di registrazione di
protocollo è effettuata dal sistema in unica soluzione, con esclusione di interventi
intermedi, anche indiretti, da parte dell’operatore, garantendo la completezza dell’intera
operazione di modifica o registrazione dei dati”
•
(Art. 6 co. 2) “L’operazione di segnatura di protocollo va effettuata
contemporaneamente all'operazione di registrazione di protocollo”
22
Principi generali del DPR 428/98
caratteristiche del nucleo minimo
possibilità di registrare
indifferentemente documenti
elettronici o cartacei
possibilità di automazione (parziale o totale)
dei processi di registrazione/segnatura
nel caso di scambi documentali tra PA
identificazione universale del
documento
possibilità di abolizione del registro cartaceo
Tutti questi aspetti saranno dettagliati nelle regole tecniche previste
23
Scambio di documenti elettronici e di informazioni
strutturate tra amministrazioni
•
(Art. 6 co. 4) “Quando il documento è indirizzato ad altre amministrazioni ed è formato
e trasmesso con strumenti informatici, la segnatura di protocollo può includere tutte
le informazioni registrate sul documento. L'amministrazione che riceve il documento
informatico può utilizzare tali informazioni per automatizzare le operazioni di
registrazione di protocollo del documento ricevuto”
24
Scambio di un documento cartaceo
•
Formazione
•
Firma
Firma
•
Registrazione
•
Segnatura
Firma
Firma
•
Segnatura
•
Registrazione
•
Autenticazione
Firma
Firma
Firma
25
Scambio di un documento elettronico
•
Formazione
•
Firma
•
Trattamento
•
Registrazione
•
Registrazione
•
Segnatura
•
Autenticazione
26
“GEDOC 2” Architetture dei sistemi
informatici
Possibili scenari
• Sono possibili varie collocazioni del sistema di protocollo
nell’ambito del sistema informatico dell’amministrazione:
–
–
–
–
Scenario minimo
Scenario “monolitico”
Scenario modulare
Scenario intermedio
28
Scenario minimo
• Il sistema di protocollo informatico è l’unico sistema automatizzato
dell’amministrazione (o dell’area organizzativa omogenea) che tratti in
modo strutturato informazioni su documenti.
• Non esistono altri strumenti informatici al di fuori di un sistema base per
l’automazione del registro protocollo
• Casi in cui ciò accade
– ci sono vincoli sul grado di informatizzazione o il livello culturale informatico del
personale
– l’AOO tratta un volume estremamente basso di documenti, e quindi non
sussistono le condizioni per rendere economicamente conveniente l’utilizzo di
ulteriori strumenti informatici
29
Scenario “monolitico”
• Il sistema di protocollo viene realizzato fin dall’inizio come un sistema in
grado di gestire, oltre ai dati necessari alla tenuta del registro di
protocollo, anche tipi di informazioni legati al trattamento dei processi
svolti dall’amministrazione, come “l’assegnatario della pratica”, “il
fascicolo” o “il procedimento amministrativo”
• Una unica applicazione “monolitica” che gestisce in modo più o meno
efficace risorse informative che hanno una valenza generale, estesa
anche al di fuori del protocollo:
–
–
–
–
–
struttura organizzativa (persone, dipendenti, ruoli, mansioni)
soggetti esterni (altre amministrazioni, cittadini, imprese)
repository documenti (tipicamente solo protocollati)
elenco dei procedimenti amministrativi
materie o titolari di classifica
30
Scenario “monolitico”
• In alcune realtà tale tipo di soluzione potrebbe ancora risultare
conveniente.
• Laddove, ad esempio, la amministrazione sia caratterizzata da una forte
staticità (procedimenti ben identificati con iter stabili, carichi di lavoro
prevedibili ecc.) allora potrebbe aver senso costruire una applicazione
monolitica perfettamente ritagliata su tali esigenze che, per definizione,
non variano.
• In generate, tuttavia, una soluzione di tipo monolitico rappresenta una
legacy che impedisce un facile adattamento del sistema di gestione
documentale alla variazione delle esigenze dell’amministrazione ed alla
evoluzione delle tecnologie e dell’offerta del mercato informatico.
31
Scenario modulare
• E’ lo scenario in cui il protocollo in senso stretto sia visto come un
modulo applicativo, esclusivamente dedicato al servizio di
certificazione, con tutte le caratteristiche previste dal DPR 428.
• Il modulo di protocollo, piuttosto che fornire direttamente all’utente le
funzioni di certificazione previste, sarà accessibile da parte di altre
applicazioni, o componenti, che costituiscono il sistema informatico
dell’amministrazione.
• Oltre al servizio di certificazione di protocollo, dovrebbero essere messi a
disposizione, centralmente a tutti i potenziali utilizzatori, altri servizi che
costituiscono il patrimonio comune dell’amministrazione, secondo criteri
opportuni di visibilità e sicurezza
32
Scenario intermedio
• A meno di applicazioni monolitiche basate su tecnologie proprietarie (ad
esempio sistemi basati su mainframe) ogni soluzione che comporti l’uso
di tecnologie di supporto aperte di tipo cient/server, facenti uso di
strumenti ed ambienti di mercato, offre una qualche forma di modularità e
di accessibilità.
• La soluzione più ricorrente è quella di incentrare il sistema di gestione del
protocollo e delle pratiche su un database e offrire a vari profili client la
possibilità di attivare diverse operazioni sul sistema.
33
Architettura “database-centrica”
• Ricerca
• Registrazione di base ed acquisizione
immagini documenti
• Acquisizione di documenti con posta
elettronica “sicura”
E-MAIL
G-NET
Ufficio posta /
Ufficio Cifra
CL “A”
• Funzioni di registrazione previste dal
processo di gestione documentale
• Funzioni di accesso ai dati
• Funzioni di supporto a ricerca & reporting
• Funzioni di gestione delle autorizzazioni
Ufficio
archivio
protocollo
FAX
SCANNER
STAMP.
STAMP.
STAMP.
•
•
•
•
Ricerca & reporting
Assegnazione pratiche
Gestione autorizzazioni
Gestione indice di
classificazione
Direzione
Generale
Server
applicativo
del protocollo
e dell’archivio
Data base
CL “B”
STAMP.
Responsabili
aree o
progetti
Altri
utenti
CL “C”
•
•
•
•
Ricerca & reporting
Classificazione
Collegamenti
Fascicolazione
• Ricerca
CL “D”
34
Schema E-R di una applicazione di protocollo
(0,N)
PERSONA
(0,N)
(1,N)
(0,1)
appartiene
(0,1)
responsabile
a
(0,N)
(0,N)
ENTITA'
COMPETENTE
responsabile
a
(0,N)
visibile
(0,N)
(1,1)
(1,1)
AREA o UFFICIO
(0,N)
GRUPPO o FIGURA
ISTITUZIONALE
GDL o PROGETTO
(1,N)
(0,N)
(0,N)
relativo
compete
DOCUMENTO
INFORMALE
(0,n)
CLASSIFICA
appartiene (0,n)
(1,1)
ASSEGNAZIONE
(1,1)
relativo
TIPO
PROCEDIMENTO
(0,N)
(0,N)
(0,1)
(0,1)
relativo
in
FASCICOLO
(1,N)
(0,1)
in
(0,N)
(1,1)
(0,N)
(1,1)
autore
(1,1)
COLLEGAMENTO
collega
(0,N)
(1,1)
(0,N)
collega
DOCUMENTO
ALLEGATO
ENTITA'
COMPETENTE
(1,1)
(0,N)
contiene
firma
(1,N)
(1,1)
(1,1)
PERSONA
(0,N)
predispone
bozza
(1,N)
(0,N)
DOCUMENTO
USCITA
appartiene
(1,1)
DOCUMENTO
ENTRATA
riceve
(1,1)
(1,N)
destinatario
(0,N) CORRISPONDENTE
CORRISPONDENTE
OCCASIONALE
(0,N)
mittente
CORRISPONDENTE
ISTITUZIONALE
35
Architettura modulare
Servizi di certificazione
Servizi di
protocollazione
Servizi verticali
Security & Directory
Transactional
WF engine
Servizi di
Repository
validazione
firma digitale
Repository
documenti
soggetti
esterni
Repository
struttura
organizzativa
Repository
procedimenti
amministrativi
Materie e
titolari di
classifica
DBMS
Document management
services
Accesso standard (COM+, IIOP, HTTP, LDAP, DMA API, WF API)
ServiziImaging
SO, File system
Procedimento
assistito da
Workflow
Gestione
corrispondenza
in ingresso
Corrispondenza
particolare
Web services
Server
COLD
E-Mail
Groupware
36
Sistemi di WF management
attività B
attività F
attività A
attività C
attività D
attività E
Definizione dei
processi
Analisi dei processi,
utilizzo di strumenti di modellazione
attività H
attività G
Fase di sintesi e modellazione
Fase di esecuzione
Definizione
Processo
Cambiamenti alla definizione
Esecuzione dei processi
& Controllo
Interazione con
Utenti & Applicazioni
Workflow Enactment Service
Applicazioni
& strumenti IT
37
Quando gestire il processo con WFMS
• stabilità dell’iter del processo in termini di possibilità di rappresentare
uno schema di processo attraverso le primitive di modellazione offerte
dal sistema in modo tale che tutte le istanze o casi del processo siano
riconducibili allo schema in modo completo e senza forzature
• una sufficiente complessità dell’iter stesso per rendere favorevole il
rapporto tra costi dovuti all’adozione di una tecnologia complessa e
benefici attesi. In altre parole casi banali di iter con pochissimi passi
potrebbero essere risolti efficacemente con altre tecnologie.
• una sufficiente numerosità delle istanze attivate per ciascun processo
rappresentato nell’unità di tempo
38
Esempio di integrazione tra Workflow e
protocollo
Servizi di
protocollazione
Servizi di
protocollazione
B
B
F
A
C
D
Servizi di
protocollazione
E
B
F
H
G
1. In una fase di un processo gestito
da un WfMS viene prodotto
un documento da protocollare
A
C
D
E
H
G
2. Il WfMS effettua tramite
la rete, una richiesta di
protocollazione fornendo i necessari
parametri
A
C
D
F
E
H
G
3. Il sistema di protocollo effettua
la registrazione e fornisce i l
risultato dell’operazione al WfMS
39
Collocazione di un sistema monolitico
Servizi di certificazione
Servizi di
protocollazione
Servizi di
validazione
firma digitale
Servizi verticali
Repository
documenti
Repository
soggetti
esterni
Repository
struttura
organizzativa
Repository
procedimenti
amministrativi
Materie e
titolari di
classifica
Sistema monolitico
Procedimento
assistito da
Workflow
Gestione
corrispondenza
in ingresso
Corrispondenza
particolare
40
Repository documentale
Unico document warehouse virtuale
Software e protocolli
standard di integrazione
Soluzioni
tecnologiche
eterogenee
API standard
API
Sistema A
Ufficio 1
API
Sistema B
Ufficio 2
API
Sistema C
Generale
API
API
Sist.D
Sistema E
Altro
Servizio
Unità organizzative
• Possibilità di “virtualizzare” un unico repository
41
Archivio e repository documentale
• Il repository dei documenti potrebbe essere l’unico archivio nel caso di
documenti formati e trasmessi con strumenti informatici
• Nel caso di documenti cartacei dovrà essere in stretta relazione con
l’archivio tradizionale
• Il repository dovrà essere arricchito di tutte le informazioni necessarie in
modo tale da
–
–
–
–
–
facilitare la ricerca dei documenti;
garantire sicurezza ed adeguati livelli di accesso;
facilitare le operazioni di scarto dagli archivi di deposito;
rendere sempre individuabile la posizione fisica dei documenti cartacei;
migliorare la circolarità delle informazioni all'interno dell'amministrazione.
42
L’accesso esterno e la interconnessione
dei sistemi di protocollo informatico: il
modello “protocollo federato”
Amministrazione o Area
organizzativa omogenea A
Amministrazione o Area
organizzativa omogenea B
Amministrazione o Area
organizzativa omogenea C
43
Federazione “intra-amministrativa”
Area organizzativa
omogenea A
Area organizzativa
omogenea B
Amministrazione
44
Federazione “inter-amministrativa”
Amministrazione o Area
organizzativa omogenea A
Amministrazione o Area
organizzativa omogenea B
Amministrazione o Area
organizzativa omogenea C
45
Accesso esterno per trasparenza
amministrativa
Cittadini e
imprese
Amministrazione o Area
organizzativa omogenea
o federazione di AOO
46
Conclusioni
• Far leva sul fattore culturale: sensibilizzazione, formazione
• Analisi dei processi: sono tutti realmente indispensabili i passi
che eseguiamo o facciamo eseguire ogni giorno?
• Apertura verso le soluzioni di mercato
• Circolarita’ delle informazioni
47