Quando inizi una discussione (come quella sull’unificazione dei database ai fini fiscali) che spazia nel campo del tuo lavoro, tendi a dare per scontato che le persone ragionino secondo i metodi e le prassi che incontri ogni giorno nel tuo lavoro. Per esempio, quando scrissi davo per scontato che qualcuno sapesse qualcosa di data mining e che si avesse idea del concetto di “complessita’ asintotica di un algoritmo”. Visto che le cose non stanno cosi’, vedo un attimo di spiegarmi.
Innanzitutto, la lotta all’evasione fiscale NON puo’ essere una operazione di reazione. Cioe’, non si puo’ fare reagendo alla notizia dell’evasione. La ragione e’ che un approccio del genere puo’ funzionare solo se i numeri sono abbastanza bassi. In quel caso, avendo 50.000 uomini a disposizione, contando che un singolo uomo possa controllare la contabilita’ completa di tre aziende l’anno (incrociando le fatture con quelle di altri) otteniamo 150.000 aziende l’anno.
Sto gia’ parlando di cinque volte quello che fa la GDF, dal momento che il numero completo di auditing
http://www.gdf.gov.it/repository/ContentManagement/information/N614484291/Rapporto_Annuale_2010_Dati.pdf?download=1 e’ di 31777, e anche unendole al “monitoring” siamo attorno ai 100.000., con la scoperta di 8000 evasori. (ne sono stimati 300.000), di cui 2700 che non versavano IVA . (ah , ah , ah. E si VANTANO di un risultato simile!).
Se consideriamo che in Italia ci sono 8 milioni di partite IVA di cui 2 risultano inattive ,e andrebbe controllato se lo siano davvero, voi capite che la lotta all’evasione fatta in maniera reattiva non ci restituisce i numeri che vogliamo. Occorrono piu’ di dieci anni per controllare (e ho fatto l’ipotesi ottimistica di un controllo pieno ogni 3 giorni/uomo) soltanto le partite IVA ufficialmente inattive.
Se considerate che l’obbligo di conservazione dei libri contabili e’ inferiore ai dieci anni, in pratica significa impiegare tutti e 50.000 gli uomini solo per una frazione del 2% delle partite iva “inattive” (tra le quali spesso si nascondono evasioni piu’ o meno furbe).
E’ ovvio, quindi, che un sistema di contrasto all’evasione NON possa basarsi sui “controlli”, almeno nella misura in cui i nostri 50.000 uomini non partano da un insieme di “sospetti” tali per cui sia molto comune trovare l’evasore.
Quindi mi spiace ma insisto: sino a quando lo stato usa come strumento il controllo su singoli, basato sull’intervento umano on-site, sta dicendo di essere uno stato che perdera’ la lotta. L’evasore e’ un individuo che calcola MOLTO bene le probabilita’ di essere pizzicato per intervento diretto : dopo l’euforia per il caso di Cortina, scoprirete che non solo il SUV e’ un autocarro aziendale, ma l’azienda e’ pure a conduzione familiare, per cui saltera’ fuori che la signora ingioiellata puo’ stare sopra l’autocarro. Per quei 42 pizzicati di cortina probabilmente tutto si concludera’ con una multa lievissima.
Lo stesso dicasi per gli esercizi commerciali che hanno quadruplicato le vendite: non e’ un reato farlo, non e’ stato dimostrato nulla , e qualsiasi avvocato li tirera’ fuori dalle peste. Non esistendo un modello completamente impositivo del sistema fiscale, anche usando la presunzione assoluta non si otterra’ altro che una serie di ricorsi e di contrattazioni col fisco, sino al pagamento di multe irrisorie.
Qualcuno ha detto che si e’ trattato di “operazione mediatica” se si trattava di far illudere degli idioti, immagino ci siano riusciti. Se si e’ trattato di portare voti al partito di Berlusconi e alla Lega, indubbiamente ci sono riusciti.
Ma “operazione mediatica” e’ solo fuffa: quell’operazione allo stato e’ costata e costera’ in ricorsi e scartoffie varie. Se non rientrano dei costi , lo stato ci ha rimesso e qualcuno paghera’. E no, l’evasore non e’ spaventato da queste minchiate: semplicemente, iniziera’ a varcare il confine e andare a sfoggiare il lusso dieci metri dietro al confine svizzero, austriaco ( o altro).
La cosa che potrebbe terrorizzare il nostro evasore sarebbe la possibilita’ di essere beccato SENZA sapere in che modo. Senza cioe’ sapere esattamente dove ha sbagliato: in quel caso e’ chiaro che l’evasore ha sbagliato nell’andare a Cortina, all’albergatore e’ chiaro che sta sbagliando a gestire le prenotazioni online (e relativi pagamenti) senza fare estero su estero, e cosi’ via.
Diverso e’ il caso in cui lo stato ti arriva addosso semplicemente perche’ da qualche parte ti ha radiografato, e tu non avevi la piu’ pallida possibilita’ di sapere cosa, come e quando: in quel caso non sapendo cosa lo stato legga e come, non riesci ad immaginare la strategia. Non riesci a sentirti “al sicuro”.
Ma qui mi sono visto dare risposte di un deludente incredibile: a parte il fatto che il PRA e’ a base provinciale, ogni provincia ha il proprio sistema e un formato diverso dei dati, il punto e’ che non basta che un sistema sia collegato in una rete perche’ sia possibile il datamining. Diciamo di voler controllare tutti i possessori di auto. (ma non cambia molto controllando tutte le partite IVA).
Allora, innanzitutto non possiamo presumere che alcune auto siano di lusso ed altre no: una Mini Minor non e’ lusso se e’ l’unica auto di una famiglia. Se e’ il regalo di compleanno di una figa di legno(TM) di 18 anni, il discorso cambia. Lo stesso dicasi se e’ auto aziendale o meno, se e’ di un’azienda a conduzione familiare o meno, e se la famiglia ha o meno altre auto. Cosi’, potremmo scrivere:
- Per ogni automobile registrata nel PRA
- Cerca l’intestatario.
- { Se e’ di una famiglia cerca all’anagrafe gli altri familiari.
- {In caso esistano altri familiari cerca se hanno altre auto.}
- Consolida il numero di auto ed il valore attuale per il nucleo familiare.}
- Se l’auto e’ di una societa’.{
- { Cerca alla CCAA se la societa’ possiede altre auto.}
- { Determina il tipo di societa’,
- Cerca l’elenco dei soci della societa’.
- cerca se i soci possiedano gia’ altre auto fuori dalla societa’.
- cerca la dichiarazione dei redditi della societa’.
- Cerca le dichiarazioni dei redditi dei soci
- cerca l’ EBT della societa’ al ministero}
- Confronta tra loro le dichiarazioni dei soci e verifica che siano analoghe.
- Confronta l’ EBT della societa’ con il valore di ammortamento dell’auto.
- Confronta il cash flow dichiarato dell’azienda con le spese standard per il mantenimento dell’auto.}
Ovviamente questo e’ piu’ o meno il controllo che avete in mente voi, non e’ detto che gli use cases siano solo questi, e neanche che sia cosi’ semplice da scrivere. Faccio presente che non ho incluso le query all’ INPS per capire se parliamo di pensionati o meno, le query all’ INAIL per capire se parliamo di invalidi, la query per stabilire se l’auto sia stata comprata nuova o usata, e cosi’ via. Chi ha programmato ha capito come procederebbe adesso il tutto sino a creare il batch, per tutti gli altri voglio fare qualche considerazione.
Se supponiamo 23 milioni di auto (anche una piccola partita IVA con la sua Smart , se la partita IVA e’ ufficialmente inattiva, e’ un evasore totale) , e consideriamo di avere una query ad un database per ogni parola “cerca”, otteniamo di avere 23×9 milioni di query, come minimo.
Ora, anche supponendo che TUTTI i database siano connessi e usando un’assunzione ottimistica che la query vada a buon segno e torni il risultato in 0.3-0.4 secondi, (se non altro per via delle latenze di una rete WAN molto disomogenea ) sono 72.45 milioni di secondi, cioe’ 838 giorni per terminare.
Ovviamente un tipo di considerazione del genere e’ molto forfettario, ma ci fornisce la misura del problema: centinaia di giorni. Ovviamente si potra’ lavorare in parallelo, e tutto quanto volete(1). Ma se la nostra base dati e’ sparpagliata per il paese, la cosa certa e’ che:
- Fatta X la durata complessiva di un batch, TUTTI i sistemi devono essere online almeno per X.
- Fatta Y la qualita’ del risultato che ci aspettiamo, TUTTI i sistemi devono garantire – a seconda del computo- una qualita’ che sia un qualche P(Y).
- DettoZ il batch, esso abbia senso in ogni regolamentazione locale della base dati stessa, ancora una proposizione su Z , P(Z).
Insomma, il semplice fatto che – se anche fosse vero che TUTTI i dati siano informatizzati ed online – un singolo batch confronti tot dati, significa che un errore ogni 9 (11%) e’ sufficiente a invalidare -statisticamente- OGNI ciclo. Per invalidarne il 20% e’ sufficiente molto meno , il 2% di errori. Se vogliamo avere delle percentuali di errore abbastanza basse da consegnare alla finanza un numero di 300.000 probabili evasori , dobbiamo garantire una qualita’ dell’accesso ai dati ed una qualita’ dei dati stessi che non scherza affatto, ed e’ ancora MOLTO distante dalla qualita’ con cui lavora la PA.
E’ possibile raggiungere una simile qualita’? Certo. Esistono le tecniche e le tecnologie? Certo: ma sicuramente NON su un sistema decentrato in 90 provincie, 800 anagrafi comunali, 90 uffici del registro, 90 PRA, 20 Database regionali della sanita’, 90 catasti, ognuno con una diversa tipologia di connessione in rete, la propria configurazione del firewall, la propria topologia di rete. Forget it!
Per raggiungere una simile qualita’ in tempi inferiori al secolo suggerirei innanzitutto di centralizzare la base dati. In tal modo si avra’ la certezza che semplici decisioni locali (legate a regolamenti del posto) non invalidino tutto il lavoro. Poi, occorrera’ standardizzare le procedure di inserimento dei dati e dei valori: nel catasto, per esempio, almeno i piani regolatori e uno standard per il valore al metro quadro e per quartiere che sia verificato anche per il passato.
Non si tratta di un risultato infattibile, ne’ sto dicendo questo: sto dicendo che per ottenere un risultato simile non basta che la base dati sia computerizzata e che sia online: occorre che le norme fiscali siano abbastanza congrue da poter scrivere il batch che spazzoli tutto l’imponibile: notate che io ho semplicemente calcolato le latenze di rete nel tempo di risposta delle query, e 800 giorni e rotti (piu’ di tre anni!) sono soltanto la somma delle latenze nella risposta alle query. Per calcolare il tempo totale occorre anche calcolare il tempo di esecuzione del batch, e se un programma deve ricalcare le normative, non e’ assai strano che impieghi altro mezzo secondo tra pescare dalle cache , file temporanei &co. (ovviamente e’ possibile ottimizzare, ma occorre un’esperienza che NON si ha nel tempo T0).
Un utente mi ha chiesto se non sarebbe possibile cominciare tutto da zero anziche’ produrre estenuanti migrazioni di dati. Probabile: occorre uno studio di fattibilita’ e di costi molto approfondito e dirlo ad occhio non sarebbe onesto, ma con ogni probabilita’ sarebbe meglio costruire un bel centro di calcolo e iniziare a far mettere “il nuovo” nel nuovo centro di calcolo, insieme a cio’ che in qualche modo viene cambiato (nel caso di societa’, variazioni scritturali di ogni tipo) costringendo ogni operatore locale a lavorare SOLO su quello, e alla fine dell’anno prossimo almeno avremmo una discreta “fotografia” del “nuovo” e di cio’ che e’ cambiato.
Considerando una “vita” media del primo possesso delle automobili di lusso piuttosto breve (5/7 anni) , una stabilita’ societaria un pochino piu’ elevata (10 anni) tra le variazioni, probabilmente in 5 anni avremmo sotto controllo quasi tutto il “nuovo” e una grossa fetta del “vecchio”. Ma vi faccio notare che parliamo di un lavoro che , ad occhio e croce, richiede un lustro solo per partire.
Se iniziamo a costruire il data center e a popolare il database oggi, cioe’, fra 5 anni potremo iniziare la vera caccia.
Come faccio ad essere sicuro che una cosa simile non esista?
Ecco il punto: me lo dice lo stato quando manda uomini di persona a fare i controlli.
Signori, detto come va detto, stimare gli affari di Cortina non e’ difficile: basta fare qualche controllo in bassa stragione ed in sordina, poi controllare il numero di cellulari collegati alle celle di Cortina, la quanita’ di rifiuti prodotta , la quantita’ di energia/acqua/gas consumati, la quantita’ di carburanti acquistata dai distributori del posto (che e’ controllata rigorosamente) e una stima forfettaria su tutta Cortina non e’ cosi’ difficile da fare: non mi serve mandare sul posto le persone per sapere che c’e’ un 75% di evaso, per una misura simile mi basta un campione statistico di pochissimi indicatori di sintesi.
Facendo cosi’, abbiamo detto agli evasori che una infrastruttura come quella che ho ipotizzato sopra non esiste, e quindi la probabilita’ di essere pizzicati e’ microscopica. Certo, 42 sono stati pizzicati: se consideriamo che la massa stimata di evasori sta sui 300.000, in pratica e’ piu’ facile che muoiano per il rimorso, o per un incidente avuto col SUV.
Cosi’ no, una lotta che abbia senso e che produca SOLDI per lo stato, dal momento che il problema dell’evasione e’ un problema di soldi, necessita di una infrastruttura centralizzata che garantisca una qualita’ alta dei dati e una disponibilita’ del sistema allo stato dell’arte, nonche’ una razionalizzazione delle norme fiscali che permetta di scrivere un batch razionale.
Altrimenti, il sistema di “controlli incrociati col calcolatore” ve lo sognate. E se considerate che ho fatto delle assunzioni MOLTO ottimistiche (0.3-0.4 su query con JOIN su grandi basi dati in sustained mode -latenze comprese- su una wan, etc(1) ) , potete immaginare la qualita’ dei dati e la qualita’ dei sistemi che occorre per avvicinarsi ad un simile risultato: occorre che i dati siano sempre aggiornati, che siano esatti al 99.7% come minimo, che sia standardizzato il valore degli immobili per un confronto, che sia standardizzato il costo delle auto usate, che siano standardizzati i costi di leasing delle auto, e cosi’ via.
Inoltre, faccio notare che non sto “progettando” proprio niente: sto semplicemente mostrando, evidenziandola, la differenza tra PENSARE un sistema informativo e REALIZZARLO. Pensarne le specifiche funzionali (“un sistema per fare verifiche incrociate tra possesso di auto e redditi”) e realizzarlo sono due cose MOLTO distanti. Non ho intenzione di discutere le specifiche tecniche di un simile sistema: ho solo voluto FAR PERCEPIRE gli ordini di grandezza e la complessita’, e quanto sia facile pensare un sistema rispetto a quanto sia difficile realizzarlo.
Uriel
(1) Bisogna stare attenti quando si e’ molto confidenti nel fatto di lavorare in parallelo sui database relazionali. Faccio notare che database Oracle abbastanza piccoli, (almeno rispetto a quelli che stiamo ipotizzando) , aumentare il numero di connessioni in parallelo puo’ produrre cose del genere:
| Concurrent Sessions |
Avg. Response Time (ms) |
Transactions Completed |
| 1 |
79 |
4,203 |
| 2 |
108 |
6,772 |
| 4 |
133 |
10,481 |
| 8 |
198 |
13,346 |
| 12 |
244 |
13,639 |
| 16 |
310 |
14,798 |
| 20 |
337 |
14,749 |
| 24 |
369 |
14,176 |
| 28 |
428 |
15,181 |
| 32 |
563 |
13,278 |
| 36 |
533 |
14,151 |
| 40 |
587 |
13,302 |
ovviamente sara’ possibile ottimizzare (indici, consolidated view , Oracle TimesTen , etc) questo database per funzionare meglio, anche se il risultato e’ difficile da interpretare. Tuttavia, e’ possibile se abbiamo UN database con UNA struttura. Se abbiamo un sistema decentrato in 90 provincie, 800 anagrafi comunali, 90 uffici del registro, 90 PRA, 20 Database regionali della sanita’, 90 catasti, dovremmo ottimizzarli tutti a seconda di come siano dimensionati, su che macchine girino, a seconda delle differenti configurazioni del database stesso, eccetera. In-fat-ti-bi-le.
