Bi: il nemico è all’interno? Sviluppare una soluzione di Business intelligence coinvolge processi e persone in modo trasversale. Attenti, però, a non perdere di vista il risultato finale
Negli attuali scenari di business diventa fondamentale per un’azienda disporre degli strumenti giusti per operare le proprie scelte in modo corretto. La possibilità di fare una fotografia dello stato (e del prossimo futuro) dei principali indicatori on demand costituisce un elemento in grado di fornire una visione precisa dell’andamento societario.
Il processo con cui si sviluppa una soluzione di Business intelligence rappresenta un insieme di tecnologia, analisi, pubblic relation, project management e profonda conoscenza del business aziendale in grado di mettere alla prova più di un Cio.
Nel momento in cui si inizia a parlare di sistemi di reportistica o di Bi, è importante cercare di far capire le implicazioni, positive e negative, di un progetto del genere in modo che la scelta sia condivisa, e supportata, dai vari settori e dalla direzione.
Mentre l’aspetto tecnologico diventa un elemento economico, funzione della dimensione del progetto, gli obiettivi che si vogliono perseguire devono essere ben definiti in termini di numeri, tempo e risorse coinvolte. Una volta chiarito quanto profondamente e trasversalmente il progetto debba spingersi, è opportuno organizzare un incontro con i responsabili dei settori coinvolti in modo da iniziare a dettagliare requisiti e aspettative. Nell’arco di successivi colloqui, che coinvolgono sia il settore It che le singole aree, si inizia a delineare un documento che evidenzia le sorgenti dati coinvolte, come queste interagiscono con i processi decisionali, quali sono gli indicatori di performance principali e come le informazioni dovranno essere rese disponibili agli utenti finali.
Non è raro trovare uffici restii a delegare l’analisi dei dati del proprio settore. In assenza di procedure automatizzate, infatti, può diventare semplice “addomesticare” i numeri, spostando in avanti o nel passato le informazioni. In questi casi è fondamentale godere di un pieno e manifesto appoggio della direzione, per non impantanarsi in rinvii, dati incompleti e scarsa collaborazione, che possono minare la buona riuscita del sistema di Bi.
Una volta completato e condiviso, il documento di progetto può essere utilizzato come specifica per la redazione delle offerte da parte dei fornitori, in modo di ricevere proposte realistiche in termini di costi, tempi e prerequisiti infrastrutturali.
Scelte ponderate
Per determinare il giusto fornitore, l’esperienza specifica in materia gioca un ruolo importante. Errori metodologici o semantici nella trasposizione delle specifiche nel datawarehouse possono portare a dati inconsistenti, difficilmente manutenibili nel tempo e poco flessibili nella fruizione. Un partner che ha già affrontato diversi progetti sarà più preciso nella stima dei giorni uomo e più collaborativo durante la fase realizzativa con consigli pratici rispetto alle richieste di partenza. Può essere utile organizzare un kick off meeting per chiarire alle persone coinvolte i rispettivi ruoli e competenze all’interno del progetto, le scadenze previste e i risultati attesi.
Molto positivo, durante il procedimento di implementazione, sarebbe riuscire ad affiancare quanto più possibile lo staff It che ha in carico la manutenzione e l’evoluzione del datawarehouse, in modo da sfruttare ogni fase come training on the job e per documentare tutti i passaggi dati in modo dettagliato.
I problemi maggiori che si possono incontrare durante questa fase operativa si legano principalmente all’accesso alle varie fonti dati aziendali all’interno del data mart e alla relativa trasformazione. Se gli import da database di cui si conosce la struttura tendono a non essere critici lo stesso non si può dire per flussi dati provenienti da sistemi legacy, soprattutto se prodotti ad hoc per il datawarehouse. Errori nella documentazione del fornitore o bug nella composizione dei flussi di dati possono comportare notevoli perdite di tempo e di risorse. Nella riconciliazione dei dati, poi, non va escluso il fatto che il dato errato possa essere quello dei “vecchi” report e non quello del datawarehouse.
Una volta che i dati quadrano e i sistemi automatici di alimentazione e import funzionano, va anche previsto un congruo periodo di test: rilasciare il sistema prima del tempo rischia di tramutarsi in un boomerang dando argomenti a chi volesse deleggittimare la veridicità dei numeri prodotti a vantaggio dei metodi tradizionali.
I principali data base includono strumenti per l’accesso via Web o l’invio automatizzato per posta elettronica di report preconfigurati, mentre sfruttando le potenzialità di accesso ai cubi Olap presenti in Excel e altri software di produttività personale si riesce a dare viste configurabili direttamente dall’utente.
In base ai differenti profili di accesso e visualizzazione dei dati, bisogna impostare un piano di training per gli utenti finali spendendo anche del tempo in più per ogni persona in modo da spiegare chiaramente in che modo i dati confluiscono nel datawarehouse, a che ora vengono processati, come sono correlati i fatti e le dimensioni dei cubi Olap e quali sono gli strumenti a disposizione per l’analisi.
Rilasciato, a questo punto, il sistema di Bi servono, comunque, alcuni mesi prima che dalle riunioni spariscano domande sull’attendibilità dei numeri oltre a spiegazioni sul perché i dati del nuovo trimestre sono così diversi da quelli degli anni prima.
