Business Intelligence (BI)

BI (Business Intelligence) si riferisce a una categoria di enterprise software dedicata alla produzione di report analitici basati principalmente sui dati transazionali raccolti attraverso i vari sistemi aziendali utilizzati dall’impresa per operare. BI è concepita per offrire capacità di reportistica self-service agli utenti che non sono specialisti IT. Queste capacità self-service possono spaziare dalla regolazione dei parametri dei report esistenti fino alla creazione di report del tutto nuovi. La maggior parte delle grandi aziende dispone di almeno un sistema BI in funzione sopra i propri sistemi transazionali, che frequentemente include un ERP.

Origine e motivazione

Il report analitico moderno emerse con i primi previsori economici^{1 2}, prevalentemente negli USA, all’inizio del XX secolo. Questa prima iterazione si rivelò estremamente popolare, ricevendo l’attenzione della stampa mainstream e una vasta diffusione. Tale popolarità dimostrò l’interesse marcato per report quantitativi ad alta densità informativa. Negli anni ‘80, molte grandi aziende iniziarono a conservare le loro transazioni aziendali come documenti elettronici, memorizzati in database transazionali, sfruttando tipicamente alcune delle prime soluzioni ERP. Queste ERP erano destinate principalmente a snellire i processi esistenti, migliorando produttività e affidabilità. Tuttavia, molti compresero l’enorme potenziale inespresso di questi record e, nel 1983, SAP introdusse il linguaggio di programmazione ABAP ³, dedicato alla generazione di report basati sui dati raccolti all’interno stesso dell’ERP.

Tuttavia, i sistemi di database relazionali, come tipicamente venduti negli anni ‘80, presentavano due limitazioni principali per quanto riguarda la produzione di report analitici. In primo luogo, la progettazione dei report doveva essere affidata a specialisti IT altamente qualificati. Ciò rendeva il processo lento e costoso, limitando severamente la varietà di report che potevano essere introdotti. In secondo luogo, la generazione dei report risultava molto gravosa per il hardware di calcolo. Generalmente, i report potevano essere prodotti solo durante la notte (e in batch), quando le operazioni aziendali erano cessate. In un certo senso, ciò rifletteva le limitazioni dell’hardware dell’epoca, ma evidenziava anche i limiti del software.

All’inizio degli anni ‘90, i progressi nell’hardware di calcolo permisero l’emergere di una diversa classe di soluzioni software ⁴, soluzioni di Business Intelligence. Il costo della RAM (memoria ad accesso casuale) era costantemente in diminuzione, mentre la sua capacità di storage era in continuo aumento. Di conseguenza, memorizzare una versione specializzata e più compatta dei dati aziendali in memoria (in RAM) per un accesso immediato divenne una soluzione praticabile, sia da un punto di vista tecnologico che economico. Questi sviluppi affrontarono le due principali limitazioni dei sistemi di reportistica implementati un decennio prima: le nuove interfacce software front-end erano molto più accessibili ai non specialisti; mentre i nuovi back-end software – caratterizzati da tecnologie OLAP (discusso di seguito) – eliminarono alcuni dei maggiori vincoli IT. Grazie a questi progressi, verso la fine del decennio, le soluzioni BI divennero diffuse tra le grandi aziende.

Con il continuo progresso dell’hardware, emerse una nuova generazione di strumenti BI ⁵ verso la fine degli anni 2000. I sistemi di database relazionali degli anni ‘80, incapaci di produrre report in modo agevole, divennero, negli anni 2000, sempre più capaci di contenere l’intera cronologia transazionale di un’azienda in RAM. Di conseguenza, complesse query analitiche potevano essere completate in pochi secondi senza un back-end OLAP dedicato. Così, l’attenzione delle soluzioni BI si spostò verso il front-end, offrendo interfacce utente web ancora più accessibili – prevalentemente in modalità SaaS (software-as-a-service) – e dashboard sempre più interattive che sfruttavano la versatilità del back-end relazionale.

OLAP e cubi multidimensionali

OLAP sta per online analytical processing. OLAP è associato alla progettazione del back-end di una soluzione BI. Il termine, coniato nel 1993 da Edgar Codd, raccoglie una serie di idee di progettazione software ⁶, per la maggior parte antecedenti agli anni ‘90, alcune delle quali risalenti agli anni ‘60. Queste idee progettuali furono fondamentali per l’emergere della BI come classe distinta di prodotti software negli anni ‘90. OLAP ha affrontato la sfida di produrre report analitici aggiornati in tempi brevi, anche quando la quantità di dati coinvolti nella loro produzione risultava troppo grande per essere elaborata rapidamente.

La tecnica più semplice per produrre un report analitico aggiornato prevede la lettura dei dati almeno una volta. Tuttavia, se il dataset è così grande ⁷ che leggerlo per intero richiede ore (se non giorni), la produzione di un report aggiornato richiederà anch’essa ore o giorni. Di conseguenza, per ottenere un report aggiornato in pochi secondi, la tecnica non può prevedere la rilettura completa del dataset ogni volta che si richiede un aggiornamento.

OLAP propone di sfruttare strutture dati più piccole e compatte – che rispecchiano i report di interesse. Queste strutture dati specifiche sono concepite per essere aggiornate in modo incrementale man mano che nuovi dati diventano disponibili. Di conseguenza, quando viene richiesto un report aggiornato, il sistema BI non deve rileggere l’intero dataset storico, ma soltanto la struttura dati compatta contenente tutte le informazioni necessarie per generare il report. Inoltre, se tale struttura è sufficientemente piccola, può essere mantenuta in memoria (in RAM) e quindi essere accessibile più rapidamente rispetto allo storage persistente utilizzato per i dati transazionali.

Consideriamo il seguente esempio: immaginate una rete retail che gestisce 100 ipermercati. Il CFO desidera un report con le vendite totali in euro per negozio per giorno negli ultimi 3 anni. I dati grezzi delle vendite storiche degli ultimi 3 anni rappresentano oltre 1 miliardo di righe di dati (ogni codice a barre scansionato in ogni negozio durante questo periodo) e più di 50GB nel loro formato tabellare originale. Tuttavia, una tabella con 100 colonne (1 per ipermercato) e 1095 righe (3 anni * 365 giorni) pesa meno di 0,5MB (calcolando 4 byte per numero). Inoltre, ogni volta che si verifica una transazione, le celle corrispondenti nella tabella possono essere aggiornate di conseguenza. Creare e mantenere una tale tabella illustra il funzionamento interno di un sistema OLAP.

Le strutture dati compatte descritte sopra assumono solitamente la forma di un cubo OLAP, chiamato anche cubo multidimensionale. Le celle esistono nel cubo all’intersezione delle dimensioni discrete che ne definiscono la struttura complessiva. Ogni cella contiene una misura (o valore) estratta dai dati transazionali originali, spesso denominata tabella dei fatti. Questa struttura dati è simile agli array multidimensionali presenti nella maggior parte dei linguaggi di programmazione mainstream. Il cubo OLAP si presta ad operazioni efficienti di proiezione o aggregazione lungo le dimensioni (come sommare e mediare), a condizione che il cubo rimanga sufficientemente piccolo da poter essere contenuto nella memoria del computer.

Reportistica interattiva e visualizzazione dei dati

Rendere le capacità di reportistica accessibili agli utenti finali che non sono specialisti IT è stato un fattore chiave nell’adozione degli strumenti BI. Per questo motivo, la tecnologia ha adottato un design WYSIWYG (what-you-see-is-what-you-get), basato su interfacce utente ricche. Questo approccio si differenzia da quello consueto per interagire con un database relazionale, che consiste nel comporre query utilizzando un linguaggio specializzato (come SQL). L’interfaccia abituale per manipolare un cubo OLAP è una matrice, simile alle tabelle pivot in un programma di foglio di calcolo, che permette agli utenti di applicare filtri (noti come slice and dice nella terminologia BI) ed eseguire aggregazioni (media, min, max, somma, ecc.).

Ad eccezione dell’elaborazione di dataset particolarmente grandi, la necessità dei cubi OLAP diminuì verso la fine degli anni 2000 in parallelo con i notevoli progressi dell’hardware di calcolo. Furono introdotti nuovi strumenti BI “leggeri” con un focus esclusivo sul front-end. Questi strumenti BI leggeri erano progettati principalmente per interagire con database relazionali, a differenza dei loro predecessori “robusti” che sfruttavano back-end integrati con cubi OLAP. Questa evoluzione fu possibile perché le prestazioni dei database relazionali, all’epoca, generalmente consentivano l’esecuzione di query complesse sull’intero dataset in pochi secondi – sempre a condizione che il dataset rimanesse al di sotto di una certa dimensione. Gli strumenti BI leggeri possono essere visti come editor WYSIWYG unificati per i vari dialetti SQL che supportavano. (Infatti, internamente questi strumenti BI generano query SQL.) La principale sfida tecnica consisteva nell’ottimizzazione delle query generate, al fine di minimizzare il tempo di risposta del database relazionale sottostante.

Le capacità di data visualization degli strumenti BI riguardavano in gran parte la presentazione dei dati lato client, sia tramite applicazioni desktop che web. Le capacità di presentazione progredirono costantemente fino agli anni 2000, quando l’hardware degli utenti finali (ad es. workstation e notebook) cominciò a superare di gran lunga (dal punto di vista computazionale) quanto necessario per la visualizzazione dei dati. Oggigiorno, persino le visualizzazioni dei dati più elaborate sono processi poco gravosi, in scala ridotta rispetto al consumo di risorse computazionali associate all’estrazione e trasformazione dei dati sottostanti.

L’impatto organizzativo della BI

Se da un lato la facilità di accesso è stata un fattore decisivo per l’adozione della maggior parte degli strumenti BI, navigare nel panorama dei dati delle grandi aziende risulta difficile, se non altro per la semplice diversità dei dati disponibili. Inoltre, anche se lo strumento BI è abbastanza accessibile, la logica di reportistica che le aziende implementano tramite questi strumenti tende a riflettere la complessità del business e, di conseguenza, la logica stessa può risultare molto meno accessibile rispetto allo strumento che ne supporta l’esecuzione.

Di conseguenza, l’adozione degli strumenti BI ha portato – per la maggior parte delle grandi aziende – alla creazione di team dedicati all’analisi, che solitamente operano come funzione di supporto insieme al dipartimento IT. Come previsto dalla Legge di Parkinson, il lavoro si espande in modo da riempire il tempo disponibile per il suo completamento; questi team tendono ad espandersi nel tempo insieme al numero di report generati, indipendentemente dai benefici ottenuti (percepiti o effettivi) dall’azienda dall’accesso a detti report.

Limiti tecnici della BI

Come spesso accade, esiste un compromesso tra le virtù degli strumenti BI, nel senso che una maggiore facilità di accesso comporta un costo in termini di espressività; in questo caso, le trasformazioni applicate ai dati sono limitate a una classe relativamente ristretta di filtri e aggregazioni. Questo è il primo grande limite, poiché molte – se non la maggior parte – delle problematiche aziendali non possono essere affrontate con tali operatori (ad esempio, qual è il rischio di abbandono di un cliente?). Naturalmente, è possibile introdurre operatori avanzati nell’interfaccia utente BI, tuttavia tali funzionalità “avanzate” vanificano ⁸ lo scopo iniziale di rendere lo strumento facilmente accessibile agli utenti non tecnici. Di conseguenza, progettare query dati avanzate non è diverso dal costruire software, un compito intrinsecamente difficile. A titolo esemplificativo, la maggior parte degli strumenti BI offre la possibilità di scrivere query “raw” (tipicamente in SQL o in un dialetto simile a SQL), ricorrendo al percorso tecnico che lo strumento intendeva eliminare.

Il secondo grande limite è la prestazione. Tale limitazione si presenta in due forme distinte per gli strumenti BI leggeri e robusti, rispettivamente. Gli strumenti BI leggeri di solito includono una logica sofisticata per ottimizzare le query al database che generano. Tuttavia, questi strumenti sono, in definitiva, limitati dalle prestazioni che il database, quale back-end, può offrire. Una query apparentemente semplice può rivelarsi inefficiente da eseguire, portando a lunghi tempi di risposta. Un ingegnere di database può certamente modificare e migliorare il database per affrontare questo problema. Tuttavia, ancora una volta, questa soluzione vanifica l’obiettivo iniziale di mantenere lo strumento BI accessibile agli utenti non tecnici.

Gli strumenti BI robusti hanno le loro prestazioni limitate dal design stesso dei cubi OLAP. In primo luogo, la quantità di RAM necessaria per mantenere un cubo multidimensionale in memoria aumenta rapidamente man mano che crescono le sue dimensioni. Anche un numero moderato di dimensioni (ad es., 10) può portare a gravi problemi legati all’impronta di memoria del cubo. Più in generale, i design in-memory (con i cubi OLAP che rappresentano il caso più frequente) soffrono solitamente di problematiche legate alla memoria.

Inoltre, il cubo è una rappresentazione lossy dei dati transazionali originali: nessuna analisi eseguita su di esso può recuperare informazioni che sono state perse sin dall’inizio. Riprendendo l’esempio dell’ipermercato, in tale scenario, i carrelli della spesa non possono essere rappresentati in un cubo. Di conseguenza, l’informazione “acquistati insieme” viene persa. Il design complessivo del cubo OLAP limita severamente quali dati possano essere rappresentati; tuttavia, questa limitazione è proprio ciò che rende possibile la proprietà “online” in primo luogo.

Limiti aziendali della BI

L’introduzione degli strumenti BI in un’azienda è meno trasformativa di quanto possa apparire. In sostanza, produrre numeri, di per sé, non ha valore per l’azienda se non vi è alcuna azione collegata a tali numeri. Il design stesso degli strumenti BI enfatizza una produzione “illimitata” di report, ma tale design non supporta alcun effettivo percorso d’azione. Infatti, nella maggior parte dei casi, l’espressività limitata degli strumenti BI risulta troppo restrittiva per automatizzare qualsiasi processo basato sui report BI.

Inoltre, lo strumento BI tende a esacerbare le tendenze burocratiche delle grandi aziende. Evidenze aneddotiche, numeri grezzi e buon senso sono spesso sufficienti a stabilire le priorità aziendali. Tuttavia, l’esistenza di uno strumento analitico self-service – come la BI – offre ampie opportunità per procrastinare e confondere le acque con un flusso incessante di metriche discutibili e non attuabili.

Gli strumenti di BI sono vulnerabili ai problemi del design by committee, in cui le idee di tutti vengono incluse nel progetto. La natura self-servicing dello strumento enfatizza un approccio estremamente inclusivo quando si introducono nuovi report. Di conseguenza, la complessità del panorama dei report tende a crescere nel tempo, indipendentemente dalla complessità aziendale che quei report dovrebbero riflettere. Il termine vanity metrics è diventato ampiamente usato per indicare metriche – solitamente implementate tramite uno strumento di BI – come queste che non contribuiscono al risultato finale dell’azienda.

Il punto di vista di Lokad

Considerando le capacità dell’hardware informatico moderno, utilizzare un sistema di reportistica per produrre 1 milione di numeri al giorno è facile; produrre 10 numeri al giorno degni di essere letti è difficile. Sebbene uno strumento di BI usato in dosi ridotte sia vantaggioso per la maggior parte delle aziende, in dosi elevate diventa un veleno.

In pratica, ci sono solo un numero limitato di intuizioni che si possono ricavare dalla BI. L’introduzione di sempre più report porta rapidamente a rendimenti decrescenti in termini di nuove (o migliorate) intuizioni ottenute con ogni report aggiuntivo. Ricorda, la profondità dell’analisi dei dati accessibile tramite uno strumento di BI è limitata per progettazione poiché le query devono rimanere facilmente accessibili ai non specialisti attraverso l’interfaccia utente.

Inoltre, anche quando si acquisisce una nuova intuizione dai dati, ciò non implica che l’azienda possa trasformarla in qualcosa di attuabile. La BI è, nella sua essenza, una tecnologia di reportistica: non enfatizza alcun invito all’azione per l’azienda. Il paradigma della BI non è orientato verso l’automazione delle decisioni aziendali (nemmeno quelle banali).

Le funzionalità della piattaforma Lokad offrono ampie capacità di reportistica personalizzata, simili alla BI. Tuttavia, a differenza della BI, Lokad è orientata all’ottimizzazione delle decisioni aziendali, più specificamente di quelle riguardanti supply chain. In pratica, raccomandiamo di avere un supply chain scientist responsabile della progettazione, e successivamente della manutenzione, della ricetta numerica che genera – tramite Lokad – le supply chain decisions di interesse.

Note