Sono un consulente di BI, non un informatico
In questo articolo affronterò un tema molto sentito per me e per molti altri consulenti di Business Intelligence.
Molti consulenti di BI hanno un backaground economico o ingegneristico (io ad esempio ho studiato ingegneria gestionale), eppure si ritrovano per lavoro a scrivere codice e programmare software (anche molto complessi).
E allora la domanda sorge spontanea, il consulente di BI è un informatico? Proverò a rispondere a questa domanda con la mia personale visione durante questo articolo.
Se non vuoi perderti i prossimi aggiornamenti, lasciami qui la tua mail migliore
Cosa fa un consulente di BI
Un consulente di Business intelligence utilizza software chiamati DWH per raccogliere, analizzare e aggregare dati.
Il risultato finale del suo lavoro consiste in report e dashboard che permettono ai manager di avere informazioni chiave sull’ andamento della propria azienda e prendere decisioni migliori.
La BI quindi è un processo che attraversa in maniera trasversale tutte le funzioni aziendali mettendo in relazione dati di reparti differenti con l’obiettivo di fornire un quadro d’insieme dell’azienda.
Proprio perché è una figura trasversale, è fondamentale che sia in grado di conoscere le principali logiche funzionali e dei principali processi aziendali presenti nei dipartimenti più disparati.
Fasi di un progetto di BI
Un progetto di BI prevede varie fasi che partono dalla raccolta dei requisiti, ossia dal mapping delle esigenze dei vari attori aziendali, fino al rilascio dei report richiesti.
Farò una panoramica di tutte queste fasi per scoprire in quali fasi si tratti di un lavoro “informatico” e se esiste anche altro oltre a questo.
Per semplificare questo viaggio immaginario lungo tutta la vita di un progetto, proporrò un esempio legato alla reportistica di credito di un’azienda e vedremo come questa venga concepita fase dopo fase.
Pertanto nei paragrafi che seguono ci sarà sempre un box con l’evolversi di questo esempio.
Andiamo a vedere quindi le fasi di un singolo progetto.
Raccolta dei requisiti
Questa è la prima fase in cui il consulente di BI intervista i responsabili dei principali dipartimenti per capire quali siano le loro esigenze e mappare tutti i fabbisogni.
In questa fase il consulente potrebbe non conoscere i processi funzionali presenti in quella specifica area aziendale e pertanto è suo compito cercare di ricavare più informazioni possibili sia sulle necessità di reportistica richiesta che sul “funzionamento” dei principali processi.
Si tratta di una fase di alto livello in cui non si scende troppo nel dettaglio, tuttavia è importante per perimetrare le necessità ma anche per iniziare a capire le logiche del dipartimento di interesse.
In questa primissima fase il consulente ha come interlocutore una persona non tecnica che quindi non conosce le logiche informatiche né la struttura del DB.
Tuttavia queste persone hanno una visione funzionale del processo, il che è fondamentale. Conoscono il perché hanno bisogno di quei dati, cosa significhino quei dati e come questi dati si originano.
Esempio di raccolta di requisito
Raccolta del requisito
Se ad esempio si dovesse effettuare una reportistica riservata al reparto credito di un’azienda, in questa fase il referente dell’area potrebbe dirci che è interessato a conoscere il credito aperto e scaduto. Inoltre potrebbe essere interessato a conoscere l’anzianità di questo credito.
Analisi funzionale dei requisiti
Completata la fase di intervista, il consulente inizia ad analizzare la richiesta per effettuare uno studio di fattibilità e definire una strategia implementativa.
Come visto nella fase precedente, abbiamo a questo punto richieste molto generiche e poco contestualizzate.
Ovviamente non sono sufficienti per partire con gli sviluppi e questo perché non sempre si conosce il processo funzionale che conduce ai dati di interesse e perché poi bisogna contestualizzare tali dati all’interno dell’infrastruttura tecnica dell’azienda.
Ma andiamo per gradi.
Al momento il nostro povero consulente sa solo che deve monitorare il credito e la relativa anzianità. Non è detto, tuttavia che sia un esperto di gestione del credito e pertanto deve per prima cosa approfondire il significato funzionale della richiesta.
In questa fase subentra l’analista funzionale, che è la persona esperta di quello specifico ambito funzionale e che è in grado di contestualizzarlo anche in relazione al data base e la struttura informatica dell’azienda.
Esempio di analisi funzionale del requisito
Analisi funzionale del requisito
Sappiamo che il risultato finale deve essere quello di fornire un report sull’anzianità del credito aperto.
Il ruolo dell’analista funzionale è quello di spiegare al consulente di BI che per credito aperto si intendano tutte le fatture NON pagate.
L’anzianità si valuta confrontando la data di scadenza di quella fattura (ossia il momento entro il quale andava pagata) rispetto ad oggi e che qui sorge una complicazione perché esiste il processo di rateizzazione per cui una fattura viene pagata a rate.
Ogni rata ha un importo ed una data scadenza diversa rispetto alla fattura originaria.
Inoltre l’analista sarà in grado di dirci in quale tabella del DB si trovano le rate, in quale tabella l’informazione rispetto al pagamento ecc.
PS: fortunato il consulente che ha sempre a disposizione un esperto funzionale del settore specifico che sia in grado di farlo addentrare nei processi. Nella mia esperienza (puoi leggere qui qualcosa di più su di me) è successo molto di rado, e nella stragrande maggioranza dei casi questa contestualizzazione è in carico al consulente di BI.
In questo caso lo step dell’analisi funzionale e tecnica assumono confini abbastanza labili.
Analisi tecnica del DB sulla base dei requisiti raccolti
Tralasciamo il mio post scriptum dello step precedente ed immaginiamo che qualcuno abbia informato il consulente BI di tutte le dinamiche riportate precedentemente.
Siamo arrivati ad una situazione in cui non si ha ancora una visione tecnica del processo ma abbiamo capito e contestualizzato la richiesta.
Sappiamo quali dati cercare e che informazioni abbiamo necessità di estrarre da questi dati.
A questo punto inizia la fase tecnica del processo.
Il nostro amico consulente di BI inizierà ad aprire le tabelle del data base che gli sono state indicate e proverà a capire come metterle in relazione.
Cercherà di individuare eventuali customizzazioni apportate al database per capire se ci sono ulteriori logiche da tenere in considerazione e proverà ad effettuare “un giro completo” con dei casi di test.
In altre parole prenderà un caso a campione e proverà a vedere se tutti i legami tra le tabelle che ha individuato sono corretti e si riesce a desumere l’informazione necessaria.
Esempio di analisi tecnica
Analisi tecnica del DB
A questo punto il consulente sa che le partite di credito si trovano nella tabella DFKKOP, che il fatto che una fattura sia stata rateizzata si individua mediante uno specifico campo e che grazie a questo campo può risalire a tutte le rate del piano rata.
Sa inoltre come si individua se una partita è pagata o è aperta e in quale tabella viene riportata questa informazione.
Ha capito inoltre che nel caso in cui una fattura sia stata rateizzata, non dovrà guardare la fattura originaria ma dovrà seguire il pagamento e la scadenza delle singole rate e ha appurato che a lui interessano solamente le partite già scadute e non pagate.
Approfondimenti funzionali
In un mondo ideale, ormai il consulente ha a sua disposizione tutte le informazioni necessarie per poter lavorare in autonomia.
Nella realtà però molto spesso si accorge che ci sono alcuni dettagli di cui ha bisogno di discutere ancora con chi conosce il processo.
Per questo motivo si interfaccerà nuovamente con il referente del processo, la persona che gli ha fornito il requisito (ossia la richiesta), la persona non tecnica e che non conosce (né è tenuta a conoscere) le tabelle del database e i loro legami.
In questa fase il nostro consulente deve essere riuscito a capire e conoscere il processo funzionale, deve essere riuscito a capirne le ricadute tecniche e per poter porre le domande corrette deve riuscire a tradurre i propri dubbi tecnici in domande funzionali.
Non potrà chiedere al referente del processo se vanno considerate le righe della tabella contraddistinte dal fatto che uno specifico campo abbia un valore o meno.
Deve, invece, chiedergli se a livello funzionale abbia senso considerare i crediti relativi ad utenze che hanno un blocco al sollecito (se non sei un esperto di credito probabilmente non sai cosa abbia blaterato, ma lo spiego nell’esempio che segue).
Esempio di approfondimento del requisito
Approfondimenti funzionali
Il nostro consulente, mentre analizzava le tabelle, si accorge che ci sono utenti che da mesi non stanno saldando delle fatture. Tuttavia l’azienda non effettua procedure di recupero del credito nei confronti di questi utenti.
Si accorge che questi utenti sono contraddistinti dal fatto che in uno specifico campo di una specifica tabella ci sia una ‘X’. Quel campo è il campo “blocco al sollecito”.
Scopre che ci sono situazioni funzionali per cui un utente non può ricevere solleciti al pagamento (ad esempio perché ha contestato una fattura).
Capisce che probabilmente le fatture che riconducono a quel campo valorizzato ad “X” non debbano essere considerate ma non è sicuro.
Ne deve parlare con il referente di business, ma non può certo chiedergli se escludere quelle X. Deve chiedergli invece se gli interessi considerare o meno anche i blocchi al sollecito
Disegno del/dei modelli dati da implementare
Fino ad ora abbiamo visto come in tutte queste fase ci sia una parte molto importante di analisi funzionale del processo.
Questo è fondamentale ed imprescindibile perché il nostro consulente deve sapere cosa fare con quei dati e come utilizzarli.
Finalmente ha a disposizione tutte le informazioni per lui necessarie e può iniziare una fase molto più tecnica del suo lavoro.
È il momento di creare la strategia di implementazione, di definire cioè cosa farà tecnicamente per fornire le informazioni necessarie.
Questa è ancora una fase di analisi, in cui però il consulente dovrà ragionare su quali strumenti tecnici a sua disposizione utilizzare e come utilizzarli.
Qui entriamo nel tecnico vero e proprio (la parte che potremmo definire “informatica). Il nostro amico dovrà capire che strutture dovrà creare, come alimentarle e metterle in relazione tra loro.
In questa fase e nelle prossime non voglio annoiarvi con l’esempio tecnico, quindi passiamo direttamente alla prossima fase,
Implementazione tecnica della soluzione
Il consulente sa finalmente tutto quello che deve fare e come farlo. È arrivato il momento di trasformare il disegno della soluzione in realtà
In questa fase dovrà conoscere molto bene il codice, il funzionamento di uno star schema ( se non sai cosa significhi star schema leggi qui la spiegazione di Wikipedia ) e le particolarità di ogni oggetto tecnico a sua disposizione.
Qui deve “lavorare da informatico” anzi da bravissimo informatico se vuole davvero riuscire a realizzare un prodotto che sia utilizzabile e soprattutto utile per chi ha richiesto questa reportistica.
Fase di test e rilascio della funzionalità
Questa è la fase finale in cui finalmente tutto è pronto e funzionante.
Mostrerà al referente del reparto credito come funzioni la soluzione, effettueranno dei test insieme e da oggi in poi il referente del credito con pochi click potrà conoscere sempre la situazione aggiornata del credito dell’azienda.
Tutto è bene ciò che finisce bene.
Conclusioni
Il consulente di BI è un informatico ma….
Abbiamo finalmente capito in maniera molto precisa in cosa consista il lavoro del consulente BI
Abbiamo detto che il suo obiettivo è quello di aggregare dati per trarne informazioni.
Per farlo utilizza dei software (più o meno complessi ed evoluti) atti proprio alla manipolazione e la storicizzazione dei dati. Questi software prendono il nome di Data Warehouse (DWH).
I DWH sono una particolare tipologia di Database che ha l’unica funzione di aggregare ed analizzare i dati.
Il consulente di BI dovrà quindi avere delle forti competenze di programmazione ed una nutrita conoscenza del software che utilizza.
Pertanto potremmo dire che è un lavoro informatico?
Sicuramente si perché qualsiasi consulente di BI deve essere in grado di interrogare una tabella, di scrivere alcune righe di codice e di saper utilizzare gli strumenti informatici a sua disposizione.
Ma gli aspetti informatici e tecnici da soli non bastano, anzi! Diciamo che rappresentano solamente la metà delle skills necessarie per svolgere questa professione.
L’informatica da sola non basta
La natura stessa della consulenza presuppone che nell’arco del tempo ci si trovi a lavorare con clienti molto differenti tra loro (io ad esempio ho lavorato con aziende in moltissimi settori, dalle telecomunicazioni, all’alta moda, alla vendita e produzione di caldaie e condizionatori, all’utility che si occupano della gestione dell’energia elettrica e del gas ecc).
Bisogna inoltre aggiungere che ogni grande azienda ha al suo interno molti dipartimenti differenti con logiche intrinseche molto differenti tra loro tra cui ad esempio:
- La fatturazione
- L’HR
- Il reparto di approvvigionamento dai fornitori ecc
Ognuna di queste situazioni porta il consulente di BI a dover entrare nei processi aziendali, immergendocisi completamente, e diventarne un vero esperto.
Perché?
Perchè vuole essere in grado di mettere in relazione tra loro dati provenienti da processi diversi e dare informazioni corrette. Per farlo deve conoscere come quei dati si originano, il processo sotteso a quei dati e come possono integrarsi ad altri dati.
Per questo motivo è indispensabile che oltre ad una buona dose di conoscenze tecniche si acquisisca una capacità di analisi dei processi funzionali.
Voglio chiudere questo articolo con un esempio molto semplicistico per spiegare la mia visione della BI.
Pensare di fare BI conoscendo solo gli aspetti tecnici e informatici sarebbe come voler fare un viaggio, avere una Ferrari in garage e non avere la minima idea della strada da percorrere.
Si può provare a guidare a caso, ma la verità è che non andremo mai nella direzione giusta né arriveremo mai a destinazione
Sono un consulente di Business Intelligence,lavoro con uno dei software di Business Intelligence più importanti e completi sul mercato che è SAP BW (da poco diventato BW4HANA), e ho avuto modo di lavorare con grandissime realtà nazionali ed internazionali.
In tutte queste realtà ho avuto modo di entrare nella vita aziendale conoscendone i processi, i problemi, e le necessità e di relazionarmi con key user, decision maker, manager e personale operativo per riuscire a costruire report e dashboard che facilitassero il loro lavoro e permettessero in pochissimi click di ottenere tutte le principali informazioni sull’andamento della società.
Ho iniziato a fare divulgazione sul tema Business Intelligence per spiegare anche ai non addetti ai lavori quanto sia importante ragionare sempre in funzione di dati e come sfruttare la tecnologia per prendere decisioni migliori.
Le informazioni hanno un valore inestimabile e sono la cartina al tornasole di qualsiasi business mentre i dati da soli sono solo numeri!
