Progetti di Business Intelligence vincenti: come iniziare

Desidero raccontarvi il mio punto di vista su come affrontare un progetto di BI cercando di farlo diventare un successo.

L’ambito di analisi

Come prima cosa bisogna definire quale sarà l’ambito di analisi (vendite, logistica ecc.) da cui iniziare, delimitare l’ambito permetterà anche di definire degli obiettivi da raggiungere in tempi ragionevoli.

I dati

Sembrerà banale ma, definito cosa si vuole analizzare, bisognerà che i dati esistano e siano estraibili per poterli poi modellare nel nostro datawarehouse.

L'utente ''principe''

Deve esistere un utente business che sia il punto di riferimento del progetto, è sempre buona cosa che sia una persona che ami i numeri giusti e che sia disponibile per effettuare le quadrature tra dwh e ERP e possa dare una mano nella ricerca delle differenze. Altra cosa importante deve essre una persona con voglia di raggiungere un qualcosa oltre a quello che ha già in mano, non possiamo pensare a un progetto di dwh come un qualcosa che replichi l’esistente in una forma differente.

Chi farà il progetto?

Beh qui penso che le scelte siano abbastanza obbligate se l’IT ha le persone in casa con gli skill adatti (principalmente sviluppo su DB) potrebbere essere uno spreco chiamare un fornitore esterno, ma visto che fare BI come ho già scritto non è solo un lavoro di programmazione e scrittura di procedure SQL, secondo me è buona cosa affidare la parte di analisi, modellazione e magari coordinamento del progetto a una persona anche esterna con provata esperienza di progetti di BI.
Se vi affidate a un fornitore esterno, al netto di quanto detto nei primi articoli, penso che la scelta debba ricadere su quanto più simile alla vostra realtà, se siete una PMI magari più Piccola che Media, potrebbe aver senso affidare il tutto a uno o due consulenti libero prof (1 lato DB, 1 lato reporting). Una classica software house comunque metterebbe in campo le stesse forze con in più dei contorni che comunque dovrete pagare in più (struttura aziendale, figure junior, project manager ecc.).
Se siete una azienda più strutturata allora ha senso essere seguiti da un’azienda che possa farsi carico del progetto.

Scelta del software

Al netto di realtà che hanno database importanti (verso i miliardi di record) dove è meglio scegliere qualcosa di specifico per la BI magari anche con una integrazione con l’hardware (le varie appliance che stanno nascendo) in tutte le altre realtà lasciate che sia l’IT interno a scegliere il DB.
Per quanto riguarda il software di query, analisi e reporting o quello che volete qui innanzitutto bisogna definire cosa vorrete fare con il dwh. Le domande bivio sono:

• Voglio anche poter stampare in un formato almeno decente?
• Voglio che gli utenti possano creare da zero in maniera molto semplice tutte le loro query che necessitano? Oppure preferisco che sia qualche persona dedicata (IT o meno) che vada a costruire quanto necessario?
• Quale complessità possono raggiungere le query che voglio creare?
• È più importante la navigabilità dei dati e la ricerca di ciò che si nasconde nei dati (Data Discovery) o la possibilità di fare query per estrarre i dati e/o stamparli?
• Voglio qualcosa accedibile via web o mi basta un client/server? Possibilità di lavoro offline?
• Serve distribuire del reporting a vari utenti magari via mail (schedulando) o mobile?
• Quanto è importante la possibilità di costruire delle dashboard dinamiche per presentare i dati?

Personalmente penso che ogni tool di BI possa avere dei punti di forza o di debolezza nel rispondere alle domande di cui sopra; non esiste, secondo me, quello che raggiunge il massimo in ognuna delle caratteristiche elencate.
Quindi definite bene cosa deve fare e chiede di poter vedere un qualcosa di mirato per rispondere alle vostre richieste, e non solo la solita demo dove comunque sia tutti i tool sono belli e luccicanti.

Analisi

Una volta definito che cosa si vuole, si può partire con l’analisi che tendenzialmente si va dividere in queste fasi:

• Definizione degli user requirements con intervista degli utenti per capire le necessità di analisi e anche il specificità del business
• Disegno di fatti e dimensioni: uno degli output delle interviste è anche un documento dove verranno elencati fatti (con le principali misure) e dimensioni (con le principali gerarchie e/o attributi) che comporranno il o i nostri datamart
• Mappatura dei datasource, conoscendo cosa vogliono gli utenti si potrà verificare con l’IT se e dove esistono i dati richiesti, siano essi su database, file xls o dati non strutturati (che tanto vanno di moda) e come andare a reperirli (frequenza e metodo)
• Definizione della finestra di refresh: prima di spiacevoli equivoci è sempre importante definire ogni quanto bisogna aggiornare i dati, a che ora i dati devono essere pronti “all’uso” e da che ora il dwh può iniziare le sue procedure di caricamento. Questi parametri saranno importanti per poter definire altre cose tipo l’hardware necessario per soddisfare i tempi di caricamento oppure una proposta differente di caricamento (demandare dei refresh al weekend, caricare solo i delta ecc.)

Modellazione dei dati

Potremmo vedere la modellazione dei dati come un output dell’analisi, ma preferisco separarla anche perchè essendo il momento topico è giusto che abbia il suo spazio
È fondamentale che a fine della modellazione ci sia un confronto con gli utenti finali per spiegargli cosa si troveranno e simulare “sulla carta” delle possibili analisi richieste.

Sviluppo della parte database del datawarehouse

Al netto dei vari tecnicismi su come sviluppare tutti i flussi di ETL ecc. penso che sia importante puntualizzare una cosa importante, ovvero il coinvolgimento degli utenti nella verifica di quanto in fase di sviluppo. Una cosa che mi piace fare è creare le dimensioni e il fatto con degli script abbastanza hard-coded, che poi utilizzerò come base per le procedure, per poter avere delle tabelle “toccabili” e coinvolgere subito gli utenti per poter vedere tramite il tool di reporting, o fosse anche con una query che mi estra su Excel per fare delle pivot, cosa avranno in mano a fine progetto, in quel momento si prova a giocare e creare delle query “a richiesta” degli utenti per vedere se tutta la modellazione sta in piedi.

Metadati

Per tutti quei tool di reporting dove è previsto uno strato di metadati, è importante confrontarsi con l’utente per definire i nomi corretti e parlanti di ogni oggetto: non c’e’ nulla di peggio per un utente di vedere oggetti che non gli dicono nulla, è come se tali dati non esistessero.

Sviluppo del reporting

Siamo alla prova del nove con la costruzione di quanto richiesto: potremmo essere tentati di partire con dashboard e report che fanno vedere tutto il valore del dwh ma forse la cosa migliore, più saggia, è partire replicando dei report in essere in modo da poter fare le quadrature e permettere agli utenti di acquistare fiducia nel nuovo strumento. Per migliorare c’è sempre tempo.

Formazione degli utenti

Coinvolgere e formare gli utenti; utenti attivi determinano il successo del progetto con espansione a nuove aree di analisi ecc. Utenti poco attivi faranno in modo che il progetto perda di valore e importanza.

Beh i punti sono undici come i giocatori di una squadra di calcio… adesso però non chiedetemi con quale schema metterli in campo!