Vita da BI: ruoli e responsabilità nella Business Intelligence

Data la sua natura trasversale, non risulta intuitivo per un’azienda formare il giusto team per un progetto di Business Intelligence. Tale difficoltà è maggiore quanto estesi e complessi sono il progetto e l’azienda stessi.

Questa difficoltà si sviluppa su due differenti livelli, esplicabili con due differenti domande:

• Quali figure professionali vanno coinvolte in un progetto BI, e con quali responsabilità?
• Come vanno gestiti il lavoro e le comunicazioni fra le figure coinvolte in un progetto BI?

Ecco una rapida guida su quali sono i ruoli, le responsabilità e i metodi di organizzazione in un progetto di Business Intelligence.

Tradizionalmente la Business Intelligence è sempre stata una costola dell’IT, questo perché per fare la BI occorreva saperne di informatica.

Dogma: L’IT è il reparto più qualificato per “smanettare” coi dati. Gli utenti finali del Business non comprendono la complessità dei progetti di questo tipo.

Questa ideologia porta ad avere due distinti gruppi di professionisti coinvolti nel progetto. Da una parte c’è il Business nei suoi vari reparti funzionali – i cui dipendenti vengono indicati come blue men, forse per indicare il grado di nobiltà di cui si fregiano – guidato dal cosiddetto Business Project Sponsor. Dall’altra invece abbiamo l’IT – composto dai red men, in contrapposizione al colore blu, perché il rosso dà bene l’idea di come gli informatici si sporchino quotidianamente le mani di sangue – capitanato dal BI Solution Architect. Il primo determina cosa deve offrire la BI, ovvero di cosa ha bisogno il business; il secondo decide come costruirla, ovvero quali sono i requisiti e qual è la miglior soluzione.

Alle spalle del BI Solution Architect c’è un team ben strutturato, formato da più figure tecniche specializzate. Nulla vieta ad una singola persona di ricoprire più d’uno di questi ruoli. Il Model Designer definisce la struttura semantica finale (o modello) accessibile al Business per le sue attività di analisi. Tale modello non è che la fonte dati da cui leggono i report e le dashboard creati dal Visual Designer, dedito a rappresentare nella maniera più intuitiva, corretta e adatta le informazioni. Questo strato semantico poggia sul data warehouse, disegnato dal Data Architect – che ne decide struttura e nomi in un contesto rigorosamente globale, corporate (ricordate la terminologia unica e condivisibile?) – e caricato dall’ETL Specialist, che pone attenzione a temi quali le performance dell’ETL, il logging degli errori, l’auditing dei dati e il checkpointing del flusso. Ad assicurare la migliore infrastruttura di base ci pensa il DBA, che garantisce la velocità, l’affidabilità (reliability), la disponibilità (availability) e il recupero dei (vari) database, oltre al loro accesso da parte dei diversi utenti e gruppi.

Alle spalle del Business Project Sponsor, invece, ci sono gli utenti finali di business nei loro vari reparti aziendali.

Questo paradigma stravolge non solo il ruolo dell’IT all’interno dell’azienda, ma anche le competenze tecniche che il Business deve acquisire.

Dogma: L’IT deve avere esclusivamente un ruolo di helpdesking e di supporto operazionale e sistemistico. Il Business deve essere quanto più autonomo possibile nello sviluppare la BI.

Questa ideologia scarica l’IT dall’onere di dover sviluppare per intero lo stack BI: la Business Intelligence è un progetto che potenzialmente può non avere mai fine, e per molte aziende è dispendioso occupare gran parte del tempo dell’IT in progetti trasversali come questo. Al contempo, incarica gli utenti di business di formarsi permettendo loro di sviluppare da sé ciò di cui hanno bisogno, secondo le proprie regole funzionali. Questi utenti, produttori oltre che consumatori di dati e quindi non più solo utenti finali, vengono chiamati Data Analyst. A supervisionare la qualità, gestione e distribuzione del dato aziendale ci pensa il Data Steward, vero e proprio collante umano fra le varie figure aziendali convolte nelle attività di creazione del dato, trasformazione dello stesso ed utilizzo dell’informazione così generata. Non si parla più quindi di red men e blue men, ma di purple people. Ma non è mai banale formare gli utenti di business in competenze tecniche: spesso sono proprio loro i primi a non volersi addentrare in certe dinamiche. Questo è lo scenario dove si fa più necessaria l’adozione della cosiddetta self-service BI, ovvero una BI non centralizzata all’IT, ma distribuita nei vari business.

In questo tipo di organizzazione, ci si sporca un po’ tutti le mani assieme. Il Business mantiene un certo potere decisionale e un certo livello di autonomia, ma è seguito, consigliato e supportato costantemente dall'IT. L’entità di intervento dell'IT è maggiore – e fondamentale! – nelle prime fasi del progetto, poi diminuisce gradualmente, non raggiungendo mai lo zero.

Qui si ha una duplicazione di alcune figure descritte nell'approccio IT-driven: in particolar modo, il Model Designer e il Visual Designer trovano un loro corrispettivo nei vari reparti di business dell’azienda. Ovviamente, ruoli fortemente tecnici come l'ETL Specialist e il DBA rimangono esclusiva dell'IT. Questa è una soluzione che ben si sposa con la decisione di un’azienda di optare per consulenti BI esterni, in quanto solleva l'IT da oneri eccessivi ed ottimizza il tempo del Business che sarà affiancato, solo quando necessario, da esperti del settore. Ed è sempre qui che spicca al meglio la figura del BI Analyst: un purple man con le tutte abilità necessarie dei due mondi IT e funzionale, capace di comunicare con tutti al giusto livello di dettaglio e tecnicismo. In questo tipo di regime, la self-service BI è adottata ma con tono moderato.

iassumiamo in una tabella le principali caratteristiche di ciascuna tipologia di team BI: