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.

Sebbene ci fosse stato un iniziale timido tentativo di costruirsi in casa un data warehouse che centralizzasse il patrimonio dati aziendale, il progetto era riuscito solo parzialmente. Questo portò l’azienda ad avere un data warehouse ancora in fase embrionale, incapace quindi di soddisfare i crescenti bisogni del decision making. Inoltre, non tutti i dati erano allineati con le sorgenti transazionali.

Nel corso del 2019 la sensazione era quella che le attività nei vari reparti produttivi non fossero ben coordinate fra di loro. Ogni venerdì sera, era compito dei responsabili di reparto redare un documento che pianificasse l’allocazione degli operatori nei diversi reparti produttivi per la settimana successiva. Ma ogni settimana successiva, tale pianificazione non veniva rispettata a causa di imprevisti quali, per esempio, le assenze per malattia che costringevano gli operatori ad un forte turnover interno. Con l’obiettivo di equilibrare la forza lavoro fra i diversi reparti, ci si allontanava dalla pianificazione, portando tra l’altro ad un generale ritardo nella produzione. Il problema fu evidente quando si notò che le ore spese per le attività effettivamente produttive erano una frazione limitata rispetto al totale.

Occorreva quindi comprendere quanto le assenze incidessero nel turnover degli operatori, quanto ciò allontanasse la produzione reale da quella pianificata, quali erano i reparti più colpiti e in che misura, quali erano i tempi extra necessari agli operatori per le attività non sopra citate, ed infine come redare una migliore pianificazione sulla base della tendenza storica.

Procedemmo modellando un data mart che includesse tutti i dati necessari provenienti da diverse fonti: i tempi registrati in reparto per le varie attività produttive e non, le timbrature dei dipendenti all’ingresso ed uscita dal lavoro (comprese le pause pranzo), e la pianificazione del venerdì sera. Queste rappresentavano le tre tabelle dei fatti centrali allo star schema disegnato per il data mart in esame; attorno ad esse, però, dovevano svilupparsi quelle dimensioni d’analisi tramite le quali sarebbe stato possibile indagare gli eventi. Tali dimensioni avrebbero messo in relazione le tre diverse tabelle dei fatti, permettendo analisi incrociate.

Furono sviluppate quindi le logiche automatizzate di caricamento dei dati certificati nel data warehouse in SQL Server Integration Services, il modello semantico Tabular in SQL Server Analysis Services, e della reportistica istituzionale in SQL Server Reporting Services. Le analisi condotte in Excel ed i report sviluppati su tale modello Tabular diedero l’evidenza, sia grafica che numerica, delle performance dei reparti (furono create delle KPI apposite) e dell’accuratezza della pianificazione. Obiettivi e metodo furono chiari fin dall’inizio, quindi tutti gli sviluppi si svolsero nell’arco di soli sei giorni lavorativi.

Ciò permise all’azienda di rendere man mano sempre più accurate le proprie pianificazioni, organizzarsi per evitare turnover improvvisati, ed in generale coordinare meglio le attività. Furono quindi ridotti i tempi di lavoro, e migliorarono le performance di tutti i reparti che soffrivano tale problematica. Il tempo effettivamente produttivo di molti reparti aumentò di svariati punti percentuali, avvicinandosi al valore desiderato.

Il cliente possedeva già un sistema di Business Intelligence. Avviato quattro anni prima, il progetto era nato con l’obiettivo di esplorare la tecnologia, ma aveva ben presto preso piede, incontrando l’entusiasmo del titolare e degli utenti. In breve tempo si era arrivati ad un progetto di dimensione e complessità importanti, ma sviluppato con una certa fretta ed una ridotta cura ai dettagli. Il data warehouse in SQL Server era stato disegnato già da subito in ottica Corporate, cioè per contenere i dati delle diverse società del gruppo; l’ETL però era stato implementato per la sola società madre, e non era facilmente adattabile per integrare anche le altre società, se non con un importante lavoro manuale da parte degli sviluppatori tramite Integration Services.

La reportistica istituzionale, creata con Reporting Services, era basilare e spesso statica: alcuni report erano frequentemente soggetti a richieste di modifica da parte degli utenti finali, che chiedevano un parametro in più od una dimensione in più. Inoltre, molti report erano stati creati per soddisfare il crescente entusiasmo degli utenti, senza però che ne venisse valutata l’effettiva utilità. Alla fine, su un centinaio abbondante di report, la metà era caduta in disuso o addirittura mai stata utilizzata. Esisteva un solo ed unico modello di Analysis Services, focalizzato su un tema specifico e purtroppo limitato nelle sue potenzialità.

Nell’autunno del 2021 era quindi sorta la necessità di revisionare l’intero sistema di BI, così da estenderlo alle filiali e consociate e poterlo orientare verso tecnologie più moderne, fra cui Power BI. Il tema critico era l’ETL: andava reso quanto più dinamico possibile, in modo da dover intervenire solo minimamente per integrare in data warehouse qualsiasi nuova società, dato che il gruppo si stava allargando. Occorreva poi un lavoro di rianalisi e scrematura della reportistica: in SSRS sarebbe stato mantenuto solo lo stretto necessario, mentre tutto il resto sarebbe stato sostituito da report dinamici in Power BI, connessi a futuri nuovi modelli d’analisi Tabular.

L’ETL in Integration Services fu, per una buona metà, riscritto: la parte di staging area passava da un database per singola società ad un database comprensivo di tutte (come il data warehouse). I pacchetti di SSIS per l’importazione dei dati in staging area furono sostituiti da una procedura SQL a codice dinamico: in questo modo era possibile richiamare questa – sola ed unica – procedura passandole come parametro il nome della tabella target, e questa si sarebbe occupata di movimentare i dati fra sorgente e destinazione, andando opportunamente in caricamento totale od incrementale a seconda dei casi. L’ETL della staging area diventava così dinamicizzato al massimo, sia a fronte di una nuova società da inserire in Dwh, sia a fronte di nuove tabelle da importare in staging area. Furono aggiunte anche logiche per la gestione di caricamenti parziali del Dwh – cioè di solo uno od alcuni dei data mart a sistema – e per il monitoraggio/tracciamento delle esecuzioni. Questo si è tramutato in un enorme guadagno – non solo di tempo – nella gestione degli errori in fase di aggiornamento del data warehouse.

Lato SSRS, vennero migrati al nuovo sistema di BI i soli report che presentavano delle statistiche di utilizzo (estratte dal database ReportServer) sopra una certa “soglia d’accettabilità”. Installato Power BI e dimostrate le sue diverse modalità operative, si concordò di utilizzarlo principalmente in Live Connection ad Analysis Services (e mai in Import Mode): venne pianificato quindi lo sviluppo di un modello d’analisi verticale per ciascun singolo processo di business in BI, così da poter creare modelli di analisi verticale e futuri nuovi report in Power BI.

Per presentare le piene potenzialità di Analysis Services e Power BI, l’unico modello Tabular esistente in azienda fu rimodellato da zero e notevolmente ampliato e potenziato, permettendo vecchie analisi (rimaste immutate dal punto di vista operativo dell’utente finale) e nuove. Vennero create delle dashboard atte a sostituire quelle precedentemente sviluppate in Qlik Sense, non facilmente accessibili agli sviluppatori IT. Con l’introduzione di Power BI si è ridotto drasticamente il costo delle licenze per la reportistica.

Il cliente si trova quindi ad avere un’infrastruttura di Business Intelligence decisamente più veloce e robusta, proiettata verso le tecnologie del futuro e meno costosa, sia in termini di licenze che di numero di sistemi da monitorare e gestire.