Data Warehousing for Dummies

DATA WAREHOUSING & BUSINESS INTELLIGENCE: ONLY FOR DUMMMIES ?
di Daniele Vanzanelli
Questo articolo tenta di sintetizzare le storture viste in qualche anno di vissuto professionale
nel campo dei sistemi di supporto decisionale (DSS).
Cercherò di riassumere la mia visione di questo mondo utilizzando una figura retorica molto
amata da chi si occupa di questioni filosofiche: il paradosso.
Cercherò di dimostrare come anni di evoluzione umana non abbiamo affatto migliorato le
cose ma le abbiano drammaticamente peggiorate e creato mostri notturni che hanno la
prodigiosa capacità di far sprecare danaro.
PARADOSSO I: della Tecnologia
La tecnologia va avanti, tutto il resto sta fermo immobile. Rispetto a 10-12 anni quando fare
un progetto di Data Warehousing & Business Intelligence rappresentava un’esperienza
catartica in quanto pionieristica, la tecnologia di supporto ha fatto incredibili passi avanti,
dal punto di vista delle performance, della facilità di utilizzo, dell’aderenza agli standard di
mercato e per certi versi anche del costo medio delle informazioni prodotte. Ciò che
assolutamente non ha fatto il salto di qualità è il modo in cui i sistemi DSS vengono
progettati e implementati, questo perché l’evoluzione della tecnologia viene considerata un
mezzo per fare progetti più veloci, non progetti migliori.
Nel fare le cose velocemente non c’è niente di male, anzi, il problema è che ciò che
contraddistingue il modo in cui le iniziative DW/BI vengono portate avanti non è la velocità,
ma la fretta. Fretta di generare risultati, fretta di ‘avere i numeri’, fretta di dimostrare che
‘non sono soldi buttati via’. Senza contare che progetti più corti consentono, a parità di
organico del team, di pagare meno i consulenti che altrimenti tendono per loro natura a
bivaccare in azienda (tanto poi tornano comunque perché non funziona niente!). Tanto per
capirci è come se voi diceste al chirurgo che deve operarvi al cuore: “Sono pienamente
cosciente che la durata standard per un’operazione di bypass è 8 ore, ma facciamo così,
invece di quattro bypass me ne metta due, così facciamo tutto in quattro ore, la pago meno e
torno a giocare a tennis in sei mesi invece di un anno!”. Recepito il messaggio ?
PARADOSSO II: del Project Management
Il Project Management è una scienza, non un’arte liberale.
I crimini che possono essere perpetrati ai danni del Project Management sono i seguenti
(Odoacre e Lattanzio sono personaggi di fantasia):
1 - Omicidio volontario
Statement: “siccome i progetti DW/BI sono ‘facili’ (?) il pm non serve, basta comprare gli
sviluppatori, la gestione del progetto la facciamo noi”.
Analisi del crimine: ritenere il project management una fastidiosa infrastruttura che non
aggiunge valore.
Conseguenze: il progetto va avanti per conto suo tra continue sterzate e correzioni dovute
all’inevitabile e perniciosa creatività degli ‘sviluppatori’ che, nonostante quanto ritenuto
dall’immaginario collettivo, sono esseri pensanti e raziocinanti con proprie opinioni, idee e
preferenze gastronomiche, e con un ego grande come il Nebraska.
Pena: andare da un odontoiatra a farsi fare una protesi dentaria; l’odontoiatra in assenza del
dentista farà di testa sua sulla base delle indicazioni del paziente.
2 - Omicidio colposo
Statement: “siccome Odoacre ha gestito 10 progetti ERP sarà sicuramente in grado di gestire
un progetto DW/BI”.
Analisi del crimine: ritenere che tutti i progetti IT siano uguali e che non ci sia differenza
alcuna tra implementare un package e sviluppare da zero un’architettura n-tier con logiche
di modeling peculiari e specifiche
Conseguenze: analisi multidimensionali, data mining e drill-down neanche a parlarne ma
report a valanghe ! Ah, dimenticavo: quadra !
Pena: distruggere il sistema frenante dell’auto e portarla al gommista per vedere se e come la
ripara.
3 - Omissione di soccorso
Statement: “siccome Lattanzio non ha alcuna competenza tecnica si occuperà della gestione
del progetto”.
Analisi del crimine: ritenere il project management un’attività priva di contenuti tecnici e
non richiedente competenze specifiche sulla materia del progetto.
Conseguenze: il novello e pivello project manager non vedrà e se li vedrà non capirà i
problemi ed i rischi insiti nel progetto.
Pena: farsi operare al cervello facendo dirigere l’equipe medica da un bambino di otto anni
con tendenze omicide.
4 - Falso ideologico
Statement: “chi ci vende il software gestisce il progetto”.
Analisi del crimine: confondere competenze di prodotto con competenze tecnologiche,
competenze funzionali e perché no ? competenze di gestione progetto.
Conseguenze: il progetto non esiste: inserire il cd e digitare d:\setup nella shell lo chiamate
fare un progetto ?
Pena: dopo che l’odontoiatra di cui al crimine 1 ha creato la protesi farsela ‘installare’ dal
suddetto.
PARADOSSO III: delle Competenze
Nel mondo della tecnologia viene sovente applicato il cosiddetto ‘Principio dell’Analogia
Estrema’ che nella sua formulazione più pura suona più o meno così: “Se non ce l’hai
inventalo e se non puoi inventarlo, crealo”. E’ così che come esperti di data warehousing e
business intelligence vengono riclassificati i seguenti profili professionali (tra virgolette ed in
corsivo il meccanismo perverso dell’Analogia Estrema):
DBA (Database Administrator): “questo sa lavorare con i database, il data warehouse è un
database quindi va bene”. Tanto per farvi capire è come pretendere che il medico sociale
(quello che entra in campo con la bomboletta magica quando i calciatori prendono un
pestone da un avversario) scenda in campo al posto del centravanti e segni tre goal.
Sviluppatori Oracle: “questo sa lavorare con i prodotti Oracle, quindi conosce Oracle DB, il
data warehouse è un database, quindi va bene”. Il dramma di certi vendor è che sono
conosciuti per una soltanto delle innumerevoli tecnologie che possiedono; per esempio
sapevate che il vendor di cui sopra (scelto per caso) ha anche un ERP, diversi ambienti di
sviluppo e una serie infinita di suite per tutto dal CRM alla gestione delle biblioteche ?
Sviluppatori C: “questo sa programmare, nel data warehouse c’è l’SQL che è un linguaggio,
quindi va bene”. Può funzionare a patto che gli spieghiate che le tabelle non sono quelle cose
che va a leggere con gli script ma oggetti che devono essere pensati, disegnati, creati,
riempiti e mantenuti.
Sviluppatori RPG: “questo sa, la conoscenza è tutto e nel data warehouse c’è la conoscenza
dell’azienda, quindi va bene”. Molto new age ma irrealistico.
Sviluppatori in genere: “questo capisce di computer, il data warehouse sta dentro un
computer, quindi va bene”. E’ un punto di vista molto tecnologico.
‘Esperti’ di controllo di gestione: “questo è esperto di reporting, nel data warehouse ci sono
i report, quindi va bene”. Questa cosa avviene sistematicamente nelle società di consulenza
direzionale, cioè quelle società che schifano la tecnologia per anni, poi quando nessuno le
paga più per produrre slide patinate, cominciano a occuparsene arrangiandosi con quello
che hanno.
Esperti di SAP FI/CO: “questo è esperto di controlling, il data warehouse serve per il controllo
di gestione, quindi va bene”. Questa cosa l’hanno fatta veramente tutti i system integrator
quando un ERP vendor ha lanciato la sua soluzione di business intelligence. Naturalmente vi
taccio il nome dell’ERP vendor.
PARADOSSO IV: del Ritorno sull’Investimento
In questo pazzo pazzo mondo dell’ICT ci sono ancora dei cavalieri senza macchia e senza
paura, veri alfieri della valutazione strategica e del bon ton manageriale che si illudono di
poter calcolare il ritorno sull’investimento di qualsiasi cosa.
Fortunatamente non sono tanti, altrimenti noi poveri consulenti saremmo finiti e non perché
non siamo capaci di calcolare il ritorno sull’investimento di un progetto di data
warehousing e business intelligence ma perché è impossibile. Solitamente sono gli stessi
che si sono incapricciati dell’ERP, del CRM o dell’e-business (ambiti applicativi dove il calcolo
del ritorno sull’investimento è un must ed è possibile), hanno fatto un bagno di sangue e
ora, con il capo cosparso di cenere, cercano di validare con il business case anche le loro
vacanze ad Alassio.
Vi risparmierò una serie di fandonie su come si fa un business case (sono sicuro che ne siete
capaci, ma avete cose più serie da fare) e vi illustrerò i motivi dell’impossibilità:
1. dimostrare che la qualità e la tempestività delle informazioni fanno vendere di più e
meglio è un azzardo, se il management di un’azienda non vale niente o vive nel
mesozoico e vuole il reporting su stampa cartacea ‘perché se lo vedo a video non riesco
a ragionare’ non c’è data warehouse che tenga. Quindi è inutile cercare correlazioni
(inesistenti, credete a me) tra il disporre di sofisticati sistemi di supporto decisionale e
gli indicatori di performance di un’azienda.
2. L’altra considerazione macroscopica su questo tema riguarda il tradizionale approccio
al calcolo dei risparmi indotti dalla sostituzione o introduzione di un qualsiasi sistema
informativo: il cambiamento della tecnologia migliora l’efficienza e l’efficacia dei
processi supportati. In parole povere il problema è cercare di dimostrare che
l’introduzione di un DSS porta ad una riduzione dei tempi del processo decisionale e
potenzialmente ad una riduzione del numero di decisori, oltre a migliorare l’efficacia
del processo stesso. Eviterò ogni commento a questo statement: fa già ridere da solo.