Progettazione ed implementazione di un Decision Support System per dati aziendali

Introduzione
L’evoluzione dell’informatica e la conseguente diffusione su scala mondiale dei com-
puter ha fatto sì che oramai sia le piccole che le grandi aziende immagazzinino
la maggior parte delle loro informazioni sotto forma elettronica. Se da una parte
questo porta innegabili vantaggi di tipo pratico, dall’altra la frammentazione delle
strutture in cui i dati sono inseriti rende difficile una loro omogenea consultazione,
facendo venir meno un vantaggio importante della conservazione elettronica delle
informazioni.
Nella maggior parte dei casi, infatti, in un’azienda si possono trovare applicativi
specifici che salvano i dati su database proprietari, informazioni strutturate in fogli
di calcolo (generalmente Excel), database più semplici creati con programmi appositi
(Access, FileMaker) e in alcuni casi anche semplici fogli di testo non formattato.
Questa disomogeneità deriva principalmente dalla necessità che ogni utente ha di
utilizzare caso per caso l’applicativo più comodo per i propri scopi, cosicché verrà
usato un foglio di calcolo per registrare una modesta quantità di informazioni da
poter condividere velocemente con altri utenti – e permettere loro un’agile modifica
– piuttosto che un database, più indicato per l’archiviazione di grosse moli di dati
accessibili per lo più per fini di consultazione.
La business intelligence ha il molteplice scopo di integrare innanzitutto tutte le
informazioni disparate in un unico contenitore – un data mart o, in caso di ingenti
quantità di dati, un data warehouse – e di renderle disponibili agli utenti sotto forma
analitica o grafica. Nello specifico le fasi necessarie alla creazione di un sistema di
business intelligence sono:
 definizione delle informazioni aziendali che risultano interessanti ai fini deci-
sionali;
 estrazione dei dati dalle fonti disomogenee;
 rielaborazione dei dati per adattarli ad uno schema omogeneo;
 aggiornamento del data mart / data warehouse;
1
creazione di strumenti di analisi semplici, intuitivi e sintetici;
 integrazione di tutti gli strumenti in una piattaforma che permetta la consul-
tazione, anche simultanea, a più utenti con differenti permessi legati a diversi
ruoli (manager, impiegato, amministratore del sistema).
Se il primo punto dell’elenco si riferisce ad un processo di analisi preliminare, da
condurre necessariamente prima ancora di operare con i dati veri e propri, il se-
condo, il terzo e parte del quarto aspetto sono contenuti nella fase di Extraction-
Transformation-Loading, o più brevemente ETL (schematizzata in figura 1), che tra-
mite un applicativo apposito permette al progettista di prelevare i dati dalle loro
sorgenti, di rielaborarli apportandovi modifiche ed eliminando quelli superflui e di
inserirli in una struttura omogenea che verrà infine caricata in un database analitico.
La scelta di creare ex novo un contenitore per i dati trasformati, piuttosto che riadatta-
re un database già esistente, è legata alla natura dell’analisi da compiere. Trattandosi
infatti di un’analisi di tipo storico e statistico si ha la necessità che i dati vengano letti
velocemente dal sistema ma al contempo non sono richieste delle grandi performan-
ce in scrittura, dovendo procedere ad un aggiornamento solo poche volte durante
l’anno, tipicamente una o due volte al mese, al più una a settimana. Ciò permette
di considerare i dati come informazioni accessibili in sola lettura, e di effettuare gli
aggiornamenti nei periodi in cui nessun utente ne richiederà l’accesso.
FIG. 1: Passaggio da dati sparsi ad un unico contenitore tramite procedura ETL
Programmi appositi permettono di completare la quinta fase, creando report
1
,
1
Rapporti informativi generalmente sotto forma tabellare e/o grafica.
2
dashboard
2
, o permettendo di strutturare i dati secondo il modello di cubo multidi-
mensionale OLAP , che consente di effettuare analisi più o meno approfondite lungo
varie dimensioni a cui i dati possono appartenere (temporale, spaziale, etc).
L’ultima fase, l’integrazione della procedura ETL e dei documenti analitici e la
loro conseguente accessibilità a più utenti è garantita da una piattaforma di tipo ser-
ver che permette di effettuare interrogazioni sui dati ed analisi sul cubo OLAP , oltre
ad impostare permessi di accesso per gli utenti e schedulare ad intervalli regolari
l’aggiornamento del database analitico. L’utilità della piattaforma unica risiede nella
necessità di dover impostare un’unica volta e su un solo computer, il server, il si-
stema vero e proprio mentre qualsiasi utente finale può accedervi in maniera molto
semplice esattamente come se stesse visitando una qualunque pagina web.
Organizzazione del progetto
Per i fini specifici di questa tesi ci si concentrerà prevalentemente su due aspetti
della creazione di un sistema di business intelligence: l’integrazione dei dati tramite
procedura ETL e la creazione di alcuni report dimostrativi. Il tutto verrà integrato in
una piattaforma open source in modo da fornire un esempio pratico di una possibile
implementazione, e verranno utilizzati dati forniti da un’azienda realmente operan-
te sul mercato nazionale ed internazionale, in modo da rendere realistica e non solo
teorica la trattazione. Proprio tale opportunità di attingere a informazioni reali e di
scoprire le vere necessità dei futuri utenti finali ha condizionato la scelta degli aspet-
ti fondamentali del progetto, infatti l’azienda (di cui viene data una descrizione nel
capitolo 1) ha fornito dati relativi all’attività di produzione, caratterizzati dall’esse-
re disomogenei e di non immediata interpretazione. Per questi motivi la soluzione
proposta da questo progetto è stata l’integrazione dei dati e la loro rappresentazione
mediante report grafici, e l’installazione di una piattaforma di tipo server che renda
possibile a più utenti, anche remoti, l’accesso alle nuove informazioni.
Nel primo capitolo successivo a questa introduzione verrà definito il domino su
cui si opererà, ossia verranno elencate tutte le fonti dei dati e verrà esaminata la
struttura in cui essi sono immagazzinati.
Nel secondo capitolo verrà fornita una breve panoramica su tutti i software open
source dedicati alla business intelligence disponibili al momento della stesura della
tesi, inoltre verranno elencati i programmi scelti per questo specifico progetto.
2
Chiamati anche “cruscotti aziendali”, sono visualizzazioni rapide e sintetiche della salute
dell’azienda.
3
In seguito nel terzo capitolo verrà analizzata la procedura ETL, e verranno ap-
profonditi i processi di integrazione fino a giungere al popolamento del data mart.
Nel quarto capitolo verranno creati, con due diversi programmi, quattro report
grafici di vario tipo. Questi, assieme alla procedura ETL saranno integrati in una
piattaforma tramite la quale un generico utente potrà richiamarli ed esportarli in
vari formati, mentre l’aggiornamento programmato del data mart verrà eseguito in
automatico dalla piattaforma stessa.
Infine si procederà ad un’analisi conclusiva dei vantaggi e dei punti deboli del
progetto, con una sezione dedicata a possibili sviluppi futuri del progetto, atti a
migliorare e potenziare le funzionalità della piattaforma di business intelligence.
4
Capitolo 1
Definizione del dominio e della
struttura dei dati
La GazpromNEFT Italia S.p.A., con sede a Roma e stabilimento di produzione sito
in Bari, è la sussidiaria italiana del gruppo GazpromNEFT, quinto produttore russo
di petrolio – a sua volta controllato all’80% dal gigante russo del gas Gazprom – ed
è nata nel 2009 a seguito dell’acquisizione della Chevron Italia S.p.A. L’azienda è
tuttavia presente sul mercato italiano sin dai primi anni ’60 come ViscoSud S.p.A.,
ed in seguito sul mercato internazionale dal 1986 come Texaco Italiana S.p.A.
Queste numerose variazioni di ragione sociale hanno portato, dal punto di vi-
sta strettamente tecnico, alla necessità di implementare ogni volta un sistema in-
formativo differente per l’immagazzinamento e l’analisi dei dati. Essendo l’ultima
variazione relativamente recente tale processo risulta ancora in corso e vi è stata sia
la possibilità di accedere a svariate fonti dei dati, sia l’occasione di sperimentare
un modello di business intelligence potendolo adattare fin dal principio alle esigenze
degli utenti.
In particolare si è scelto di legare i dati più significativi che lo stabilimento di
Bari potesse offrire, quelli riguardanti la produzione di merce destinata alla vendita,
con altre informazioni riguardanti alcuni degli aspetti connessi all’attività lavora-
tiva, ossia la produzione di rifiuti, il consumo di risorse energetiche necessario al
funzionamento dell’impianto e la pericolosità teorica che l’attività lavorativa può
rappresentare per l’ambiente.
1.1 La produzione
La GazpromNEFT Italia S.p.A. è specializzata nella produzione di lubrificanti rivolti
a molteplici segmenti di mercato. Tutta la produzione si può distinguere in due
5
DEFINIZIONE DEL DOMINIO
macro categorie, produzione di oli e produzione di grassi. Questi ultimi a loro volta
sono classificabili in tre sotto categorie:
grassi normali grassi che richiedono una lavorazione standard;
grassi speciali grassi che prevedono l’aggiunta di additivi e di conseguenza alcune
fasi aggiuntive rispetto al caso precedente;
grassi tixotropici grassi le cui fasi di lavorazione sono completamente differenti
rispetto agli altri.
1.1.1 Analisi della produzione
Ogni prodotto è identificato univocamente da un codice alfanumerico, in aggiunta
vengono assegnati altri attributi come il nome, il tipo (olio o grasso) e il tipo di
grasso, che ha valore ovviamente solo quanto il prodotto è un grasso. Lo schema è
rappresentato nella tabella 1.1, mentre il diagramma ER finale è la figura 1.1 nella
pagina seguente.
ATTRIBUTO STRUTTURA
codice VARCHAR
nome VARCHAR
tipo VARCHAR
tipo_grasso CHAR
TAB. 1.1: Attributi e struttura dell’entità PRODOTTO
Il software di gestione degli ordinativi presente in azienda assegna automatica-
mente, all’inserimento di un nuovo ordine, un numero di batch intero progressivo. Il
batch è completato dal codice del prodotto da inviare in produzione, dalla quantità
di prodotto richiesta e dalla data di produzione.
ATTRIBUTO STRUTTURA
num_batch INTEGER
cod_prodotto VARCHAR
quantita_kg INT
data_produzione DATE
TAB. 1.2: Attributi e struttura dell’entità PRODUZIONE
6
DEFINIZIONE DEL DOMINIO
1.1.2 Diagramma ER
Per la creazione del diagramma ER è necessario notare che il codice del prodotto
presente nella tabella della produzione deve essere uno – ed uno solo alla volta – tra
quelli presenti nella tabella dei prodotti, mentre uno stesso prodotto può apparire
più volte nella tabella della produzione. Questo stabilisce una relazione uno a molti,
così come mostrata in figura 1.1:
FIG. 1.1: Diagramma ER della produzione
Vengono inoltre definite le seguenti business rules:
 prodotto.tipo IN {’olio’, ’grasso’}
 (prodotto.tipo_grasso IN {’N’, ’S’, ’T’} AND prodotto.tipo=’grasso’)
OR (prodotto.tipo_grasso IS NULL AND prodotto.tipo=’olio’)
1.2 La produzione di rifiuti
Gli scarti di produzione, e in particolar modo il loro smaltimento, occupano una
parte importante nella filiera produttiva di un’attività industriale. La gestione dello
smaltimento dei rifiuti in azienda è effettuata – secondo norma di legge – registran-
do tutte le operazioni su di un annuario cartaceo. Non essendo quindi presente un
apposito applicativo si è ipotizzata la creazione di un database che rispecchiasse il
più fedelmente possibile la struttura dei dati riportati nell’annuario.
1.2.1 Analisi della produzione di rifiuti
Tutti i rifiuti prodotti dallo stabilimento sono divisi in due categorie, non pericolosi
e pericolosi. Se tutti i rifiuti non pericolosi sono raggruppati sotto lo stesso codice
identificativo, quelli pericolosi hanno un codice univoco per ciascuno. Questa scelta
7