Strumento per la piallatura del legno

E’ vero che a pensare a male a volte ci si prende, ma sarebbe opportuno anche non arrestare prima di averne conferma. Ritengo questa una forma di rispetto, più che nei confronti degli indagati, nei confronti della Giustizia con la “G” maiuscola.

Pag. 49 dell’atto di accusa: Il sistema di frode nelle pubbliche forniture attraverso la cessione di calcestruzzo difforme

“…e non può essere casuale il fatto rilevato dal perito che in data 11/10/2007 nello stesso giorno siano stati rettificati 2554 records, pari a circa il 30% di quelli esistenti in memoria e tutti riguardanti la zona Sicilia (in particolare gli impianti di Riesi, Gela e Castelbuono…

Il momento di tale operazione (tecnicamente definita “piallatura”) corrisponde con l’epoca del sequestro da parte dell’autorità inquirente nissena dei computer degli impianti dei quali provenivano i dati.
Tale contestualità conferma che analoghe operazioni fossero volte ad occultare i reali valori delle ricette utilizzate per le forniture…”

Innanzitutto non si capisce perché in quella data gli utenti del CED avrebbero effettuato la “piallatura” solo del 30% di dati, ignorando l’altro 70% dove gli stessi uomini del CTU hanno poi trovato i riscontri delle ricette con cls a contenuto minore di cemento… Allora fatemi capire: io, che secondo qualcuno sarei il “deus ex-machina” della truffa solo perché conosco perfettamente il software e come accedere ai dati, mi sarei lasciato sfuggire un 70% dei dati che poi sono serviti per individuare le frodi siciliane?

Cari lettori, come alcuni di voi sapranno meglio di me, nel linguaggio di programmazione SQL-Like (come è il linguaggio Progress usato dall’applicazione Calcestruzzi) sarebbe stato  sufficiente eseguire l’istruzione DELETE * FROM dati_produzione ed il problema si sarebbe risolto, definitivamente. Ma che stupido a non averci pensato prima; avrei salvato l’azienda e i veri responsabili, e inoltre la cancellazione sarebbe stata anonima e quindi non riconducibile alla mia persona… Ma che strano; invece così ho salvato il 70% dei dati e ho lasciato che il software scrivesse la mia utenza e quella dei miei colleghi, e ci cacciasse tutti nei guai… Ma vi sembra che questa tesi sia oltremodo logica?

Il CTU peraltro afferma che sono stati rettificati 2554 records; ma sulla base di cosa è in grado di affermare questo? Si è così certi che il dato precedente fosse diverso da quello successivamente aggiornato? Eh già, bella domanda: c’è differenza tra modifica e aggiornamento?

Per capire meglio il significato di quest’ultima domanda vi invito a fare questa prova: se io aprissi un file di Word a caso del vostro PC e lo salvassi così com’è senza aggiungere o toccare alcuna lettera, l’avrei effettivamente modificato? Fatemi indovinare: si otterrebbe la stessa identica rappresentazione del testo che era presente in precedenza sul documento, ma con stato del record (data e utente) modificato! E anche eseguendo l’elaborazione centinaia di volte otterrei centinaia di aggiornamenti per lo stesso file, ma senza apportare alcuna modifica al contenuto di esso…

Proviamo quindi a dare una rappresentazione ben diversa di quanto accaduto e molto più rispondente alla verità:

  • La Direzione Calcestruzzi probabilmente richiese in data 11/10/2007 la verifica dei dati siciliani sulla base delle accuse formulate dalla Magistratura;
  • Gli operatori del CED (tra i quali non c’ero io, perché impegnato come relatore al corso per tecnologi della Mapei sull’uso degli strumenti informatici nel settore del calcestruzzo… pensate un po’…) lanciarono il programma di controllo TESTESTRAZ (lo dice la parola stessa, TEST ESTRazioni) creato appositamente per permettere verifiche di dettaglio maggiore;
  • Il programma individuò su diverse bolle “manuali” (vi ricordo che nel 2001-2002 gli impianti in questione non erano automatizzati) alcune righe di dettaglio di tabella pesi con quantità espressa in Kg ma unità di misura “Tonnellate”;
  • Sommando le quantità per metro cubo, il programma ottenne un valore assurdo e ricondusse la causa dell’errore ad un’evidente anomalia di dati di pesata, e non un’anomalia dell’unità di misura della ricetta (l’errore fu commesso dall’allora tecnologo di Zona Sicilia che associò alle materie prime l’unità di misura “T” anziché “Kg”);
  • Poiché il peso per metro cubo sul dettaglio pesi risultava di circa 750 volte superiore al peso medio trasportabile da una betoniera, il programma si attivò automaticamente per ricostruire il mix e a dichiarare la pesata “manuale” (ossia “stimata”);
  • Purtroppo però, a risultare errato era proprio il mix della ricetta con i suoi materiali espressi in tonnellate, e non l’acquisizione dei dati di pesata dall’automazione; di conseguenza il programma non fece altro che rigenerare nuovamente la riscrittura dei dati nella forma errata salvando ancora il peso in tonnellate, e riscrivendo quindi esattamente gli stessi valori.

Come si può facilmente intuire, essendo poi gli impianti indicati dall’accusa tutti in manuale e quindi sprovvisti di dati di pesata in automatico, in data 11/10/2007 nessun dato venne modificato, ma solo ri-processato e, purtroppo, riconfermato (cambiando solo lo stato di aggiornamento del record), perché – ribadisco – quello che era sbagliato era il mix design di origine.

A controprova di quanto affermo, il CTU può individuare i codici dei mix presenti nella lista dei 2554 records e verificarli direttamente sui database Progress sequestrati il 30 Gennaio 2008; noterà che quel 30% delle bolle modificate sarà probabilmente legato a questi mix errati. Suggerisco inoltre di verificare i dati di Backup dei database Progress presenti in sede Calcestruzzi, che ho personalmente salvato negli anni 2004 e 2005, e che dovrebbero essere ragionevolmente già in possesso della Magistratura, oppure presenti ancora negli armadi della Calcestruzzi; in questo modo si potrà facilmente smentire quanto affermato in sede di formulazione di accusa e diffuso così solertemente a tutti i notiziari italiani ed internazionali…

Questo esempio di ricette errate in Sicilia peraltro è molto significativo per spiegare i motivi alla base di alcune procedure del software atte a “normalizzare” le pesate associate alle bolle di vendita; nessuno si poteva accorgere dell’errore di unità di misura proprio perché gli impianti erano in manuale, altrimenti in caso di impianto automatizzato il punto di carico e la betoniera sarebbero stati sommersi di inerte e ci si sarebbe accorti subito dell’errore; non solo, ma anche l’accuratezza dei mix design inseriti in Progress lasciava a desiderare, proprio per l’assenza di un sistema di automazione da configurare correttamente. Sempre in zona Sicilia a quel tempo erano inoltre spesso presenti mix design completamente “vuoti”, ossia senza i componenti di dettaglio, ma solo con i dati generali (caratteristica, denominazione, ecc…) necessari alla formulazione della bolla… Secondo voi, perché in tutta Italia i mix design erano correttamente inseriti mentre in Sicilia erano così lacunosi? E’ colpa ancora dei sistemi informativi di sede?

Dal confronto di questi dati con quelli a disposizione del CTU si potrà facilmente verificare sia l’entità reale dell’attività di normalizzazione sia l’assoluta infondatezza del disegno criminale di occultamento delle prove; come anche evidenziato dall’accusa in sede istruttoria, i dati degli impianti cominciano ad essere fruibili regolarmente a partire dal 2001, quindi per gli anni 1998, 1999 e 2000 (e forse 2001) si suppone già in partenza una scarsa o poco significativa qualità delle informazioni presenti sui DB storici; mi risulta che la maggior parte delle modifiche riguardi proprio questi anni, e che anche a detta dell’accusa siano periodi poco rappresentativi…

E’ importante infine evidenziare che nel Giugno 2007 io ero prossimo all’uscita dall’Azienda; quindi, per quale motivo avrei dovuto eseguire un’azione “illecita” per mio interesse personale e per un’azienda che stavo peraltro lasciando? Inoltre nel Giugno 2007 non ero a conoscenza di un’indagine nei confronti della sede, e quindi mancavano ragionevolmente i presupposti illeciti per eseguire un’attività di “normalizzazione” (peraltro inutile sui PC già sequestrati) che, ripeto, non ha occultato informazioni che potevano nascondere attività fraudolente, bensì, come spiegato per l’accusa precedente, ha solo verificato le situazioni macroscopicamente errate, ha rielaborato i dati anomali (senza apportare alcuna modifica), e infine ha ri-aggiornato lo stato del record ovviamente con l’utenza degli operatori del CED. Del resto, se fossimo stati in malafede, avremmo potuto tranquillamente modificare il programma eliminando temporaneamente l’aggiornamento dell’utente sul record; avremmo evitato un sacco di problemi…

A questo punto qualcuno si potrebbe fare la domanda: perché si è preferito un programma automatico di normalizzazione al posto di un intervento manuale sui dati considerati errati? Una cosa fondamentale da sapere è che gli scarichi fiscali di magazzino venivano eseguiti a quel tempo “a vista”, verificando cioè i cumuli e le giacenze fisiche presenti in impianto. Il motivo è molto semplice: se non si è dotati di un sistema di automazione efficiente, il dato inserito dall’operatore a computer (definito “pesata in manuale”) non può considerarsi attendibile o rispondente al 100% con quanto poi effettivamente scaricato. Inoltre, se il sistema di automazione è usato poco e male è evidente che una parte delle pesate restituite dal sistema di automazione non potrà essere mai completamente rappresentativa di tutta la produzione mensile; tanto maggiore sarà la percentuale di automazione dei carichi dell’impianto (fissata come obiettivo al 95% da Calcestruzzi), tanto più i consumi saranno vicini al consumo effettivo riscontrato a magazzino. Sempre che l’automazione o i mix design restituiscano i valori giusti.

Ed ecco che entra in gioco l’automatismo della normalizzazione dei dati. Poiché i magazzini dovevano essere chiusi e validati dal Controllo di Gestione entro il 6° giorno lavorativo, questo implicava che i responsabili regionali dovevano verificare i dati di loro competenza entro il 4° giorno lavorativo, quindi a cascata gli uomini degli impianti di Calcestruzzo dovevano eseguire tutti i loro controlli (specialmente le bolle di entrata ed uscita) entro il 2° giorno lavorativo. Poiché al tempo gli impianti della Calcestruzzi oscillavano tra i 200 e i 250, con un numero di bolle medio mensile dell’ordine di 100.000, i dati di dettaglio di pesate da verificare erano quindi circa 600.000/mese. Ora, qual è la probabilità che un sistema di automazione in tilt, o un operatore distratto, o un errore di unità di misura, o un transfer-file parzialmente danneggiato, o qualsiasi altra cosa non prevista possa creare una riga non congruente con quanto effettivamente compiuto in impianto? Bene, dalle nostre statistiche mensili risultavano circa 4.000/5.000 righe di dettaglio anomale (il che non significa necessariamente errate, ma il cui valore poteva essere considerato “fuori norma”). Di queste, 2.000/3.000 erano effettivamente errate. E quante persone ci lavoravano in sede all’analisi e alla verifica di queste righe anomale? Al massimo tre, e guarda caso erano gli operatori del CED, che oltre a dover svolgere le complesse attività informatiche di fine mese, dovevano anche trovare l’errore (qualora ci fosse stato) che andava ad inficiare il calcolo corretto dei consumi di fine mese.

Come dire: avete voluto il sistema di automazione, adesso i casini (nostri) li sistemate voi. Cornuti e mazziati.

 

Torna al Menù