Posts tagged protocollo informatico

Capita spesso di confrontarmi sul *come* attuare politiche di protocollo informatico per la Pubblica Amministrazione, in realtà parte dei vincoli normativi riguardano anche le organizzazioni private, diciamo comunque che il *grosso* delle problematiche si hanno quando ci si interfaccia con le prime.

La normativa corrente, in termini di soluzione applicativa, definisce in maniera vincolante requisiti e modalità di fruizione del prodotto in maniera quasi maniacale: infatti una delle osservazioni più comuni è proprio quella che porta a considerare l’informatizzazione delle procedure di protocollo, cosi come descritte nella normativa, come semplice trasposizione di attività umane in termini di sistema informativo.

Sembra stupido ma è cosi: il protocollo informatico  è sopratutto questo! E’ un grande contenitore di casi, di procedure ed eccezioni che rendono soltanto più veloce l’attività di *esplicare* una pratica. Non significa comunque che il tutto è banale, anzi, come ogni procedura umana informatizzata si è di fronte ad un livello di *capillarietà* di funzioni molto alta … senza considerare l’aspetto archivistico di procedure di gestione documentale che comunque sono presenti e devono essere automatizzate.

Non a caso, la normativa prevede diversi livelli di attuazione del Protocollo Informatico, ovvero:

• Nucleo Minimo
• Gestione Documentale
• WorkFlow
• Business Process Reengineering

Questi livelli sono resi necessari per dare modo alle organizzazioni di avviare un graduale processo di ri-organizzazione del sistema informativo al fine di conseguire una divisione logica del flusso documentale interno/esterno all’organizzazione stessa, il tutto basato sul concetto di pratica.

Nucleo minimo

Questo primo livello in realtà nasconde delle particolarità molto importanti. Se è vero che per nucleo minimo, di norma, si intendono le attività di *tenuta* di un registro elettronico dei protocolli è anche vero che esso include, ovviamente, tutte quelle attività di classificazione … molto care agli archivisti che rendono necessaria la presenza di un archivio elettronico delle pratiche acquisite dall’organizzazione. Va da se che, pur non vincolando la gestione informatica del protocollo, questo primo step di attuazione richiede la presenza di un qualche flusso che assicuri ai documenti un ciclo di vita pertinente alla vigente normativa in materia di dematerializzazione.

Gestione Documentale

Questa parte descrive la modalità *avanzata* di gestione del nucleo minimo, attraverso un entry point documentale che sia in grado di supportare tra le altre:

• Acquisizione elettronica dei documenti (segnatura elettronica, firma + eventuale marca)
• Assegnazione telematica della pratica (visibilità dell’organizzazione interna)
• Collegamento dei documenti alla gestione dei procedimenti interni

In pratica, non occorre soltanto un portale documentale, si ha la necessità in questo specifico caso, di prevedere una serie di funzionalità agiuntive che assicurino una corretta veicolazione delle informazione acquisite da parte dell’organizzazione.

WorkFlow

Razionalizzare i processi documentali è il requisito fondamentale del WorkFlow, cosi come è inteso dalla normativa sulla nuova PA digitale. Il beneficio tangibile diretto è la particolare *velocità* di individuazione dell’informazione a prescindere dalla logistica del documento e dalla sua conservazione.

Business Process Reengineering

Ultimo step: qui ci giochiamo il tutto per tutto! Dare in mano uno strumento di BPR ad una organizzazione pubblica può essere molto pericoloso. Ri-disegnare processi umani o documentali, solitamente richiede un’ampia visione dell’organizzazione interna, cosi da poter di volta in volta inglobare le competenze e profili aziendali i più idonei per l’espletamento di un processo amministrativo durante la sua modellazione. La normativa su questo punto non è molto chiara, si parla di potenzialità e di obiettivi, senza a mio avviso specificare, che forse un grado di maturazione dell’assessment è un requisito fondamentale per una buona riuscita dell’attuazione del protocollo informatico. Non è una novità che spesso all’interno di pubbliche amministrazione si ha una visibilità superflua dell’organizzazione (verticale il più delle volte) ed una *non spiccata* propensione alla conoscenza ed alla comprensione delle capacità, più che i ruoli, altrui. Uno strumento di BPM/BPR, deve prevedere situazioni di conflittualità relativi a competenze su determinati procedimenti ed una certa *dinamicità* di assegnazione dei ruoli aziendali. Faccio notare, con non poco fastideo, che uno dei casi in qui una forte propensione, sopratutto nella fae di accettazione del management, in questi casi, gioca un ruolo fondamentale nella buona riuscita del progetto ed in genrale della messa in opera di tutto il sistema informativo.

Livelli di attuazione diversi che hanno particolarità comuni da non sottovalutare durante la fase di analisi di un prodotto o di un qualsiasi intervento tecnologico basato su questo dominio applicativo. Particolarità che riguardano alcuni filoni logici che accomunano i seguenti concetti:

• L’identificazione del documento dal punto di vista di procedura e di classificazione;
• Il protocollo informatico come unico entrypoint di una organizzazione;
• La relazione tra ruoli ed organizzazione non incentrata sulle competenze;