Principi generali dell'utenza
Il Comune è suddiviso in settori. Ogni settore è composto da unità organizzative (UO), rette da un responsabile, che gestisce delle tipologie di istanze o pratiche.
Ogni UO è composta da personale suddiviso, per le funzioni esplicate, in ruoli.
Le tipologie di istanze sono suddivise in istanze o pratiche.
Questo sistema organizzativo dei dati permette di gestire logicamente il processo.
L’istanza (di una certa tipologia) arriva al protocollo ed è destinata ad un settore.
L’istanza viene esaminata (a mano o tramite software) e indirizzata ad una UO del settore.
La Uo del settore, gestita da un responsabile, tramite il personale avente i propri ruoli e il workflow che sposta la pratica nel suo iter gestendo nodi e ruoli, conduce la pratica alla sua istruttoria e archiviazione.
Questa struttura organizzativa operativa è affiancata ad una struttura organizzativa di utilizzo del software.
Per l’accesso al software ci si avvale di una altra struttura, quella tradizionale degli ‘Utenti’.
Gli utenti sono suddivisi in gruppi ed ogni gruppo ha dei diritti di lettura e scrittura sulle classi di informazioni gestite dal software.
Le due strutture si intrecciano ma non coincidono. Gli utenti del software possono essere diversi dai responsabili della gestione della pratica e dei dati. Pensiamo ad un assessore o ad un presidente di commissione che potrebbero avere la necessità di accedere a dei dati, ma non entrano nel processo istruttorio.
Il punto di contatto tra la struttura organizzativa comunale e le utenze del software è l'abbinamento di un utente al ruolo. Un utente può quindi appartenere ad una unità organizzativa ed avere un ruolo. Se ha questa caratteristica questo utente potrà partecipare alla gestione delle pratiche.
Va sottolineato però che la gestione degli utenti del sistema, non affiancata dalla gestione dei workflow, ha sempre avuto delle notevoli difficoltà nel controllo dell’accesso ai dati e necessitava di una certa accuratezza per la sua predisposizione che, nella maggior parte dei casi, non era però sufficiente a garantire il controllo dell’accesso. Pensiamo alla difficoltà, quasi impossibilità, utilizzando solo la gestione degli utenti, di poter proibire ad un istruttore tecnico di mettere mano ad un’istruttoria di una pratica assegnata ad un suo collega istruttore impiegato presso lo stesso ufficio.
Con l’applicazione del workflow questo problema decade. Solo l’istruttore assegnato potrà toccare quella pratica e stenderne il rapporto di istruttoria.
Utilizzando il workflow diventa così molto più semplice ed elastico la gestione dei diritti per i gruppi di utenza. Si può dare a tutti gli istruttori il diritto di leggere e scrivere un dato, ma poi ci penserà la struttura del workflow a far scrivere solo l’istruttore assegnato a quella pratica, gestendo dei diritti di accesso che stanno a monte dei diritti dei gruppi di utenza.
Quindi i gruppi di utilizzatori possono essere più generici, come, ad esempio, gli altri uffici comunali, i politici, gli uffici di enti esterni e, naturalmente, il gruppo che gestisce le pratiche edilizie.
Particolare attenzione dovrà essere posta nella formazione dei gruppi che avranno l’accesso alla configurazione del software, cioè per le tabelle, gli utenti, le tipologie delle pratiche, l’associazione delle pratiche ai modelli e ai workflow, oltre alla gestione della modulistica e alla costruzione degli stessi workflow.
Come pure si dovrà curare particolarmente, nella gestione utenti, la formazione delle relazioni tra Responsabili/pratiche e Ruoli/Permessi. Con la prima praticamente si indirizzano automaticamente le pratiche in arrivo ad un responsabile, quindi ad un UO. Con la seconda si mette in relazione un elemento della struttura comunale (un funzionario con un ruolo) con la struttura del software (le classi di informazioni gestite).