"Estrapolazione e analisi di dati appartenenti ad applicazioni commerciali attraverso strumenti di business intelligence."

U

NIVERSITÀ DI

P

ISA

Dipartimento di Informatica

Corso di laurea magistrale in Data Science & Business Informatic

Tesi di laurea

“Estrapolazione e analisi di dati

appartenenti ad applicazioni

commerciali attraverso strumenti di

business intelligence”

Relatore:

Candidato:

Dott. Roberto Bruni Luca Giambastiani

Tutore aziendale:

Dott. Emanuele Giovanni Calgaro

Una speciale dedica va a mia madre, che purtroppo poco tempo fa è venuta a mancare e non potrà assistere al raggiungimento di questo importante traguardo. Finalmente, ho terminato questo percorso a cui tu probabilmente tenevi anche più di me: spero di averti reso orgogliosa e che, in qualche modo,

tu riesca a vedermi e starmi vicino. Questo risultato è tutto per te.

A mio padre e mio fratello, i quali hanno sempre creduto in me, sostenendomi e standomi vicino in questo momento difficile. Spero, con questo traguardo, di

averli resi orgogliosi e di aver ricambiato, almeno in parte, l’affetto e la

fiducia mostrata.

Agli amici, ma quelli veri, compagni di mille avventure e punto fermo su cui poter fare affidamento sempre.

A me stesso, che con perseveranza e dedizione sono riuscito a raggiungere questo ambito traguardo, dimostrando il mio valore.

Sommario

L’obiettivo di questa relazione è quello di descrivere l’attività che ha caratterizzato il mio tirocinio curricolare.

Esso si è tenuto presso Apparound, un’azienda che opera nel settore informatico offrendo soluzioni digitali a supporto delle vendite.

In particolare, Apparound ha sviluppato degli applicativi, sia per il contesto web, sia per quello mobile, al fine di supportare e migliorare tutto il processo di vendita dei propri prodotti o servizi. Ovviamente, tali applicativi vengono customizzati per ciascun cliente in base alle esigenze.

Il mio progetto di tesi riguarda il cliente più importante di Apparound, ovvero Vodafone Italia.

In sintesi, la mia attività consisteva nell’acquisizione e nell’analisi di dati, relativi a degli applicativi che Apparound ha sviluppato per Vodafone, al fine di produrre e mantenere costantemente aggiornata della reportistica.

Tale reportistica, in parte già esistente precedentemente, ha il compito di evidenziare il valore di alcune metriche, le quali ci forniscano delle indicazioni riguardanti aspetti di carattere commerciale e, in generale, sull’utilizzo di questi applicativi.

Il progetto di tirocinio nasce proprio dalla volontà di migliorare tutto il comparto della reportistica di Vodafone, sia in termini di quantità e qualità dei dati a disposizione, attraverso l’implementazione di un data warehouse che conterrà i dati acquisiti, sia attraverso la produzione di nuovi rapporti informativi, i quali mostreranno informazioni non ancora evidenziate. Un altro importante obiettivo che il tirocinio si prefissava era quello di automatizzare l’intero processo di aggiornamento dei dati e, conseguentemente, dei report. Per quanto riguarda le tecnologie utilizzate nel corso del progetto, esso si basa sui prodotti Microsoft, il quale costituisce l’ambiente di riferimento per Apparound. Infatti, il data warehouse è stato sviluppato attraverso Microsoft SQL Server ed è stato popolato, a partire dai dati contenuti nei database degli applicativi Vodafone, attraverso procedure di ETL costruite con Microsoft SQL Server Integration Services. Anche la reportistica è stata prodotta con Power BI, lo strumento di Microsoft dedicato al data reporting.

Questa relazione è organizzata in modo che siano descritti i vari passaggi che hanno caratterizzato la mia esperienza lavorativa, nell’ordine col quale si sono svolti.

Partendo dalla descrizione dello stato dell’arte prima dell’inizio del tirocinio e delle tecnologie utilizzate nel corso di esso, passeremo alla fase di descrizione del lavoro da me svolto per realizzare il progetto, evidenziandone le scelte e le modalità di implementazione.

1

Indice

1 Introduzione 3

2 Vodafone TiT – TuttoInTasca 7

2.1 TiT Enterprise . . . . 8

2.2 TiT Care . . . . . . . 10

2.3 TiT Consumer . . . . 12

2.4 Ambienti di sviluppo . . . . . . . . 13

2.5 Reportistica relativa agli applicativi TiT . . . . . . . 14

2.5.1 Vodafone KPI . . . 14

2.5.2 Dashboard Power BI . . . . 16

2.6 Procedura di aggiornamento della reportistica . . . . 21

3 Tecnologie e strumenti utilizzati 25 3.1 Microsoft SQL Server . . . . . . . . . . 25

3.1.1 SQL ServerManagement Studio . . . 26

3.1.2 SQL Server Integration Services . . . . . . . . . 28

3.2 Visual Studio . . . . . . . . 28

3.3 Power BI . . . . 30

3.4 Linguaggi di programmazione e librerie . . . . 31

3.4.1 T-SQL . . . . 31

4 Sviluppo del progetto 34

4.1 Progettazione e implementazione del data warehouse . . 34

4.1.1 Creazione delle tabelle in DB_Staging . . . . . . 38

4.1.2 Sviluppo delle procedure di ETL per DB_Staging . . . 40

4.1.3 Creazione delle tabelle in DB_Staging . . . . . . . 44

4.1.4 Sviluppo delle procedure di ETL per DB_ETL . . . . . 47

4.1.5 Automatizzazione dell’attività di ETL . . . . . . . . . . 53 4.2 Reportistica Power BI . . . . . . . . 54

5 Conclusioni 62

1 Introduzione

Lo scopo di questo elaborato consiste nella descrizione del tirocinio curriculare da me svolto presso l’azienda Apparound1_{di Montacchiello, in provincia di Pisa.}

Il tirocinio, dalla durata di 700 ore, è iniziato a aprile 2020 ed è terminato nel mese di ottobre. Esso, fatta eccezione per qualche giorno lavorativo, si è svolto in modalità a distanza a causa della pandemia mondiale di Covid-19.

Durante questa esperienza sono stato seguito dal dott. Emanuele Giovanni Calgaro, in qualità di tutore aziendale, e dal professor Roberto Bruni, in qualità di relatore e tutore accademico. Inoltre, ho strettamente collaborato con molti membri di Apparound, in particolare con i colleghi del team di cui facevo parte. Tra essi mi pare doveroso citare Roberto Bedola, persona con la quale ho lavorato assieme quotidianamente.

In questa introduzione illustrerò in modo sintetico in che cosa consisteva il mio tirocinio, evidenziando quale era la base di partenza prima dell’inizio, quali erano le consegne e descrivendo a grandi linee il lavoro svolto, per poi concludere con

la presentazione della struttura dell’elaborato.

L’attività di tirocinio consisteva nell’acquisire, gestire e analizzare dei dati, appartenenti a un importante cliente di Apparound, mediante l’utilizzo di tecniche di business intelligence. Il fine dell’attività era quello di ottenere e

monitorare delle informazioni relative agli applicativi Apparound utilizzati dalla

forza di vendita di questo cliente. Quest’ultimo, il più importante per Apparound,

è Vodafone Italia, azienda operante nel settore delle telecomunicazioni.

Gli applicativi appena citati hanno lo scopo di supportare la forza di vendita di

Vodafone nell’engagement e nella gestione dei clienti lato business. Queste applicazioni, che hanno in comune l’acronimo TiT (TuttoInTasca), essendo state

sviluppate per i tablet in particolare, sono tre e offrono funzionalità diverse tra loro; TiT Enterprise, il prodotto “di punta” di Apparound, si occupa di condividere con i venditori Vodafone tutte le informazioni e gli strumenti utili al loro scopo: esso consente alle forze di vendita di configurare e quotare tutte le offerte di Vodafone in ambito business-to-business, di gestire la scontistica e di sottomettere gli ordini. Abbiamo poi TiT Care, un tool desktop di tipo gestionale

utilizzato dall’assistenza clienti a supporto della gestione della clientela

Vodafone, e TiT Consumer, il quale fornisce informazioni, spesso sotto forma di rapporti informativi, riguardanti le vendite lato consumer. Infine, è presente anche un tool desktop chiamato TiT Web, il quale è una parte complementare di TiT Enterprise, essendo un’estensione di quest’ultimo.

Ovviamente, tutti questi applicativi necessitano di una moltitudine di dati, in particolare di tipo commerciale, per poter funzionare correttamente. Infatti, ciascuno di essi possiede un database relazionale che ha il compito di raccogliere tutti i dati utilizzati delle app.

Vista la grande quantità di dati che circolano su questi applicativi, Apparound e Vodafone hanno pensato di sfruttarli, al fine di estrapolare da essi utili informazioni. Infatti, attraverso l’analisi di questi dati è possibile ottenere sia informazioni di carattere commerciale, riguardanti per esempio i preventivi, i contratti stipulati e le offerte, sia riguardanti l’utilizzo generale delle applicazioni, come gli accessi utente, i device utilizzati e così via.

Prima dell’inizio del mio tirocinio, la Vodafone Business Unit2 _{di Apparound}

aveva già acquisito una piccola parte di questi dati, presi dai DB degli applicativi TiT, e se ne era servita per produrre dei rapporti informativi che evidenziassero e monitorassero alcune informazioni, come quelle già citate in precedenza. Per sviluppare questi report, è stato utilizzato Power BI, un software di Microsoft

dedicato all’analisi e alla visualizzazione dei dati.

Nonostante ciò, il lavoro che era stato fatto prima del mio ingresso in azienda era molto limitato: esso si trattava di un progetto acerbo, il quale si trovava ancora in

una fase embrionale. Infatti, non c’era del personale all’interno dell’azienda che

seguisse questa iniziativa in modo strutturato, e dunque molti possibili sviluppi erano rimasti momentaneamente in sospeso.

Tuttavia, la VF BU ha intravisto delle potenzialità in questo progetto e ha deciso

quindi di investire in esso attraverso l’assunzione della mia figura. In particolare,

le criticità più evidenti, al momento del mio arrivo, riguardavano la fase di acquisizione e storage dei dati; infatti, essi venivano estratti manualmente,

attraverso l’esecuzione di query SQL sui rispettivi database, e poi venivano

semplicemente inseriti all’interno di file Excel, anziché essere salvati all’interno di una struttura come un database o un data warehouse. Questi file Excel venivano poi caricati su Power BI e costituivano, in pratica, la base di dati sulla quale sviluppare i report.

Questa procedura aveva, ovviamente, degli enormi limiti: in primis, il fatto di

non essere automatizzata, in quanto l’acquisizione dei dati era vincolata all’esecuzione manuale, la quale avveniva con cadenza mensile, delle query SQL.

Inoltre, la quantità e la qualità dei dati era insufficiente, visto che ne venivano raccolti solo alcuni, in base alla necessità di quel preciso momento e senza essere pre-elaborati in alcun modo. Di conseguenza anche la reportistica prodotta con Power BI presentava alcuni limiti. Infatti, a causa dei pochi dati a disposizione, si era in grado di produrre un numero esiguo di report e si riusciva, in generale, a far emergere una ristretta quantità di informazioni.

Lo scopo del mio progetto consisteva proprio nel trovare ed implementare delle

soluzioni, nell’ambito della business intelligence, che ovviassero alle criticità

appena presentate, in modo da sfruttare pienamente tutto il potenziale informativo che i dati degli applicativi TiT possiedono e da permettere un miglioramento complessivo di tutto il comparto della reportistica Apparound. Per fare questo, abbiamo in primis deciso di progettare e implementare un data warehouse, il quale contenesse i dati delle applicazioni TiT. Infatti, essendo una struttura centralizzata, il data warehouse è ideale per conservare tutte queste informazioni e ci permette di raccogliere i dati in modo automatico e ottimale; questo è possibile mediante procedure di ETL (Extract, Transform, Load), per mezzo delle quali si estraggono i dati dai database relazionali, e, dopo averli trasformati in modo opportuno, si caricano all’interno del data warehouse. Per fare ciò abbiamo quindi dovuto sviluppare tali procedure e integrarle nel data warehouse, in modo che esse venissero eseguite automaticamente, con una certa frequenza temporale, e i dati risultassero sempre aggiornati.

Poiché Apparound opera in ambito Microsoft, queste procedure sono state

sviluppate attraverso un’apposita componente di Microsoft SQL Server chiamata

SQL Server Integration Services. Ovviamente, anche il data warehouse è stato creato e gestito mediante SQL Server Management Studio, il software di gestione per SQL Server.

Una volta fatto questo, abbiamo poi utilizzato il data warehouse sviluppato per potenziare la reportistica di Power BI, cercando di sfruttare al meglio le potenzialità che i nuovi dati offrivano. Abbiamo quindi collegato il data warehouse a Power BI, rimpiazzando i vecchi file Excel, e abbiamo successivamente lavorato sulla reportistica. In prima battuta, ci siamo occupati di

riadattare i report Power BI già esistenti sulla nuova base di dati, per poi produrre successivamente dei nuovi report che mettessero in risalto delle informazioni non ancora mostrate. Esse spesso corrispondono a degli indicatori chiave di

prestazione, meglio conosciuti con l’acronimo inglese di KPI (Key Performance

Indicator), ovvero delle metriche, da noi individuate, che ci permettono di

monitorare l’andamento di determinati aspetti, sia generali che commerciali. Per fare ciò, è stato necessario effettuare un’approfondita analisi dei dati, unitamente

alle competenze in materia di data reporting.

Le soluzioni appena riportate sono state progettate e realizzate unanimemente da me e dagli altri membri della VF BU che si sono occupati di questa iniziativa, tra cui, ovviamente, il tutor aziendale.

Tale progetto, una volta ultimato, è stato presentato a Vodafone Italia, nella speranza che il cliente fornisca dei feedback positivi e che, quindi, ne possano conseguire degli sviluppi futuri interessanti per ambedue le aziende.

Il testo dell’elaborato si suddivide in cinque capitoli, di cui:

 Il capitolo 2 illustra lo stato dell’arte prima dell’inizio del tirocinio,

descrivendo, nel dettaglio, sia gli applicativi citati precedentemente, sia la vecchia reportistica, compresa la fase di acquisizione e aggiornamento dei dati.

 Il capitolo 3 tratta le tecnologie e gli strumenti utilizzati per realizzare il

progetto.

 Il capitolo 4 si occupa di descrivere la progettazione e l’implementazione

della soluzione adottata, evidenziando le scelte progettuali.

 I rimanenti due capitoli riguardano invece le conclusioni finali,

2 Vodafone TiT – TuttoInTasca

Il ruolo di questo capitolo è quello di presentare brevemente le funzionalità e, soprattutto, la struttura degli applicativi TiT – TuttoInTasca, per poi descrivere nel dettaglio tutta la vecchia procedura di estrazione ed analisi dei dati appartenenti a queste app. A riguardo di ciò, faremo anche vedere come era la reportistica e come sono stati definiti gli indici chiave di prestazione, i cosiddetti KPI.

Per quanto riguarda invece le applicazioni TiT, in particolare verrà mostrato quali sono e come sono organizzati i dati di ciascuna, poiché il data warehouse sviluppato sarà popolato proprio da essi.

Di seguito, presentiamo a scopo introduttivo una panoramica (Figura 1) riguardante il mondo TiT – TuttoInTasca, la quale riassume sinteticamente le mansioni che gli applicativi svolgono.

2.1 TiT Enterprise

TiT Enterprise consiste nell’applicazione Apparound più importante per

Vodafone. Essa è stata rilasciata nel 2016 ed è stata sviluppata per l’ambiente mobile, nello specifico per i tablet con i quali i venditori Vodafone operano, con il proposito di supportare quest’ultimi nell’attività di vendita verso le imprese (il cosiddetto B2B, che sta per business-to-business). In particolare, essa è stata progettata per rendere i venditori più efficaci nel corso delle trattative, per semplificare il loro lavoro e per ottenere un maggiore coinvolgimento del cliente. Al fine di permettere tutto questo, TiT Enterprise si occupa di:

 gestire tutti i contenuti informativi e commerciali, i quali vengono

condivisi con le forze di vendita a supporto delle loro attività;

 attraverso il modulo CPQ3_{(Figura 2), fornire un preventivo per tutte le}

offerte Vodafone, le quali sono tipicamente multiprodotto e, talvolta, possono risultare anche molto complesse da configurare;

 gestire gli sconti, i quali devono essere approvati tramite un flusso di

approvazione, attraverso un tool chiamato NAS;

 fornire preventivi rivolti alla customer base di Vodafone per quanto

riguarda i rinnovi e le vendite di tipo cross e up, mediante anche

l’interazione con la componente TiT CB, la quale passa i dati dei clienti

Vodafone a Enterprise;

 generare, sottoscrivere ed inviare i contratti (Figura 2) che vengono

stipulati in seguito all’acquisizione di un nuovo prodotto o di un rinnovo.

Inoltre, TiT Enterprise possiede anche una componente web con la quale scambia informazioni chiamata appunto TiT Web. Essa consiste in un’estensione di Enterprise, in quanto fornisce dei servizi e delle funzionalità aggiuntive per gli agenti e anche per i negozi Vodafone.

TiT Web permette in particolare di consultare delle anagrafiche relative agli agenti e alle agenzie, di visionare della reportistica commerciale e di generare dei contenuti profilati.

In sostanza, TiT Enterprise è quindi un software che supporta il venditore durante tutte le fasi del processo di vendita e che gli permette di concludere quest’ultima.

Ovviamente, l’utilizzo di questo strumento comporta molti vantaggi per la forza

di vendita Vodafone, primi su tutti l’impossibilità di generare errori,

l’allineamento in tempo reale delle informazioni e la completa integrazione con

Vodafone Italia. Affinché tutto ciò sia possibile, è evidente come TiT Enterprise necessiti di condividere delle informazioni con altri sistemi appartenenti al mondo Vodafone. Infatti, essa è interessata da svariati flussi di dati: lo schema in Figura 3 descrive le interazioni di Enterprise con gli altri sistemi e ci fornisce

un’idea piuttosto precisa riguardo la quantità di informazioni che circola all’interno di essa.

Dalla mappa delle interazioni emerge chiaramente come TiT Enterprise invii, ma soprattutto riceva, informazioni relative ai cataloghi prodotti, alle offerte, ai prezzi / sconti e le utilizzi per le proprie mansioni. A partire da esse, infatti, Enterprise configurerà offerte, genererà preventivi e sottoscriverà contratti, producendo a sua volta ulteriori informazioni di carattere commerciale, come il numero di preventivi effettuati.

Alla luce di queste considerazioni, appare evidente come sia possibile sfruttare tutte queste informazioni per monitorare l’andamento delle vendite, le performance dei singoli venditori Vodafone e, più in generale, il volume di

utilizzo dell’applicazione per ciascun utente. Queste considerazioni restano

valide anche per gli altri applicativi del mondo TiT - TuttoInTasca.

I dati di cui stiamo parlando sono ovviamente situati su un database di tipo relazionale sul quale TiT Enterprise si appoggia. Essendo un modello relazionale, tali dati sono organizzati in strutture tabellari dove ciascuna contiene una specifica informazione: per esempio, la tabella CPQ_Product contiene tutti i possibili prodotti che possono essere inseriti all’interno di un’offerta in fase di configurazione. È quindi ovvio che all’interno del database sono presenti tabelle riguardanti sconti, offerte e, in generale, riguardanti tutti gli elementi che caratterizzano TiT Enterprise; a partire da molte di esse, formeremo il data warehouse.

2.2 TiT Care

TiT Care è uno strumento desktop di tipo gestionale che viene utilizzato

dall’assistenza clienti e dall’ufficio marketing di Vodafone al fine di fornire

supporto nella gestione della clientela. Infatti, questo tool consente di gestire e assistere i clienti che fanno già parte della customer base di Vodafone, permettendo di effettuare molte operazioni con essi. Quest’ultime possono essere, banalmente, delle proposte riguardanti l’attivazione di una nuova offerta, ma talvolta anche operazioni riguardanti la gestione del cliente in senso stretto, come le chiamate con il call center Vodafone ai fini di ricevere supporto, la verifica di

fatture d’acquisto o la valutazione della redditività del cliente stesso.

Inoltre, per ciò che concerne l’ufficio marketing, questo strumento consente ad

esso di gestire le campagne, comprese quelle di cambio piano, up sell e cross-sell. Per fornire il supporto di cui eventualmente i clienti hanno bisogno, gli utenti che

Nello specifico, ciascuna pratica è dedicata alla risoluzione di un certo problema che si è verificato.

L’immagine in Figura 4 illustra il modulo di gestione pratiche di TiT Care. Da

essa, si nota come a ogni pratica sia assegnato uno stato, il quale descrive qual è la situazione attuale per essa.

Figura 4 – Gestione delle pratiche di TiT Care

Così come per Enterprise, anche TiT Care comunica con molti altri sistemi esterni con i quali scambia delle informazioni necessarie per espletare le mansioni appena indicate. Anche in questo caso, i dati di cui l’applicazione si

serve vengono salvati all’interno di un database relazionale dedicato. TiT Care è

quindi in grado di fornirci delle ulteriori informazioni riguardo aspetti di natura commerciale come, ad esempio, l’elenco delle pratiche in lavorazione o il numero di campagne di marketing attualmente attive.

2.3 TiT Consumer

L’ultimo strumento che esamineremo è TiTConsumer, un’applicazione che offre

la possibilità di consultare una serie di report nei quali vengono evidenziate informazioni relative alle vendite in ambito business-to-consumer, il cosiddetto B2C. Questo tool è utilizzato sostanzialmente dai negozi Vodafone, i quali costituiscono il principale canale di vendita per i prodotti B2C.

Per riportare un esempio, l’immagine in Figura 5 mostra un report che descrive,

per ciascuna marca e per ciascun modello, il numero di cellulari che sono stati venduti da un certo negozio in combinazione con una sim ricaricabile.

Figura 5 – Report che descrive, per ogni marchio e modello, il numero di cellulari venduti da un determinato negozio insieme a una sim ricaricabile.

TiT Consumer include anche dettagli sui piani, sui terminali e addirittura anche sulla formazione dei venditori.

Inoltre, l’applicazione ha anche lo scopo di conservare e divulgare della documentazione: infatti, i manager utilizzano TiT Consumer per condividere con la forza di vendita, ovvero i negozi in questa circostanza, brochure informative e comunicazioni riguardanti gli strumenti di vendita da utilizzare e gli obiettivi da raggiungere. Chiaramente, le considerazioni fatte per TiT Enterprise e TiT Care

rispettivi DB relazionali ai fini informativi e di monitoraggio, valgono anche per TiT Consumer.

2.4 Ambienti di sviluppo

Ogni applicazione TiT possiede un database dedicato nei quali vengono salvati i dati. In realtà, esistono più versioni di questi database:

infatti, per ciò che concerne lo sviluppo e il rilascio di questi applicativi, sono presenti più ambienti di sviluppo, ai fini di limitare al minimo i possibili errori e di testing in generale, e ciascuno di tali ambienti possiede il proprio database relazionale.

Nel dettaglio, gli ambienti di sviluppo degli applicativi TiT sono cinque e corrispondono ai seguenti: DEV, ST (system test), PRE (pre-produzione), IAT, PROD (produzione). L’ambiente di sviluppo per il rilascio definitivo dei prodotti è ovviamente quello di produzione, mentre gli altri sono finalizzati al rilascio di versioni intermedie per effettuare testing.

Per ciò che concerne le banche dati su cui tali versioni di prodotto si appoggiano, esse sono tipicamente situate su macchine fisiche diverse. Inoltre, per quanto

riguarda gli ambienti DEV e ST, troviamo all’interno dei database dei dati fittizi,

ovvero dei dati creati dai programmatori per essere utilizzati durante le fasi di sviluppo in base alle necessità. Tutto questo è dovuto principalmente dalla policy in materia di dati che Vodafone applica. Infatti, Vodafone Italia ha una politica

molto rigida per quanto riguarda l’accesso ai propri dati, e non consente quindi

alle realtà esterne, fornitori compresi, di servirsene in modo incontrollato.

Per questo motivo, i database di produzione, IAT e pre-produzione, i quali contengono dati reali o quantomeno verosimili, sono situati su delle macchine la cui proprietà appartiene a Vodafone e sono gestiti direttamente da loro, in modo che i dati in essi contenuti siano gestiti internamente all’azienda. Tuttavia, Apparound può accedere a queste macchine e, conseguentemente, alle rispettive banche dati, attraverso strumenti di accesso remoto. In questo modo, Vodafone

fornisce ad Apparound l’accesso ai dati affinché l’azienda possa lavorare sui

propri prodotti, mantenendo però la proprietà e il controllo su essi.

Per quanto riguarda invece gli altri due ambienti di sviluppo, ovvero DEV e ST, essi si trovano su macchine di proprietà di Apparound e sono gestiti direttamente da loro, poiché i dati al loro interno non sono reali ma sono fittizi.

È importante fare queste precisazioni perché, come vedremo nel quarto capitolo, il progetto è stato realizzato prendendo i dati dai database appartenenti a un certo ambiente di sviluppo, e la scelta è legata sia alle considerazioni appena fatte, sia al fatto che tale progetto non è stato formalmente concordato con Vodafone ma è

stata un’iniziativa di Apparound che verrà poi mostrata e proposta a loro.

2.5 Reportistica relativa agli applicativi TiT

In questo paragrafo mostreremo alcuni dei report già esistenti e spiegheremo quali sono le metriche che abbiamo considerato per monitorare le prestazioni degli applicativi e degli utenti che gli utilizzano. Infatti, come già anticipato, Apparound si era già occupata di produrre della reportistica inerente agli applicativi TiT, allo scopo di effettuare un controllo periodico interno per ciò che concerne le attività e, in generale, l’andamento dei propri prodotti.

2.5.1 Vodafone KPI

Per effettuare il monitoraggio degli applicativi TiT, è stato necessario stabilire quali erano le metriche in grado di descrivere nel modo migliore possibile la

situazione e l’andamento generale di essi.

Queste misure, in ambito economico, corrispondono a dei particolari indici conosciuti come indicatori chiave di prestazione (key performance indicator, detti anche KPI). Infatti, i KPI non sono altro che un insieme di misure che descrivono coerentemente le prestazioni di un processo aziendale di qualsiasi tipo. Riguardo la tematica dei KPI, è stata prodotta svariata letteratura; consultando quest’ultima [1], emerge che esistono in particolare quattro tipologie differenti di indicatori:

 indicatori generali, i quali misurano il volume del processo;

 indicatori di qualità, il cui compito è quello di descrivere la qualità dell’output del processo secondo determinati criteri;

 indicatori di costo, la cui mansione è quella di controllare i costi legati al

processo;

 indicatori di servizio, i quali misurano la durata di svolgimento del

Nel determinare i KPI relativi agli applicativi TiT, Apparound ha tenuto in considerazione sia aspetti di carattere economico, sia aspetti relativi all’utilizzo delle applicazioni. Infatti, Apparound ha ritenuto importante verificare sia la quantità e la modalità di utilizzo dei propri prodotti, sia la qualità dell’output, la quale viene tipicamente misurata attraverso parametri economici.

A mio avviso, le valutazioni fatte da Apparound si sono rivelate corrette, in

quanto è ovvio che, per valutare le performance di un’applicazione che ha scopi

commerciali, oltre ai volumi di utilizzo, è fondamentale monitorare anche le cosiddette conversioni che si verificano per mezzo delle applicazioni. Tali conversioni, in un prodotto del genere, corrispondono solitamente all’effettuazione di una vendita o comunque alla produzione di un preventivo o di

un’offerta commerciale4_.

Tuttavia, è opportuno specificare che la selezione degli indicatori chiave di prestazione non è avvenuta in modo formale e strutturato, così come tutte le attività inerenti alla reportistica Apparound. Infatti, solitamente i KPI vengono determinati da un analista, il quale, seguendo uno specifico approccio, effettua

un’analisi del processo che si ha intenzione di monitorare, al fine di stabilire quali sono i fattori elementari del suddetto processo. L’individuazione di questi fattori

fondamentali determina poi gli indicatori da considerare per il processo esaminato. Apparound invece ha stabilito questi indicatori in modo empirico, semplicemente cercando di individuare le misure più idonee a descrivere le prestazioni dei propri prodotti, sfruttando in primis la grande conoscenza di quest’ultimi.

Nel dettaglio, i principali KPI individuati sono i seguenti:

 gli accessi ai sistemi TiT, i quali ci fanno comprendere con chiarezza il

volume di utilizzo degli applicativi;

 il numero di offerte generate da TiT Enterprise, un valore che invece

descrive bene la qualità di utilizzo dei sistemi TiT, in quanto esprime il numero di conversioni;

 i proventi derivanti dalla sottoscrizione di nuove attivazioni e rinnovi;

anche questa misura, ovviamente, corrisponde a un indicatore di qualità. Questi indicatori sono chiaramente analizzati tenendo conto di alcuni attributi: per fornire un esempio, gli accessi sono talvolta valutati entro un certo lasso temporale, mentre magari i ricavi possono essere analizzati solo per ciò che concerne i negozi piuttosto che gli agenti di vendita; in alcune situazioni si 4_{Gli indicatori di qualità riguardano solamente TiT Enterprise, anche se sarebbe stato possibile definirne}

possono dunque applicare dei filtri, al fine di mostrare una specifica informazione, mentre per alcuni indicatori talvolta vengono forniti più report nei quali la metrica viene mostrata considerando un attributo piuttosto che un altro.

Alla luce di ciò che è emerso, appare piuttosto evidente che, anche se le valutazioni fatte da Apparound in modo empirico appaiano corrette, sarebbe possibile fornire una migliore definizione dei KPI Vodafone, in particolare per quanto riguarda il numero di indicatori da considerare. Infatti, seppur le metriche scelte siano forse le più significative nel descrivere le performance degli applicativi TiT, sicuramente esse sono poche e mettono quindi in risalto solo una parte delle possibili informazioni che possono essere ricavate dai dati posseduti. Purtroppo, nel corso della mia attività di tirocinio, non ci siamo concentrati granché su questo aspetto, in quanto il mio operato si è focalizzato in particolare sulle altre fasi del progetto, attribuendo una bassa priorità alla definizione di nuovi KPI.

2.5.2 Dashboard Power BI

Gli indicatori chiave di prestazioni di cui abbiamo appena parlato sono monitorati da Apparound attraverso dei report generati con Power BI. Infatti, come vedremo meglio successivamente, queste particolari metriche corrispondono a degli

attributi che sono presenti all’interno dei dati importati su Power BI. Attraverso

gli script SQL esse vengono dunque estrapolate dai database, insieme ad altri attributi, e vengono poi inserite all’interno dei fogli Excel, i quali vengono poi

caricati all’interno del tool.

Sfruttando gli strumenti che Power BI offre congiuntamente ai dati posseduti, è possibile applicare dei filtri per questi indicatori, oltre che fornire visualizzazioni diverse. Infatti, per ciascun KPI solitamente sono stati creati più report, in modo da mostrare informazioni diverse, variando i filtri applicati e/o gli attributi per i quali considerare gli indicatori.

Inoltre, collocando i report che riguardano un determinato KPI all’interno della stessa pagina di Power BI, viene fornita una panoramica completa, la quale tiene conto di prospettive diverse per uno stesso indice.

Queste pagine contenenti un insieme di report prendono il nome di dashboard. Consultando la documentazione ufficiale [2], una dashboard di Power BI viene definito come una singola pagina chiamata area di disegno, la quale offre una narrazione tramite delle visualizzazioni, ovvero attraverso i report.

Di seguito mostriamo alcune delle dashboard che Apparound aveva creato prima del mio ingresso in azienda; senza dubbio, una delle dashboard più importanti e significative consiste in quella relativa agli accessi agli applicativi TiT: in particolare, essa mostra il numero di accessi che sono stati effettuati alle applicazioni di Enteprise, Care e Consumer, considerando un intervallo temporale di due anni al massimo.

Tale dashboard si presenta come in Figura 6:

Figura 6 – Dashboard relativa agli accessi

In sostanza, questa dashboard è stata creata allo scopo di confrontare, per ciascun mese, il numero totale di accessi con il numero totali di utenti attivi. Tale confronto viene effettuato anche per ciascun applicativo Apparound, considerando sia la versione web che quella mobile5.

Nel dettaglio, la dashboard in questione è composta da quattro distinti report, i quali mostrano:

1) Il numero totale di accessi messo a confronto con il numero di utenti attivi negli ultimi due anni; tali valori sono riportati con cadenza mensile e non vengono fatte distinzioni per ciò che concerne i singoli sistemi TiT, i quali sono considerati tutti assieme.

2) Per ciascun mese, il numero totale di utenti attivi sugli applicativi mobile

nel mese dell’anno corrente, confrontato con quello relativo allo stesso

5_{Per ciascun applicativo TiT è presente sia una versione mobile che una versione web, fatta eccezione per}

mese dell’anno precedente. Inoltre, vengono anche presi in considerazione

i singoli applicativi TiT, fornendo il confronto anche per ciascuno di essi. 3) Le stesse informazioni del report precedente, considerando gli applicativi

web anziché quelli mobile.

4) Per ciascun mese, il numero totale di accessi sugli applicativi, sia mobili che web, nel mese dell’anno corrente messo a confronto con quello

relativo allo stesso mese dell’anno precedente. Anche in questo caso viene

considerata ogni singola applicazione TiT, facendo il confronto anche per ognuna di esse.

Adesso vediamo nel dettaglio un paio di questi report, in modo da mostrare

chiaramente l’informazione che essi descrivono.

Per esempio, il report contrassegnato con il numero 1 corrisponde al seguente (Figura 7):

Figura 7 – Report che confronta, con cadenza mensile, il numero totale di accessi con il numero di utenti attivi negli ultimi due anni

Nel grafico sono presenti due curve, le quali esprimono il numero totale di accessi (curva rossa) e il numero totale di utenti attivi (curva azzurra) per ciascun mese, considerando un lasso temporale che va da ottobre 2018 a settembre 2020.

L’attributo AnnoMese si trova sull’asse delle ascisse, mentre il conteggio di accessi e utenti è situato sull’asse delle ordinate, così come è solito fare per i

report nei quali viene misurato un certo valore; infatti, solitamente le measure vengono collocate sull’asse y, mentre gli attributi per i quali esse vengono considerate vengono poste sull’asse x.

può effettuare più accessi all’applicativo nell’arco di un mese. A dimostrazione di

ciò, prendiamo come esempio il mese che è stato evidenziato nell’immagine soprastante, ovvero luglio 2020; in questo mese, gli utenti attivi sono stati 7237, mentre gli accessi totali 283028.

La visualizzazione grafica che mostra questa informazione, corrispondente al riquadro di colore grigio scuro, riporta anche il valore della varianza, ovvero la differenza percentuale tra i due valori, oltre che l’attributo sull’asse delle ascisse per il quale ci interessava conoscere il valore delle metriche in questione.

Questa visualizzazione grafica di Power BI prende il nome di tooltip.

Un altro interessante report presente all’interno di tale dashboard è quello in

Figura 8:

Figura 8 – Report che mostra, per ogni mese, la variazione del numero di accessi effettuati sui sistemi TiT tra l’anno corrente e quello precedente quest’ultimo.

Questo rapporto informativo è stato realizzato scegliendo una visualizzazione di Power BI chiamata grafico ad area, poiché essa risulta adeguata nel far capire la differenza tra i valori delle due curve, i quali vengono calcolati mese per mese.

Come per il report precedente, il campo mese si trova sull’asse delle ascisse,

mentre il numero di accessi calcolato per un determinato mese su quello delle ordinate.

Dal report emerge evidentemente come, nel corso del 2020, il volume di utilizzo dei sistemi TiT sia diminuito in modo pressoché costante rispetto a quello del 2019. Difatti, la curva che rappresenta gli accessi effettuati nel 2020, ovvero quella di colore più scuro, è sempre situata sotto la curva più chiara, la quale

Una volta appurato ciò, è interessante capire quali potrebbero essere le ragioni della diminuzione di questo trend; una possibile chiave di lettura potrebbe riguardare la pandemia di COVID-19 scoppiata a marzo, che sicuramente ha inciso parecchio per ciò che concerne le attività della forza di vendita Vodafone. Le informazioni presenti nel report sembrerebbero supportare questa teoria, in quanto ritroviamo le maggiori differenze tra i valori delle due curve proprio nei mesi corrispondenti allo scoppio della pandemia.

Questo report ci fornisce anche altre informazioni degne di nota; per esempio, nel mese di agosto, sia nel 2019 che nel 2020, si registrano valori molto più bassi rispetto a quelli degli altri mesi: ciò non è nient’altro che una conferma del fatto che le attività lavorative in agosto si riducano parecchio a causa delle ferie estive. Infine, analizziamo brevemente il tooltip che è stato utilizzato per questo report. Esso è stato personalizzato in modo che tale rapporto informativo descrivesse il numero di accesi ad un livello di dettaglio maggiore. Infatti, per mezzo di questa struttura grafica è possibile conoscere il numero di accessi mensile per ogni singolo sistema TiT. Ovviamente, la somma degli accessi per ciascun applicativo corrisponde al numero totale di accessi di cui abbiamo parlato prima e, difatti, il dato aggregato viene riportato anche nel tooltip.

All’interno di quest’ultimo è presente anche un grafico ad anello, il cui compito è

quello di far capire in modo immediato a chi sta leggendo il report quanto incidono gli accessi su un singolo applicativo piuttosto che su un altro. Dal grafico emerge chiaramente come la maggior parte degli accessi avvenga sul prodotto più importante di Apparound, ovvero TiT Enterprise. Infine, sono anche riportati il numero di utenti attivi, sempre per ciascun prodotto TiT, in modo da

fornire un’ulteriore informazione da poter confrontare ed analizzare.

La dashboard appena esaminata riguardava ovviamente indicatori chiave di prestazione di tipo generale, in quanto misuravano la quantità di utilizzo degli applicativi.

Ovviamente, Apparound ha creato delle dashboard che monitorano anche i KPI di tipo qualitativo; per fornire un esempio, analizziamo brevemente un report facente parte di una dashboard relativa alle offerte generate da TiT Enterprise.

In particolare, tale rapporto informativo mostra il numero di offerte che sono state prodotte attraverso TiT Enterprise nell’arco degli ultimi dodici mesi (Figura 9):

Figura 9 – Numero di offerte generate da TiT Enterprise negli ultimi dodici mesi

Questo grafico, strutturato come i precedenti per quanto riguarda la disposizione dei campi sugli assi cartesiani, è stato realizzato scegliendo un comune istogramma a colonne. Da esso, emerge che il numero massimo di offerte è stato generato a maggio 2020, considerando l’intervallo di tempo compreso tra ottobre 2019 e settembre 2020.

2.6 Procedura di aggiornamento della reportistica

La reportistica che abbiamo appena presentato viene prodotta a partire da alcuni dati che vengono importati all’interno di Power BI. Come ormai sappiamo, prima del tirocinio questi dati venivano acquisiti manualmente attraverso degli script SQL, i quali si occupano di estrapolarli dalle banche dati dei sistemi TiT, e poi

messi all’interno di file Excel. A causa di ciò, non era possibile aggiornare

automaticamente questi dati e, di conseguenza, nemmeno la reportistica di Power BI. Tuttavia, era ovviamente necessario trovare un modo per effettuare

l’aggiornamento di queste informazioni una certa regolarità, in modo da avere dei

report sempre up-to-date. Per questo motivo, Apparound ha stabilito in modo

formale una procedura a cui attenersi per quanto riguarda l’acquisizione di tali dati e per l’aggiornamento della reportistica.

Prima di descrivere tale procedura, è necessario indicare brevemente quali sono i file Excel in cui essi venivano salvati e quali sono gli script SQL che si occupano di fare ciò.

Nello specifico, la tabella seguente (Tabella 1) riporta il nome dei suddetti file, la descrizione dei dati in essi contenuti e i nomi delle query SQL la cui esecuzione permette di ottenere tali dati:

NOME FILE DESCRIZIONE DEL CONTENUTO

QUERY SQL

Accessi.csv Accessi ai sistemi Vodafone_{negli ultimi 12 mesi Accessi_titcons.sql}Accessi_titent.sql Accessi_titcare.sql Licenze.csv Utenti attivi sui sistemi TiT negli_{ultimi 6 mesi Licenze_titcons.sql}Licenze_titent.sql Licenze_titcare.sql Offerte.csv _{Enterprise negli ultimi 12 mesi}Offerte generate su TiT Offerte.sql

Quote.csv Offerte generate su TiT

Enterprise negli ultimi 12 mesi Quote.sql QuoteAvg.csv Media delle Offerte generate su

TiT Enterprise negli ultimi 6 QuoteAvg.sql

Tabella 1 – Nome e descrizione dei file Excel

Tale tabella è indispensabile per comprendere la tipologia dei dati che Apparound aveva interesse a monitorare e per spiegare le modalità di acquisizione degli stessi dai database dei sistemi TiT.

Adesso è possibile presentare la procedura di estrazione dei dati, finalizzata ad

aggiornare quest’ultimi e, di conseguenza, la reportistica Power BI.

In sintesi, la procedura corrisponde, passo dopo passo, al seguente elenco di operazioni da effettuare:

1) Collegarsi al DB di produzione di TiT Enterprise, sfruttando gli strumenti di accesso remoto di cui Apparound si serve per fare ciò.

2) Eseguire, una alla volta, tutte le query relative a TiT Enterprise (vedi Tabella 1) e aggiornare opportunamente i file Excel corrispondenti con i

record ottenuti dall’esecuzione di esse. Per limitare eventuali errori da parte dell’utente, la procedura afferma che ogni volta che si lancia una

query è conveniente aggiornare immediatamente il corrispettivo file prima di passare allo script successivo. Nel dettaglio, ogni volta che si esegue una

query, si devono inserire i record che corrispondono al mese precedente

quello in cui si sta effettuando la procedura all’interno del file associato

allo script e si devono cancellare da esso le righe del mese più vecchio, in modo da ottenere un aggiornamento mensile dei dati. Infine, poiché alcuni

file contengono dati acquisiti dall’esecuzione di più query, talvolta è

necessario rimpiazzare solo alcuni record. Infatti, tipicamente possono esserci tre query, una per ciascun sistema TiT, le quali acquisiscono lo stesso tipo di informazione, per ciascun applicativo, interrogando il DB corrispondente, la quale viene poi salvata all’interno dello stesso file. In questo particolare caso, andranno rimpiazzati solo i record relativi

all’applicativo sul quale stiamo lavorando; essi solitamente si distinguono

attraverso il campo ambiente, il cui valore ci permette, ovviamente, di capire il prodotto al quale fanno riferimento queste righe.

3) Chiudere il collegamento con il DB di TiT Enterprise e ripetere in modo analogo le operazioni appena descritte per gli altri due applicativi.

4) Aggiornare una copia locale del file Power BI contenente le dashboard

relative ai KPI Vodafone, attraverso l’apposito bottone Refresh presente

nel software. Questo file, chiamato KPIVodafone.pbix, si aggiornerà

prendendo i dati contenuti nei fogli Excel, poiché quest’ultimi sono direttamente collegati ed integrati all’interno di Power BI (tali file devono

trovarsi nella stessa cartella del file .pbix).

5) Collegarsi al report server di Apparound, il quale consiste in un server aziendale dedicato alla reportistica il cui scopo è quello di permettere ai

membri dell’azienda di accedere, creare e caricare report, e rimpiazzare il

file denonimato KPIVodafone.pbix presente facendo l’upload di quello aggiornato.

6) Caricare la cartella contenente tutti i file necessari per svolgere la procedura corrente, compreso il file KPIVodafone.pbix appena aggiornato, sullo sharepoint aziendale utilizzando un qualsiasi software di controllo versione.

La procedura appena illustrata doveva essere eseguita all’inizio di ogni mese, in modo che i dati e, di conseguenza, la reportistica risultassero aggiornati mensilmente. Infatti, la reportistica presente veniva poi solitamente analizzata durante alcune riunioni del personale Apparound, le quali si tenevano ogni mese a

metà circa dello stesso, al fine di monitorare l’andamento dei propri prodotti nel

corso del mese appena trascorso. Infatti, dalla spiegazione fornita al punto 2) si evince che l’aggiornamento per il mese X avviene nel mese X + 1, in quanto il

valore delle metriche in questione, per un determinato mese, è definitivo solo una

volta che quest’ultimo è terminato.

Infine, esaminando la procedura in questione, appare evidente come il metodo di acquisizione dei dati e aggiornamento della reportistica presenti dei limiti e delle criticità notevoli, in quanto è frutto di un lavoro eseguito saltuariamente e in modo non strutturato, e che possa quindi essere ampiamente migliorato.

3 Tecnologie e strumenti utilizzati

Il compito di questo capitolo sarà quella di presentare le tecnologie e gli strumenti utilizzati durante la mia esperienza di tirocinio al fine di realizzare il progetto. Verranno descritti, in ordine, i software coinvolti e i linguaggi di programmazione di cui ci siamo serviti.

3.1 Microsoft SQL Server

Microsoft SQL Server consiste in un DBMS relazionale (relational database management system, talvolta indicato come RDBMS) sviluppato da Microsoft. Esso corrisponde quindi al software che Microsoft ha progettato per creare, manipolare ed interrogare, in modo efficiente, un database basato sul modello relazionale. Oltre a ciò, il DBMS ha anche il compito di verificare la sicurezza,

consentendo l’accesso esclusivamente agli utenti autorizzati, e l’integrità della

banca dati, impedendo di effettuare operazioni che possono generare risultati inconsistenti, come, per esempio, la modifica contemporanea di un record da parte di più utenti.

Solitamente, per svolgere tutte queste mansioni i DBMS sono costituiti da un insieme di programmi software. A dimostrazione di questo, congiuntamente a SQL Server, Microsoft rilascia anche un’applicazione desktop chiamata SQL Server Management Studio, abbreviata in SSMS, il cui compito è quello di configurare e amministrare tutti i componenti che SQL Server possiede. Infatti, SQL Server include una suite di servizi server-based che permette agli utenti di effettuare varie operazioni a partire dalle basi di dati. Queste componenti sono:

 SQL Server Reporting Services (SSRS), la quale permette di generare dei

report interattivi;

 SQL Server Analysis Services (SSAS), il cui scopo è quello di analizzare

dei dati al fine di estrapolare informazioni attraverso tecniche di OLAP6_e

data mining;

6_{OLAP, acronimo di Online Analytical Processing, consiste in una serie di tecniche software per}

 SQL Server Integration Services (SSIS), che invece fornisce strumenti per l’estrapolazione e la trasformazione dei dati, utili dunque per

sviluppare procedure di ETL.

Queste componenti forniscono anche un’interfaccia su Microsoft Visual Studio,

per cui è possibile utilizzarle anche su questo ambiente di sviluppo.

Per avere informazioni aggiuntive riguardanti l’installazione e l’utilizzo di SQL

Server e delle sue componenti, è necessario fare riferimento alla guida tecnica [3] che Microsoft mette a disposizione degli utenti.

Microsoft SQL Server è la tecnologia con cui ho lavorato di più durante la mia esperienza di tirocinio. Infatti, come già accennato, il data warehouse che abbiamo prodotto è stato realizzato attraverso questo DBMS, così come le basi di dati relazionali su cui si appoggiano gli applicativi Apparound. Inoltre, mediante SQL Server Management Studio e le componenti precedentemente introdotte, abbiamo quindi effettuato la maggior parte delle operazioni necessarie sulle varie strutture dati coinvolte, al fine di realizzare il progetto.

La versione che abbiamo utilizzato è quella on-premises, ovvero in locale,

dell’anno 2017, in quanto Apparound lavora ancora attraverso server fisici in

loco7_.

Infatti, è opportuno specificare che SQL Server viene distribuito sia on-premises

che in cloud; quest’ultima opzione corrisponde a un servizio di Microsoft Azure

conosciuto come Azure SQL Database.

3.1.1 SQL Server Management Studio

Come già detto, SQL Server Management Studio, talvolta abbreviato in SSMS, corrisponde al sistema software che permette di interfacciarsi con i componenti di SQL Server al fine di effettuare determinate operazioni su essi. Infatti, gli utenti utilizzano questo strumento per gestire i server SQL e i servizi ad esso connessi.

A proposito di ciò, la documentazione ufficiale Microsoft [4] afferma che

“SSMS consiste in un’utility completa la quale combina un ampio gruppo di

strumenti grafici con una serie di editor per lo sviluppo di script, al fine di fornire

Una delle feature principali di SSMS è Object Explorer (Figura 10), uno strumento grafico che permette di navigare, selezione e agire su tutti gli oggetti

all’interno del server SQL.

Figura 10 – Schermata di SSMS con Object Explorer

Le azioni che il tool consente di effettuare sono molteplici, come ad esempio:

assegnare i permessi riguardanti l’accesso ai database, svolgere operazioni di creazione, eliminazione e accesso, attraverso delle query, di quest’ultimi,

modellare le strutture dati all’interno dei database, come le tabelle nei database relazionali.

Durante il tirocinio ho utilizzato questo software costantemente: attraverso

l’editor di script, abbiamo realizzato tutto il codice SQL su cui si basano le

procedure di ETL, per mezzo delle quali abbiamo popolato il data warehouse; in generale, abbiamo usato tale editor ogni volta che si è reso necessario produrre uno script SQL, anche per operazioni banali e/o di routine sui database o sul data warehouse. Ovviamente, abbiamo sfruttato le funzionalità che lo strumento fornisce per creare, accedere, attraverso gli script, e gestire queste strutture dati. Infine, in quanto SSMS offre la possibilità di gestire le componenti di SQL Server, abbiamo usando il software per caricare i pacchetti di SSIS, corrispondenti alle procedure di ETL, sul data warehouse. Ciò è stato fatto per far

sì che il server schedulasse l’esecuzione di tali pacchetti con una certa frequenza

e i dati risultassero quindi sempre aggiornati.

3.1.2 SQL Server Integration Services

SQL Server Integration Services consiste, come già introdotto in precedenza, in una componente di SQL Server che ha lo scopo di effettuare le attività di estrazione, trasformazione e caricamento dei dati, meglio conosciute con

l’acronimo inglese ETL (Extract, Transform, Load). Questo strumento, infatti,

consente di generare dei pacchetti a cui viene assegnata una sorgente dati, da cui

quest’ultimi vengono presi, e una destinazione, nei quali essi vengono scritti. All’interno di ciascun pacchetto è possibile poi creare dei flussi di nodi di

svariate tipologie, a seconda delle operazioni che vogliamo performare. Tra questi nodi, ne esiste un tipo la cui mansione è quella di eseguire uno script SQL, chiamato nodo “Esegui SQL”. È facile intuire come questa categoria di nodi è stata utilizzata al fine di inserire all’interno di essi gli script che, di fatto,

svolgevano l’attività di ETL nel progetto.

Nel dettaglio, abbiamo creato un pacchetto SSIS per ciascun applicativo Apparound e ogni pacchetto, a sua volta, conteneva un nodo per ciascuna tabella presente nel relativo database; nei nodi era presente il codice SQL finalizzato a eseguire la procedura di ETL per quella determinata tabella.

Tutto questo è stato realizzato su Microsoft Visual Studio, mediante l’interfaccia che l’ambiente fornisce per Integration Services e le altre componenti di

Microsoft SQL Server. Per poter utilizzare questo servizio, è però necessario installare la relativa estensione direttamente da Visual Studio.

Infine, è doveroso specificare che è stata utilizzata la versione Community

dell’anno 2019.

3.2 Visual Studio

Visual Studio è un ambiente di sviluppo integrato (IDE, che sta per integrated development environment) prodotto da Microsoft. Esso consiste quindi in un software che supporta iprogrammatorinello sviluppo e nel debugging di codice attraverso una serie di strumenti.

Visual Studio è multilinguaggio e consente lo sviluppo di progetti per diverse piattaforme, tra cui quelle mobile. Inoltre, fornisce la possibilità di installare e utilizzare delle estensioni e delle componenti aggiuntive.

degli ambienti IDE, Visual Studio include compilatori, strumenti di completamento codice, finestre di progettazione con interfaccia grafica e altre funzionalità che semplificano il processo di sviluppo del software”.

Nella figura sottostante (Figura 11), corrispondente alla schermata principale del programma, vengono evidenziate alcune delle funzionalità che il software offre.

Figura 11 – Schermata principale di Visual Studio con focus sulle funzionalità che il sw fornisce Questo strumento è stato utilizzato nel mio progetto di tesi come ambiente per lo sviluppo delle procedure di ETL attraverso Integration Services. Infatti, come abbiamo già anticipato, Visual Studio fornisce un’interfaccia per i servizi di SQL Server, tra cui ovviamente Integration Services. Tuttavia per poter utilizzare Integration Services e creare quindi un progetto SSIS, è stato necessario eseguire l’installazione di questa componente aggiuntiva.

Dopo aver fatto questo, abbiamo sviluppato il progetto di Integration Services all’interno di questo ambiente di sviluppo, servendoci delle funzionalità che esso fornisce. Per esempio, attraverso l’interfaccia grafica è possibile selezionare le varie tipologie di nodi, i quali poi, in Integration Services, determinano il flusso di operazioni da eseguire, lavorare su più pacchetti e passare da uno all’altro, eseguire i singoli pacchetti in modo manuale e molto altro ancora.

3.3 Power BI

L’ultimo software di cui ci siamo serviti per sviluppare il progetto è Microsoft Power BI che, come abbiamo già nei capitoli precedenti dell’elaborato, consiste in uno strumento di data reporting, ovvero di analisi e visualizzazione dei dati. Infatti, come indicato nella documentazione ufficiale [6], Power BI consente di connettersi alle origini dati, le quali possono essere dei fogli di calcolo Excel o dei data warehouse, e costruire, a partire da esse, report interattivi attraverso un’interfaccia grafica semplice e intuitiva. Quest’ultima offre agli utenti delle visualizzazioni interattive e funzionalità di business intelligence per questi scopi. Nel dettaglio, Power BI è costituito da vari elementi che interagiscono tra di loro, di cui tre fondamentali; essi sono i seguenti:

 un’applicazione desktop per Windows chiamata Power BI Desktop;

 un servizio SaaS (Software as a Service) online denominato servizio Power BI;

 App Power BI per dispositivi mobili Windows, iOS e Android.

Per realizzare il progetto, abbiamo utilizzato principalmente il primo elemento, ovvero l’applicazione desktop di questo software. Con essa, è altresì possibile modellare i dati che vengono importati in Power BI. Infatti, tale strumento offre la possibilità di modificare le strutture dati, tipicamente delle tabelle, calcolando nuove colonne e nuove misure da utilizzare poi all’interno dei report.

Power BI permette di fare questo attraverso l’interfaccia grafica e, in modo più completo ma anche più complesso, mediante una libreria denominata DAX. Essa verrà trattata in maniera più approfondita nel capitolo successivo.

Oltre a questo, come già parzialmente visto, Power BI consente ovviamente di scegliere diverse tipologie di visualizzazione grafiche, come gli istogrammi e i grafici a torta, giusto per citarne due, per mezzo delle quali costruire i report. Una volta scelta la struttura grafica, è poi possibile selezionare, dai dati importati nel software, gli attributi (righe, colonne, misure e così via) con i quali popolare il report e mostrare l’informazione desiderata. E’ chiaramente permesso effettuare delle operazioni sui dati su cui il report si basa, in modo da ottenere la visualizzazione che si intendeva produrre.

Come oramai noto, nel mio progetto di tesi Power BI è stato utilizzato per evidenziare le informazioni insite nei dati degli applicativi Apparound, utilizzati

strumenti che il software offre, abbiamo potuto scegliere le visualizzazioni grafiche più opportune per rispondere a questo bisogno informativo, per poi selezionare e filtrare gli attributi che popoleranno i report, e creare, infine, quest’ultimi.

3.4 Linguaggi di programmazione e librerie

Poiché il mio lavoro si è incentrato, come abbiamo visto, nello sviluppo di codice che consentisse la migrazione di dati da database relazionali a un data warehouse

e nell’interrogazione, in generale, di queste strutture, ci siamo serviti del linguaggio standard per fare questo, ovvero l’SQL. In particolare, abbiamo utilizzato un’estensione di questo linguaggio chiamata Transact-SQL.

Inoltre, è stata utilizzata anche una libreria di Microsoft chiamata DAX (Data Analysis Expressions), il cui scopo è quello di modellare i dati in alcuni servizi Microsoft, tra cui Power BI.

3.4.1 Transact-SQL

Transact-SQL, conosciuto anche come T-SQL, consiste nell’estensione del linguaggio SQL (Structured Query Language) sviluppata da Microsoft. Questa

versione viene rilasciata insieme a Microsoft SQL Server attraverso un’unica

installazione.

T-SQL, essendo quindi un’estensione di SQL, ha i medesimi scopi di

quest’ultimo, il quale corrisponde al linguaggio standard per i database basati sul

modello relazionale (RDBMS). Tali propositi sono i seguenti:

 creare e modificare schemi di database, attraverso la parte del linguaggio

SQL conosciuta come DDL (Data Definition Language);

 inserire, modificare e gestire dati memorizzati, mediante il DML (Data

Manipulation Language);

 interrogare i dati memorizzati, tramite il DQL (Data Query Language);  creare e gestire strumenti di controllo e accesso ai dati, utilizzando il DCL

Per fare tutto ciò, il linguaggio mette a disposizione dello sviluppatore una serie di comandi da poter utilizzare. Per avere maggiori informazioni riguardanti

quest’ultimi e, in generale, per quanto riguarda la sintassi del linguaggio in

generale, è opportuno consultare la documentazione fornita da Microsoft [7]. Tuttavia, anche se gli scopi sono gli stessi, il linguaggio T-SQL aggiunge elementi non presenti nel SQL tradizionale, in quanto è un super-set di

quest’ultimo. Nello specifico, questo linguaggio estende SQL aggiungendo:  funzioni per controllo di flusso

 possibilità di definire variabili locali

 varie funzioni per la manipolazione di stringhe, date, espressioni

matematiche

 miglioramento delle istruzioni DELETE e UPDATE

Come già parzialmente spiegato, questo linguaggio è stato utilizzato nel corso del progetto per sviluppare gli script corrispondenti alle procedure di ETL e, in generale, ogni qualvolta si presentava la necessità di interrogare un database e acquisire dei dati per un certo proposito.

3.4.2 DAX

Come afferma la documentazione ufficiale [8],DAX (Data Analysis Expressions) consiste in un linguaggio di espressioni delle formule usato in Power BI e in altri prodotti Microsoft come Analysis Services e Power Pivot di Excel. Le formule DAX includono funzioni, operatori e valori per eseguire query e calcoli avanzati sui dati presenti in tabelle e colonne correlate nei modelli di dati tabulari. Con questa libreria è possibile, per esempio, produrre dei nuovi campi per una certa tabella già esistente, e aggiungerli ad essa. Questi campi possono essere di vario tipo; tuttavia, quelli che più comunemente vengono calcolati sono le misure, ovvero degli attributi dinamici che vengono utilizzati all’interno dei report, e le colonne calcolate, corrispondenti a delle colonne determinate da una formula DAX che ne definisce i valori. Di seguito, riportiamo un semplice esempio della prima tipologia di campo:

In un ipotetico report, se un utente inserisce la misura “Total Sales” e inserisce anche una qualsiasi colonna come filtro, tale misura verrà calcolata in modo

dinamico sulla base dei record che non vengono scartati dal filtro. In altre parole, appare ovvio come il valore di “Total Sales” sia mutevole e che, quindi, necessita di essere ricalcolato ogni volta.

Durante il progetto, abbiamo utilizzato questo linguaggio proprio per effettuare operazioni del genere su Power BI, il tool di data reporting di cui ci siamo serviti. Infatti, una volta che il data warehouse è stato collegato al software e i dati sono stati importati al suo interno, talvolta si è presentata la necessità di modificare una colonna (per esempio, il tipo) di una certa tabella, oppure di crearne una nuova, o di calcolare una misura sulla base degli attributi esistenti.

Questo è stato fatto ovviamente al fine di generare dei report o di ottenerne di migliori, in quanto essi sono costruiti direttamente sui dati importati dal data warehouse.

4 Sviluppo del progetto

Questo capitolo è dedicato alla descrizione di tutto il lavoro da me svolto durante il tirocinio. Nello specifico, vedremo le modalità di progettazione e sviluppo del data warehouse, così come delle procedure di ETL, le quali consentono di popolare esso a partire dai sistemi TiT e di mantenere i dati ottenuti sempre aggiornati.

Inoltre, parleremo anche delle migliorie apportate alla reportistica Power BI, mostrando alcuni dei nuovi report che abbiamo prodotto sfruttando i dati a disposizione e spiegando come essi sono stati realizzati.

Infine, il ruolo di questa sezione sarà anche quello di discutere tutto quello che concerne le scelte progettuali e implementative, fornendo le relative motivazioni.

4.1 Progettazione e implementazione del data warehouse

Per ovviare alle criticità illustrare nelle sezioni precedenti, le quali caratterizzavano la vecchia procedura di acquisizione e aggiornamento dei dati, abbiamo deciso di adottare una soluzione incentrata sulla realizzazione di un data warehouse relazionale su DBMS Microsoft SQL Server.

Per questa circostanza, la decisione si è rivelata ovvia sia da parte mia sia da

parte dell’azienda, in quanto la soluzione tipica per scopi del genere consiste proprio nell’implementazione di un data warehouse. Infatti, come già spiegato

nel capitolo introduttivo di questo elaborato, esso permette di raccogliere grandi quantità di dati, i quali talvolta vengono elaborati e organizzati in modo da essere fruibili nel miglior modo possibile da strumenti di analisi e visualizzazione di dati come Power BI. Inoltre, con esso è possibile anche ovviare alla problematica

riguardante l’aggiornamento dei dati, attraverso l’utilizzo degli strumenti che

Microsoft SQL Server mette a disposizione. A questo proposito abbiamo sfruttato la componente chiamata SQL Server Integration Services, la quale ci ha consentito di sviluppare le procedure di ETL attraverso cui si riesce ad acquisire automaticamente i dati dagli applicativi TiT secondo una certa frequenza

temporale, eseguendo così un aggiornamento periodico di quest’ultimi, e a salvarli all’interno della struttura dati.

In conclusione, la realizzazione del data warehouse ci ha permesso di avere una struttura finalizzata alla raccolta dati adeguata, sulla quale poi adattare la reportistica Power BI già sviluppata da Apparound e, soprattutto, produrne di nuova, in maniera più agevole e sistematica, sfruttando la quantità e la completezza dei dati a disposizione che abbiamo ottenuto.

Per ciò che invece concerne l’aspetto architetturale del data warehouse in

questione, non è stato altrettanto ovvio scegliere la soluzione che risultasse migliore per le nostre esigenze. Infatti, come emerge consultando la numerosa letteratura che tratta questo tema, esistono vari modelli architetturali da poter implementare per quanto riguarda il data warehousing. La decisione è influenzata

ovviamente dalle esigenze dell’azienda, sia in termini tecnici, sia per questioni

economiche e temporali.

Per prendere questa decisione, abbiamo analizzato i modelli architetturali descritti nel libro di testo adottato dal corso di Decision Support Databases [9]. In particolare, abbiamo optato per una delle soluzioni più comuni da adottare in questo ambito: il modello a tre strati (three-layer architecture). Questa soluzione risulta essere probabilmente quella più completa ed efficiente tra quelle esaminate ma, allo stesso tempo, più laboriosa da implementare.

Il modello architetturale a tre strati si presenta come segue in Figura 12.

Figura 12 – Modello architetturale a tre strati

I tre strati in questione corrispondono alle sorgenti dati, al data staging e al data warehouse, come visibile nella figura soprastante. Nello specifico, questo modello architetturale si distingue dagli altri per la presenza dello strato chiamato data staging, corrispondente solitamente a un vero e proprio database operazionale che si interpone tra le sorgenti dei dati e il data warehouse.

In particolare, questa struttura si occupa di raccogliere i dati ottenuti dalle varie fonti, i quali vengono poi preparati per essere caricati nel data warehouse.