Business Intelligence: alcuni esempi

Il cliente non possedeva alcun sistema di Business Intelligence, né utilizzava alcun prodotto affine per l’analisi in autonomia dei dati. L’unica reportistica presente in azienda era composta da file Excel prodotti da routine implementate direttamente nel sistema AS/400 del gestionale. 

Col tempo, si era fatta sempre più pressante la necessità di un sistema informativo che garantisse innanzitutto la qualità dei dati e li riorganizzasse in strutture più comode da interrogare. C’era quindi bisogno di un data warehouse che facesse da fondamento per l’intero sistema di Business Intelligence. Il responsabile delle vendite soffriva la limitatezza delle routine di reporting, e aveva bisogno di un oggetto che gli permettesse analisi più estese, dinamiche e approfondite.

Inoltre, era necessario calcolare tutta una serie di metriche (principalmente in quantità e valore, ma anche in rapporto percentuale) distribuiti lungo tutto il ciclo di vita di un ordine di vendita: dalla sua acquisizione alla produzione degli articoli, dalla loro gestione in magazzino alla spedizione al negozio. Metriche, tra l’altro, di non poca rilevanza operativa in quanto permettono di comprendere come si muovono i numeri all’interno dell’intero processo ciclo attivo.

Una particolarità del mondo del vestiario sono le taglie, che assumono diciture differenti a seconda del mercato di vendita. Queste informazioni sono organizzate in tre tabelle separate nel sistema sorgente, e prone a disallineamenti. Inoltre, il cliente gestisce un totale di sedici taglie diverse: nel database del gestionale, alle sedici taglie corrispondono sedici colonne in tabella SQL. Questo vincolava gli output Excel a presentare il dato nella stessa forma, vincolo a cui bisognava trovare una soluzione che permettesse maggiore libertà di visualizzazione.

Un’altra particolarità del settore sono le stagioni: i dati non devono essere confrontati su base annuale (per esempio, l’anno corrente rispetto all’anno precedente), ma in base alle stagioni di mercato, ossia primavera/estate ed autunno/inverno. L'analisi temporale assume quindi tutto un altro significato rispetto alla norma.

Dati i vincoli tecnici ed economici, la scelta è ricaduta sulla creazione di un database dedicato al data warehouse in un’istanza di SQL Server già esistente ma non soggetta a carichi di lavoro importanti. Sulla stessa macchina è stata creata anche l’istanza di Analysis Services, che ospita i modelli d’analisi Tabular. Il carico di lavoro su entrambi i sistemi è stato previsto essere minimale; quindi, non si è ritenuto indispensabile installare una nuova macchina dedicata alla BI.

I dati sono stati rimodellati in maniera non indifferente, soprattutto per quanto riguarda due ambiti: le anagrafiche (o dimensioni) degli articoli e delle taglie, e la tabella degli ordini di vendita. Nella dimensione dell’articolo sono state conformate – e quindi sono confluite –  informazioni diverse da molteplici tabelle, rendendo di fatto centralizzata qualsiasi logica sul prodotto del cliente. La dimensione delle taglie è stata anch’essa modellata come unione delle tre tabelle originali per le tre nazionalità italiana, tedesca e statunitense. Così facendo, presa una taglia, è istantaneo visualizzarne la specifica dicitura per singola nazionalità. Per quanto riguarda la tabella degli ordini di vendita, si è effettuato l’unpivoting in modo da trasformare le sedici colonne (per le sedici taglie) in righe (record) differenti. Questa operazione permette di avere una struttura dati molto più flessibile perché ora il dato può essere esposto a piacimento in riga od in colonna, senza alcun vincolo. Per risparmio di spazio in memoria, la tabella è stata spezzata in due: una con le informazioni di testata e riga d’ordine, una con le (massimo) sedici righe di taglia per singola riga d’ordine.