www.poliziapenitenziaria.it

Home Page> Articolo> Pubblicato il: 07/03/2016  -  stampato il 10/12/2016


Corte dei Conti contro CED del DAP: accertato illecito amministrativo contabile con effetti dannosi permanenti

Di notevole rilievo giuridico e tecnico è l’atto di citazione (brani) che concerne la realizzazione difettosa del sistema informatico presso il Dipartimento dell’Amministrazione Penitenziaria (DAP) del Ministero della Giustizia. Le questioni eccepite dal P.M. Contabile sono ampiamente esaustive della materia informatica e, pertanto, detengono un pregio ed un rilievo ex se.

Con nota n. GDAP-0391384-2011 del 17 ottobre 2011 (pervenuta a questa Procura regionale il 19 ottobre), il Direttore dell’Ufficio per l’attività Ispettiva del Dipartimento dell’amministrazione penitenziaria (d’ora in poi DAP) del Ministero della Giustizia ha segnalato un presunto danno alle pubbliche finanze connesso alla realizzazione del sistema informatico AFIS-UEPE (già AFIS-CSSA).  

Successivamente, a seguito di una visita ispettiva condotta a partire da settembre 2011 presso l’Ufficio per lo sviluppo e la gestione del Sistema Informativo Automatizzato del citato Dipartimento, è stata trasmessa a questa Procura, con nota n. RIS/3/2013 del 23 gennaio 2013, la relativa relazione ispettiva datata 12 dicembre 2012. A seguito degli ulteriori accertamenti istruttori delegati in data 27 novembre 2013 da questo Pubblico Ministero al medesimo Ufficio per l’attività Ispettiva del DAP, è stata prodotta dagli ispettori incaricati la relazione finale del 4 dicembre 2014, da cui emerge quanto di seguito sintetizzato.

L’attività ispettiva ministeriale e la conseguente attività istruttoria di questa Procura regionale ha avuto ad oggetto, in particolare, due progetti per l’informatizzazione degli Uffici del DAP CSSA, poi divenuti UEPE. L’affidamento al R.T.I. della realizzazione del sistema informativo per l’automazione degli Uffici UEPE, prevedeva da parte del medesimo RTI – come è sempre previsto nello sviluppo dei software applicativi - la fondamentale attività di identificazione e analisi dei requisiti, volta ad individuare i requisiti degli utenti e di sistema (specifiche per la realizzazione del software), in particolare anche attraverso una serie di incontri con il committente Direzione Generale Esecuzione Penale Esterna (d’ora in poi, “DGEPE”) e gli utenti finali nonché utilizzatori (UEPE – Uffici per l’Esecuzione Penale Esterna).

All’uopo veniva costituito dall’amministrazione un apposito gruppo di lavoro formato da rappresentanti dei vari uffici coinvolti. A tutto ciò si aggiunga che il collaudo vero e proprio dei due sistemi non risulta essere mai avvenuto. Trattasi di un’ipotesi di danno erariale derivante dall’inutile realizzazione e mancata utilizzazione di un sistema informatico, oggetto di due distinti progetti.

LE FASI DEL PROGETTO

Prima di entrare nel dettagli della realizzazione del progetto, occorre premettere in via generale che, dal punto di vista dell’ingegneria del software – la disciplina tecnologica e gestionale che riguarda la produzione sistematica e la manutenzione dei prodotti software da sviluppare o modificare entro tempi e costi preventivati – esistono modelli progettuali ormai del tutto consolidati, suddivisi in macro-fasi, il più diffuso dei quali (adottato da decenni anche nell’ambito delle amministrazioni pubbliche e previsto anche con riferimento ai progetti in discorso), si articola come segue:

a) Studio di fattibilità: si tratta di una valutazione preliminare dei costi e dei benefici di un’applicazione;

b) Analisi e specifica dei requisiti: vengono individuate le funzionalità (requisiti funzionali), i vincoli e gli obiettivi del progetto;

c) Progettazione: si precisa l’architettura generale (hardware e software) del sistema e si descrivono le funzioni che il sistema deve svolgere. L’architettura software può essere composta da singoli moduli, di cui andranno esposte le funzionalità e le relazioni.

d) Realizzazione e test delle unità: il progetto entra nella fase esecutiva e viene realizzato come insieme di programmi o unità di programmi (moduli) nel linguaggio di programmazione scelto. L’attività di testing delle unità è finalizzata poi a verificare che ciascuna di esse soddisfi le specifiche richieste.

e) Integrazione e test del sistema: le singole unità e/o i programmi vengono integrati tra loro. Il cosiddetto alfa test individua il rilascio per l’uso del sistema, mentre, con il beta test avviene il rilascio controllato ad un campione ridotto e selezionato di utenti del prodotto.

f) Utilizzo e manutenzione: si tratta della fase più lunga del ciclo di vita di un prodotto software. La manutenzione comporta la correzione degli errori che non erano stati scoperti nelle fasi precedenti. E’ possibile distinguere tre tipi di manutenzione: correttiva, adattativa o evolutiva, e perfettiva, qualora occorra effettuare l’aggiornamento del prodotto o aggiungere nuove funzionalità.

L’articolazione in micro-fasi era la seguente: la realizzazione di un prototipo funzionale, da installare presso l’Ufficio Centrale di Roma; la sperimentazione del prototipo funzionale attraverso adeguate attività di verifica e test da effettuarsi, presso il suddetto Ufficio Centrale, per un periodo di 30 giorni; la diffusione del prototipo funzionale su 3 Uffici CSSA campione; l’effettuazione del test operativo del prototipo funzionale sui suddetti 3 Uffici campione; l’aggiornamento dei prototipi installati presso l’Ufficio Centrale e presso i tre Uffici campione con la versione finale del SI-CSSA; il rilascio finale dell’applicazione software.

Quindi nel caso di specie il collaudo finale (mai avvenuto) si sarebbe dovuto eseguire successivamente all’installazione del software presso tutti gli uffici interessati

GRAVISSIMI ERRORI NELLA GOVERNANCE

Nel corso degli accertamenti istruttori delegati da questa Procura regionale e nell’ambito dell’attività ispettiva già svolta in precedenza dall’amministrazione è emerso che gravissimi errori nella governance e nel coordinamento del progetto hanno determinato “l’acquisizione da parte dell’amministrazione di un prodotto del tutto inidoneo alle esigenze operative…e non conforme ai requisiti contrattuali”. Oltre a numerosi irregolarità e anomalie riscontrate già nella fase di gara, l’attività istruttoria ha permesso di rilevare palesi errori metodologici e di governance della fornitura, che ne hanno causato l’inidoneità, la mancata accettazione ed il conseguente inutilizzo totale.

Si può dunque concludere sul punto che il coinvolgimento del personale degli Uffici UEPE nella stesura dello studio di fattibilità è stato totale e ha consentito alla FORMIT di raggiungere gli obiettivi prefissati, tenendo conto delle esigenze degli utenti finali, così come prescrive la manualistica in materia, e individuando chiaramente le specifiche generali e le specifiche di massima del sistema informativo da realizzare.

Passando alla seconda fase progettuale essa prevedeva, come è prassi e come previsto dalla manualistica in materia, lo svolgimento di una serie di incontri tra il fornitore aggiudicatario, il committente (DGEPE) e gli utenti finali nonché utilizzatori (UEPE), allo scopo di identificare l’insieme dei requisiti utenti e di sistema. In questa fase, è emerso che il Gruppo di lavoro, nel corso delle sin troppo numerose sedute di analisi (circa 42), ha fornito le osservazioni ai fini dell’individuazione delle specifiche di progetto dell’applicazione, come risulta anche dalle dichiarazioni rese in sede di audizione dinanzi agli ispettori delegati alle indagini; in particolare, sono stati definiti i livelli di dettaglio delle funzionalità per ciascuna delle macro aree di intervento individuate dallo studio di fattibilità.

In conclusione su questo punto (centrale ai fini della ricostruzione della vicenda e dell’affermazione di responsabilità), va ribadito che non ci sono stati errori né nello studio di fattibilità, né nella fase di analisi dei requisiti, infatti, il gruppo di lavoro ha fornito collaborazione e chiarimenti alla Società Finsiel, partecipando, come detto, a ben 42 sedute di analisi dei requisiti. L’anomalia di questa fase è semmai costituita dal fatto che il Documento di Specifica dei Requisiti (DSR) non è stato approvato dall’amministrazione, causando una rischiosa fluidità e incertezza delle specifiche funzionali da realizzare (cfr. supra sub. 1b).

LA COMMISSIONE TECNICA

Venendo ad un ulteriore aspetto centrale nella vicenda, il contratto prevedeva (art. 8) la costituzione di una “Commissione Tecnica MG” che doveva verificare e controllare l’esecuzione del contratto “per tutta la sua durata”; in particolare, si trattava di verificare, fase per fase, lo stato di avanzamento del progetto e di eseguire le attività di collaudo del SICSSA.

Nonostante tutto ciò, con nota 0357756–2003 del 12.09.2003 si comunicava al R.T.I. l’accettazione del prototipo funzionale, pur segnalando soltanto che “la Commissione tecnica dell’Amministrazione ritiene, tuttavia, che debbano essere apportate le modifiche segnalate nella relazione allegata al verbale prima della diffusione del prodotto ai tre uffici campione “. Il R.T.I. rispondeva al DAP di aver preso atto delle richieste formulate dalla Commissione Tecnica MG e dichiarava di aver completato la realizzazione delle conseguenti attività previste nel contratto. In sostanza, il nuovo contratto n. SIA05-06-D1.S26/0, è stato stipulato sul presupposto della realizzazione dell’applicativo SI-CSSA, di cui questo secondo progetto costituiva la continuazione, nonché del suo collaudo, mentre al contrario, pochi giorni prima la stipula di questo nuovo contratto, in data 26.8.2003, la Commissione tecnica MG aveva richiesto di apportare le importanti modifiche di cui si è detto.

Il resto della vicenda non rappresenta altro che la naturale conseguenza dei gravi errori gestionali e di governo della fornitura appena rappresentati: il nuovo prototipo visionato nel corso del 2004 presentava le medesime criticità riscontrate nella realizzazione del primo progetto e precisamente la mancanza del collegamento al Protocollo necessario per l’operatività degli Uffici CSSA. Di fatto veniva confermato che anche il nuovo prototipo non era rispondente alle specifiche richieste del gruppo di analisi e di conseguenza alle esigenze dell’Ufficio.

TIPICO CASO DI ILLECITO AMMINISTRATIVO CONTABILE CON EFFETTI DANNOSI PERMANENTI

La fattispecie in esame configura dunque un tipico caso di illecito amministrativo contabile con effetti dannosi permanenti – cristallizzati dalla perdurante inutilizzabilità dei servizi e forniture oggetto dell’appalto – con conseguenze rilevanti anche in ordine alla decorrenza del termine prescrizionale in base alla disciplina generale di cui all’art. 2935 c.c., a tenore del quale la prescrizione decorre dal momento in cui il diritto può essere fatto valere (su questo aspetto specifico, tra le tante, Corte dei conti, Sez. I App., nn. 427 del 2003 e 68 del 2006). In particolare, la sentenza delle SS.RR. appena citata (la n. 2/QM del 2003) ha affermato 73 che ipotesi di appalto di opere pubbliche, la prescrizione inizia a decorrere dal momento in cui sia conoscibile o effettivamente conosciuto da parte dell’amministrazione appaltante il comportamento illecito del soggetto legato da rapporto di servizio e il danno abbia assunto il carattere della certezza ed attualità.

A tutto ciò si aggiunga che, come visto, il collaudo vero e proprio dei due sistemi non risulta essere mai avvenuto. Nella vicenda in esame, oltre alle numerose irregolarità di cui si è detto, emerge un chiarissimo difetto di governance della fornitura; in particolare, come si evince dagli atti, il dirigente ha omesso di imporre all’impresa (il RTI) l’osservanza scrupolosa degli adempimenti contrattuali, nonché di attenersi delle numerosissime osservazioni dei Gruppi di lavoro succedutisi nel corso degli anni e, soprattutto, della Commissione Tecnica, che avrebbero avuto un risvolto positivo sul piano funzionale e operativo degli Uffici CSSA.

 

La Relazione completa della Corte dei Conti

 

Caro CED ti scrivo (capitolo quinto): Il Sistema Informativo Direzionale

 

Le tecnologie possono essere d'aiuto in carcere per i detenuti e il personale? Dipende...

 

Sono le applicazioni informatiche che non funzionano oppure sono i Dirigenti che non sanno usarle?