Progettazione e implementazione di un sistema di Business Intelligence nel contesto del Gruppo Lipari

Dipartimento di Informatica

Corso di Laurea Magistrale in Data Science and Business Informatics

TESI DI LAUREA

PROGETTAZIONE E IMPLEMENTAZIONE DI UN SISTEMA DI BUSINESS INTELLIGENCE NEL CONTESTO DEL GRUPPO

LIPARI

RELATORE

Dott. Giulio ROSSETTI TUTORE AZIENDALE Dott. Giovanni LIPARI

CANDIDATO Davide SAVASTA Matr. n. 550502

Abstract

Viene presentata la progettazione e successiva realizzazione di un

sis-tema di Business Intelligence a supporto dei diversi processi aziendali

operanti nel Gruppo Lipari. Vengono riportate tutte le fasi di data

ware-housing coinvolte per la realizzazione del progetto: studio dei processi,

analisi dei requisiti, progettazione, analisi degli strumenti (open-source)

impiegati, procedure di ETL, analisi dei dati e reportistica. Ogni fase

citata `e stata seguita e realizzata in prima persona con il sostegno di

fig-ure funzionali aziendali. Per ogni soluzione individuata vengono riportate

le scelte che hanno condotto a tale scenario, analizzandone pro e

con-tro. In conclusione vengono mostrati in termini di dashboard i risultati

Contents

1 INTRODUZIONE 4

1.1 Analisi della natura e dei fini aziendali . . . 4

1.1.1 Lipari Consulting . . . 5

1.1.2 Lipari Technology . . . 9

1.2 Presentazione dell’obiettivo aziendale e benefici ricercati . . . 10

1.3 Rassegna della letteratura . . . 13

1.4 Contenuto Tesi . . . 14

2 PROGETTAZIONE DATA WAREHOUSE 16 2.1 Requisiti . . . 16

2.1.1 Analisi processi significativi . . . 16

2.1.2 SALES . . . 19

2.1.3 PKM . . . 22

2.1.4 HR . . . 25

2.1.5 Specifica dei requisiti . . . 29

2.2 Progettazione concettuale iniziale . . . 36

2.3 Progettazione concettuale dei dati AS-IS . . . 38

2.4 Progettazione concettuale finale . . . 46

2.5 Progettazione logica . . . 48

3 AMBIENTE DI SVILUPPO 52 3.1 Dati AS-IS Excel . . . 52

3.2 Microsoft SQL Server . . . 53

3.2.1 Microsoft Power BI . . . 58

3.3 Qlikview . . . 59

3.4 Anaconda - Jupyter . . . 61

4 PROCESSO ETL - ESTRAZIONE, TRASFORMAZIONE E CARICAMENTO 62 4.1 Il processo ETL . . . 62

4.2 Software ETL . . . 64

4.3 Estrazione dei dati . . . 65

4.4 Trasformazione dei dati . . . 67

4.5 Caricamento dei dati . . . 69

5 ANALISI KPI E REPORTISTICA 70 5.1 Reportistica e KPI: Sales . . . 70

5.2 Reportistica e KPI: Recruiting . . . 76

6 CONCLUSIONI 80 6.1 Sviluppi futuri . . . 82 List of Figures 84 List of Tables 85 References 86 Ringraziamenti 87

1

INTRODUZIONE

1.1

Analisi della natura e dei fini aziendali

Lipari Consulting e Lipari Technology sono due societ`a fondate da Giovanni Lipari, per fornire alle societ`a di consulenza direzionale e tecnologica un inno-vativo servizio di consulenza in partnership. Questa si traduce nella possibilit`a di innestare nei team progettuali del Partner dei talentuosi consulenti Lipari. Le grandi societ`a di consulenza partner apprezzano le competenze e la pro-fessionalit`a dei consulenti Lipari, riconoscendo i benefici della collaborazione: velocit`a nel costituire team progettuali per rispondere alle richieste dei clienti e flessibilit`a delle risorse per gestire picchi e contrazioni di mercato.

La filosofia Lipari mette al centro di tutto la crescita personale e profession-ale delle sue persone. Gli oltre 150 dipendenti hanno iniziato la loro carriera lavorativa in Lipari da neolaureati, intraprendendo un percorso di formazione in linea con la cultura aziendale orientata alla crescita interna dei leader e manager del futuro. L’alta qualit`a del servizio Lipari riconosciuta dal mercato `e garan-tita dalla selezione dei migliori talenti, da un percorso di formazione continua in competenze, soft skill e dall’attenzione alle inclinazioni personali e professionali delle persone in azienda.

La mission dell’azienda `e la seguente:

“Grazie ai nostri Professionisti della consulenza, coinvolti nelle progettualit`a dei nostri Partner, offriamo competenza, flessibilit`a e tempestivit`a. La garanzia di alta qualit`a deriva da:

• selezione dei migliori talenti, grazie a solide relazioni con le universit`a • formazione continua in competenze e soft skill, tramite Lipari Academy • attenzione alle inclinazioni personali e professionali, grazie ad un costante

dialogo con le nostre persone

• acquisizione di molteplici esperienze professionali, attraverso la collabo-razione con i diversi Partner ”

Per quanto concerne vision e valori:

”Diventare una Multinazionale (azienda in forte crescita) che aiuti le PER-SONE a valorizzare i propri Talenti.

• Relazioni e Fiducia: a noi piace investire in relazioni di lungo periodo • Entusiasmo e Motivazione: siamo un Team di Persone appassionate che

crede in ci`o che fa

• Partecipazione: coinvolgimento attivo delle Persone nelle dinamiche azien-dali

• Comunit`a: proviamo a restituire ai territori di appartenenza”

[11]

1.1.1 Lipari Consulting

Sin dalla sua costituzione nel 2007, la Lipari Consulting ha ricercato ed assunto i migliori talenti delle facolt`a di Ingegneria Gestionale ed Economia, offrendo loro un percorso di crescita ricco di molteplici esperienze progettuali e di col-laborazioni con diversi partner.

Il valore professionale e umano dei consulenti Lipari Consulting, unitamente ai vantaggi dell’innovativo servizio offerto, ha generato nel mondo del manage-ment consulting, operante prevalentemanage-mente nel settore dei Financial Services, un passaparola positivo che ha spinto l’azienda a crescere velocemente nel corso degli anni, al punto da diventare leader in Italia della consulenza in partnership.

Ad oggi l’azienda vanta pi`u di 500 collaborazioni in progetti svolti sia in Italia che all’estero nei mercati Banking, Insurance, Energy, Telco, GDO. Tra i principali settori d’intervento troviamo: Energy, Banking, Consumer Credit, Media, Insurance.

I principali ambiti d’intervento invece si presentano come:

• COMPLIANCE

– Lo studio, l’analisi e il reperimento delle normative nazionali ed eu-ropee

– Identificazione gap (organizzativi, tecnologici e di processo) e propo-sizione di specifici interventi per sostenere i cambiamenti introdotti dalle nuove normative

– Definizione delle metodologie di valutazione dei rischi di conformit`a • RISK MANAGEMENT

– Identificazione rischi aziendali

– Valutazione qualitativa e quantitativa dei rischi, probabilit`a e im-patto (economico, normativo, reputazionale)

– Definizione controlli e misure di gestione del rischio • MARKETING

– Supporto nella definizione e lancio delle campagne commerciali – Definizione strategia di vendita multicanale

– Analisi Benchmarking e ricerche di mercato • DIGITAL

– Strategie di digital marketing per il potenziamento dei canali web (vendita, comunicazione, etc.)

– Design ed implementazioni di soluzioni multicanale (es. app, mobile site)

– Restyling portali web e siti internet per il miglioramento della cus-tomer experience

• MERGER AND ACQUISITION

– Governance di prodotti di acquisizione e fusione

– Gestione attivit`a di migrazioni applicative e porting infrastrutturali • ORGANIZATION

– Definizione e implementazione di modelli organizzativi e operativi; – Implementazione modelli di sizing;

– Analisi degli impatti di modifiche organizzative e change manage-ment.

• IT GOVERNANCE

– Gestione processi di sviluppo software;

– Implementazione modelli di gestione servizi IT;

– Analisi soluzioni IT e tool per il miglioramento delle performance aziendali.

• FINANCE

– Definizione modelli di cost allocation; – Razionalizzazione processi di budgeting; – Definizione tool di reporting;

– Disegno piattaforme di Wealth management. • BUSINESS STRATEGY

– Analisi di mercato e benchmark su modelli e soluzioni presenti nel contesto internazionale;

– Stesura business plan.

All’interno di ognuno di questi ambiti, l’azienda applica diverse competenze attraverso propri consulenti. Tra queste ritroviamo:

• PROJECT GOVERNANCE

– Stesura, gestione e monitoraggio piano di lavoro; – Gestione criticit`a progettuali;

– Capacity plan; – Cost control;

– Monitoraggio e valutazione rischi di progetto; – Reporting.

• BUSINESS ANALYSIS – Analisi fattibilit`a; – Partner selection;

– Definizione requisiti di business; – Business case;

– Definizione modelli di servizio; – Lancio campagne commerciali. • PROCESS ANALYSIS

– Analisi e valutazione As-Is dei processi;

– Mappatura processi attraverso i principali tool di mercato; – Re-design e implementazione processi To-Be.

– Raccolta requisiti funzionali;

– Stesura documenti di specifiche funzionali di un software/app; – Software selection;

– Definizione modelli di integrazione IT; – Training e redazione manuali utente. • SOFTWARE CERTIFICATION

– Definizione strategia di test management; – Redazione master test plan;

– Stesura documenti di test funzionali; – Attivit`a di UAT;

– Test Reporting.

[11]

1.1.2 Lipari Technology

Considerata l’esponenziale evoluzione tecnologica negli ultimi anni e la crescente richiesta di competenze informatiche, nasce a marzo 2018 la Lipari Technology che, adottando lo stesso modello di collaborazione vincente della Lipari Con-sulting, offre ai propri partner un servizio di eccellenza tramite risorse con com-petenze relative alla progettazione, sviluppo software e alla data science.

Oggi Lipari Technology conta pi`u di 20 risorse e mira ad una repentina crescita gi`a nel breve periodo, rispecchiando cos`ı l’andamento della Consulting.

Fattori critici di successo:

• Approccio strutturato ed elevati standard professionali;

• Risorse con expertise maturata in diversi settori e con diverse societ`a di consulenza partner;

• Costante attenzione ai bisogni dei clienti; • Massima affidabilit`a e tempestivit`a;

• Cura nella selezione e nella formazione delle risorse.

Lipari Technology grazie al forte network acquisito sul territorio nazionale, offre servizi di Consulenza IT e di Sviluppo Software in Partnership con i pi`u grandi System Integrator internazionali. Il settore in cui opera principalmente `

e il Finance (Banking e Insurance), tuttavia in volumi inferiori opera anche in altri settori. Tra i servizi offerti ritroviamo:

• Sviluppo software a 360 gradi (BE e FE); • Data Science;

• Business Intelligence; • Business Analytics; • Low Code.

[11]

1.2

Presentazione dell’obiettivo aziendale e benefici

ricer-cati

Al giorno d’oggi le aziende di tutte le dimensioni sono sempre alla ricerca di strumenti, strategie e soluzioni per migliorare la propria capacit`a di essere com-petitivi nei confronti della concorrenza. Tuttavia ogni tentativo di migliora-mento o di ottimizzazione ha bisogno di essere analizzato e valutato secondo degli indicatori di cui spesso i dirigenti o i responsabili hanno una conoscenza non sempre precisa e puntuale, e che spesso necessita di essere ponderata con la propria esperienza di dominio. Eppure l’avanzamento delle tecnologie e degli strumenti informatici all’interno di quasi tutte le realt`a aziendali hanno portato

ad un aumento significativo delle informazioni a disposizione della catena ges-tionale.

Il problema consiste nel non riuscire ad utilizzare questa ingente mole di informazioni per ricavare indicatori (KPI) chiari ed efficaci per la valutazione delle prestazioni di un determinato processo aziendale. Lo scopo principale della tecnologia dei data warehouse `e proprio quello di riorganizzare e sintetizzare le informazioni immagazzinate dai sistemi operazionali permettendo di condurre analisi immediate sull’andamento di determinati processi.

Il data warehouse oggetto di tesi `e progettato per il Gruppo Lipari. La sempre pi`u rapida espansione della realt`a aziendale ha generato la necessit`a di sviluppare un sistema che sia in grado di gestire e customizzare la crescente mole di informazioni generate nel corso degli anni.

Attualmente non vi `e la presenza di un sistema centralizzato comune a tutti i reparti aziendali, i quali devono gestire i rispettivi dati attraverso soluzioni in-dipendenti, come ad esempio fogli Excel. Questo non consente una condivisione delle informazioni tra i diversi settori, in quanto tale strategia non permette la comunicazione tra i vari moduli informativi. Se ad esempio il CEO necessita alcune informazioni sul numero di assunzioni in un dato periodo di tempo dovr`a interfacciarsi con il responsabile del settore di competenza per ricevere tali dati, dilatando cos`ı la latenza nel ricevere tali informazioni.

L’utilizzo dei fogli Excel comporta numerose difficolt`a per l’analisi e la ges-tione dei processi interni aziendali. Tra queste ritroviamo:

• incongruenze nei dati tra i diversi fogli utilizzati;

• non vi `e comunicazione tra i diversi fogli e le informazioni utili devono es-sere trasmesse tramite tabelle/report generati manualmente o addirittura

a voce;

• non permette una visione completa delle performance aziendali, sia nella sua interezza che nei singoli reparti;

• limiti nel filtraggio e nella ricerca di informazioni;

• non consente un’analisi periodica di KPI fondamentali per l’analisi delle prestazioni interne;

• confusione nella gestione dei diversi fogli;

• tempistiche inadeguate nell’elaborazione e nello scambio delle informazioni. Per poter centralizzare il sistema di fruizione e manipolazione delle infor-mazioni e quindi condividere quelli che sono i dati utili per tutti i settori, si necessita la progettazione e la customizzazione di un sistema di business intel-ligence aziendale. Nello specifico l’esigenza aziendale `e quella di realizzare un data warehouse che contenga tutti i dati delle operations aziendali, ne consenta l’elaborazione dei KPI e la fruizione degli stessi attraverso uno strumento di re-porting. Verr`a cos`ı realizzato un sistema End-to-end che attraversa ogni reparto aziendale in modo da:

• fornire al CEO una visione completa delle performance di ogni comparto; • consentire ad ogni responsabile di area una gestione ottimale e una visione

completa delle prestazioni del proprio ramo; • favorire la comunicazione tra le diverse aree;

• condividere dati e informazioni fra i diversi rami aziendali; • estrapolare KPI fondamentali per i processi aziendali.

In questa fase progettuale `e stato proposto un PoC che consenta di porre le basi per la realizzazione del sistema di BI citato in precedenza. Attraverso questo modello sar`a possibile apprezzare i benefici che l’applicazione di queste tecnologie pu`o apportare.

La sua realizzazione `e partita da un’analisi dell’AS-IS aziendale, ovvero uno stu-dio accurato sullo stato dell’arte e sull’ambiente di lavoro. Questo si `e tradotto dunque in una raccolta di requisiti principali che il sistema deve presentare. La raccolta `e stata effettuata in termini di KPI che fossero in grado di quantificare le performance aziendali, al fine di fornire utili indicazioni agli owner delle at-tivit`a.

I dati necessari per poter soddisfare tali requisiti vengono estrapolati dai fogli excel redatti dai responsabili delle aree aziendali. Questi vengono sottoposti a numerose manipolazioni al fine di renderli pronti ad essere interrogati.

Tutti gli aspetti di questo stream progettuale sono stati seguiti e portati avanti in prima persona con l’appoggio di figure interne aziendali per quanto riguarda gli aspetti ”funzionali” del sistema. L’aspetto pi`u critico incontrato nella realiz-zazione si `e concretizzato nell’estrazione e nel trattamento dei dati. Trattando dei file excel redatti da attori differenti, il livello di entropia incontrato nelle informazioni era estremamente elevato. Difatti sono stati numerosi gli sforzi impiegati per poter unificare ed adeguare le informazioni al modello progettato.

1.3

Rassegna della letteratura

Per il design del data warehouse `e possibile seguire due differenti approcci: Data driven o Analysis driven. L’approccio Data driven presenta una strategia top-down, ovvero viene realizzato un DWH basandosi sui dati disponibili, a partire dal quale creare i data marts candidati. Questo viene fatto analizzando il mod-ello concettuale dei dati, se disponibile, o i layout dei record logici effettivi e selezionando gli elementi dei dati ritenuti interessanti. Tale approccio `e l’unico possibile nel momento in cui non vi `e un documento di requisiti contenente le esigenze per la creazione del sistema. Queste verranno estrapolate, con l’ausilio dell’utente finale, a partire dal DW sviluppato, al fine di scoprire nuovi modi in cui utilizzare i dati disponibili e identificare le aree su cui concentrare gli sforzi di sviluppo del data warehouse. Lo svantaggio di questo approccio `e che senza il coinvolgimento dell’utente c’`e il rischio di produrre un risultato non interessante.

L’ approccio Analysis driven `e stato originariamente proposto da Kimball, un noto autore sul tema del data warehousing. Tale metodologia presenta una strategia bottom-up, il cui obiettivo consiste nel progettare prima i data mart basati sull’analisi dei dati che gli utenti vogliono eseguire, per poi integrarli al fine di costruire il DW. Il principale vantaggio di questo approccio consiste nel porre l’attenzione su ci`o che `e veramente necessario, piuttosto che su ci`o che `e disponibile. In generale, questa metodologia ha un ambito pi`u limitato rispetto all’approccio basato sui dati. Lo svantaggio si concretizza nel rischio che alcuni dei dati di cui l’analisi necessita non siano disponibili.

Per il design e la progettazione del sistema si `e scelto una combinazione dei due approcci appena descritti: per l’analisi dei processi aziendali si `e fatto riferimento alla metodologia Analysis driven proposta in Kimball[1], invece per lo sviluppo dei data mart candidati ci si `e concentrati sull’approccio Data driven.

La realizzazione di ogni singola fase progettuale `e stata portata avanti sec-ondo le indicazioni e i concetti presenti in ALbano [2], all’interno del quale vengono affrontati i diversi aspetti e i diversi approcci per la realizzazione di un data warehouse. Tali metodologie sono state arricchite e approfondite dai concetti presenti in Kimball [1], una guida completa per il data warehousing.

1.4

Contenuto Tesi

L’obiettivo di tesi rappresenta la progettazione di un sistema di Business Intelli-gence all’interno di un contesto aziendale. Questo dovr`a permettere la gestione automatizzate delle informazioni e l’elaborazione di KPI di rilevanza per le sin-gole aree aziendali al fine di incrementare il proprio potere commerciale. Il processo si articola in diverse fasi ognuna delle quali descritta in tutti i suoi aspetti nei capitoli seguenti.

All’interno del capitolo 2 viene descritta la progettazione del data warehouse attraverso le sue componenti: analisi dei requisiti e progettazione. Successiva-mente nel capitolo 3 sono riportate le informazioni riguardo l’AS-IS dei dati in esame e sugli ambienti di sviluppo adoperati. I capitoli 4 e 5 descrivono rispet-tivamente il processo di etl e l’analisi dei KPI rafforzate da rappresentazioni grafiche. Infine vengono riportate le conclusioni con gli obiettivi posti per il proseguo della realizzazione.

2

PROGETTAZIONE DATA WAREHOUSE

2.1

Requisiti

2.1.1 Analisi processi significativi

Di seguito vengono analizzati i processi ritenuti significativi all’interno del con-testo aziendale.

Nella figura seguente possiamo osservare l’albero della struttura dell’azienda, articolato in 4 componenti:

• CEO

– Monitoraggio complessivo delle attivit`a aziendali; – Rapporti con i clienti.

• SALES

– Gestione contatto Clienti; – Ricerca prospect;

– Gestione delle richieste per nuove opportunit`a; – Gestione delle negoziazioni;

– Staffing delle risorse nei team Partner. • PKM

– Valutazione delle risorse aziendali; – Valutazione dei progetti in carico;

– Valutazione andamento aziendale in base alla valutazione delle risorse coinvolte nei progetti;

– Gestione knowledge delle risorse; – Organizzazione formazione delle risorse. • HR

– Attivit`a di Recruiting di nuove risorse; – Censimento Universit`a.

Per ognuna delle attivit`a citate sono state effettuate delle interviste con i relativi responsabili al fine di estrapolare le principali esigenze.

Attraverso il questionario `e stato possibile estrapolare importanti informazioni per ogni area aziendale, alcune delle quali comuni a tutte le componenti. Tali domande sono state prodotte a seguito di uno studio accurato sulla natura e composizione aziendale. Prima di effettuare le interviste specifiche, sono stati effettuati dei colloqui preliminari con i responsabili delle attivit`a. Attraverso questi incontri `e stato possibile comprendere in prima battuta le esigenze richi-este dal sistema desiderato cos`ı da poter stabilire una guida per la raccolta delle informazioni utili.

Il questionario proposto consente cos`ı di individuare gli aspetti fondamentali indipendentemente dall’attivit`a a cui si sta facendo riferimento.

2.1.2 SALES

L’attivit`a Sales rappresenta il cuore delle operazioni aziendali in quanto si con-cretizza nella gestione e finalizzazione delle richieste dei clienti in maniera proat-tiva o reatproat-tiva.

Di seguito `e possibile osservare il flusso di eventi / operazioni che portano a ci`o.

1. Gestione richieste

(a) Ricezione diretta di richiesta da parte del cliente;

(b) Proporre al cliente proattivamente un profilo sulla base delle richieste storiche.

2. Contatto (telefonico o incontro fisico) con il cliente per approfondimento sull’opportunit`a al fine di chiarire a 360 le caratteristiche della richiesta (owner: Sales).

3. Delineata nei dettagli la richiesta si avvia un confronto con PKM per cen-sire le risorse (disponibili) adatte per realizzare tale richiesta. La ricerca della risorsa avverr`a per:

(a) Ruolo;

(b) Livello seniority; (c) Esperienze progettuali; (d) Skills tecniche;

(e) Orientamento risorsa (si pone l’attenzione sulle preferenze personali). 4. Individuata la risorsa interna si inoltra il profilo Lipari al cliente in attesa

di un feedback:

(a) OK – la risorsa `e adeguata, si avvia la fase di negoziazione (costi, tempi, tariffa, tempi di start, durata ingaggio);

(c) KO – la risorsa risulta adeguata da CV ma a seguito; dell’incontro con il Cliente non riceve un feedback positivo, si riparte dal punto 3.

A seguito dell’intervista effettuata con il principale responsabile dell’attivit`a, `

e stato possibile estrapolare una serie di KPI fondamentali ai fini della realiz-zazione del sistema.

• Tempo di risposta per una richiesta ricevuta dal cliente (dati del cliente se ha partecipato in passato ad altre collaborazioni);

• Numero di richieste ricevute per periodo (mese, trimestre, anno) e per cliente;

• Numero opportunit`a OK per periodo (mese, trimestre, anno), cliente e commerciale;

• Numero opportunit`a KO per periodo (mese, trimestre, anno), cliente e commerciale;

• Rapporto opportunit`a OK / tot.Opportunit`a per periodo (mese, trimestre, anno), cliente e commerciale;

• Rapporto opportunit`a KO / tot.Opportunit`a per periodo (mese, trimestre, anno), cliente e commerciale;

• Rapporto opportunit`a OK / KO;

• Numero incontri con clienti per periodo (mese, trimestre, anno), per tipolo-gia di incontro (primo incontro, operativo con partner, operativo con man-ager, presentazione risorsa), per commerciale (interno);

• Fatturato delle risorse per periodo (giorno, settimana, mese, trimestre, anno), risorsa e cliente;

• Costi di staffing delle risorse per periodo (giorno, settimana, mese, trimestre, anno), risorsa e cliente.

Risulta opportuno spendere maggiore attenzione verso gli ultimi due KPI riportati poich`e rappresentano l’effettivo margine aziendale.

Nella tabella seguente vengono specificati i requisiti per l’attivit`a di riferi-mento.

• (1) E’ importante analizzare la proattivit`a aziendale nel rispondere alle richieste pervenute dai clienti. Tale valore pu`o rappresentare un indicatore di solidit`a aziendale e tempestivit`a nel cogliere le opportunit`a di mercato; • (2) Consente di censire i periodi di maggior / minor affluenza di richi-este cos`ı da poter clusterizzare i clienti in: abituali, churned, fidelizzati. (esemplificativo)

• (3-7) Metriche che consentono di estrapolare l’efficacia aziendale nei con-fronti dei clienti (efficacia dei commerciali)

• (8-9)Consentono di valutare l’efficacia aziendale in termini eco-nomici (di maggior interesse per l’attivit`a Sales)

2.1.3 PKM

L’attivit`a di PKM consiste principalmente nella gestione e nella formazione delle risorse interne. Per poter supportare in modo adeguato e performante queste operazioni, gli owners dell’attivit`a necessitano di un prospetto sempre aggiornato e consistente sulle risorse e sui progetti in cui vengono coinvolti.

Tra le mansioni di competenza di tale attivit`a ritroviamo:

• Valutazione annuale delle risorse: in base al feedback fornito dal cliente viene calcolata una metrica interna;

• Calcolo statistiche relative ai progetti su cui vengono staffate i consulenti; • Analisi dei progetti per risorsa

– Inizio progetto – Fine progetto – Descrizione progetto – Ruolo ricoperto – Tipologia progetto.

Per far ci`o i responsabili di tali attivit`a dovranno disporre di un’anagrafica completa delle risorse e dei progetti per poter concretizzare la gestione efficace-mente.

Qu`ı possiamo osservare alcuni esempi di metriche d’interesse per il PKM:

• Distribuzione sesso risorse all’interno dell’azienda;

• Statistiche legate ai costi risorsa, utili per la comunicazione con l’attivit`a Sales (tipologia contratto, stipendio, fiscalit`a);

• Valutazione Retention.

Nella tabella vengono specificati i requisiti per l’attivit`a di riferimento.

Figure 3: Requisiti PKM

• (1-2) Poich´e l’azienda opera in diversi ambiti (Compliance, Marketing, Risk Management, Finance, Business Strategy, etc.), atraverso diverse competenze (Process Analysis, Business Analysis, Project Governance,

etc.), `e importante tenere traccia dei progetti in cui le risorse sono coin-volte, cos`ı da analizzare la distribuzione delle partecipazioni per Industry al fine di avere un quadro completo e preciso.Questo pu`o essere di sup-porto ai manager per comprendere quali sono i settori in cui l’azienda risulta avere maggiore penetrazione e con quali competenze;

• (3) La bont`a aziendale rappresenta un indicatore fondamentale per com-prendere il valore dell’operativit`a presso i clienti. Questa viene elaborata in base alle schede di valutazione sottomesse ai clienti stessi riguardo le risorse aziendali; i giudizi espressi nella scheda (spesso redatta in linguag-gio naturale) vengono tradotti in valori numerici (una scala da 1 a 5) in base ai quali estrarre i parametri per valutare le risorse e quindi le perfor-mance aziendale. (esempio calcolo indicatore);

• (4) La Retention (% risorse che lasciano l’azienda / % risorse trattenute in azienda) rappresenta uno degli indicatori pi`u importanti sia per il PKM che per l’area Sales al fine di comprendere il flusso di risorse tra l’azienda e i clienti;

• (5) Di fondamentale importanza `e avere un overview sui dati relativi ad ogni singola risorsa, in modo tale da mappare:

1. Provenienza 2. Dati anagrafici

3. Progetto sul quale la risorse `e staffata 4. Data inizio e data fine del progetto

5. Competenze risorsa (pregresse e maturate).

L’analisi per periodo indicata nei requisiti va intesa come analisi per setti-mana, mese, trimestre e anno.

2.1.4 HR

L’attivit`a di HR si concretizza prevalentemente nel Recruiting di nuove risorse. Ci`o avviene attraverso l’analisi e successiva selezione dei CV di interesse presenti negli attuali strumenti informativi a disposizione.

Dal punto di vista delle risorse, questo rappresenta il punto di accesso al mondo Lipari.

Punto cardine di tale attivit`a consiste dunque nel censimento dei profili rac-colti nelle varie attivit`a di promozione aziendale (annunci, recruiting day, eventi universitari, sito aziendale). Questi dovranno essere catalogati in base a diversi criteri come facolt`a e universit`a di provenienza.

Per far ci`o l’attivit`a dovra avere a disposizione un archivio esaustivo riguardo i profili raccolti e le universit`a con cui si entra in contatto. In questo modo la ricerca potr`a essere pi`u performante, incrociando i dati dei candidati con quelli relativi alle univesit`a al fine di estrapolare KPI target e trend significativi.

Qui possiamo osservare alcuni esempi di metriche d’interesse per l’HR:

• Distribuzione candidature per territorio; • Distribuzione candidature per universit`a;

• Studio della periodicit`a delle candidature al fine di osservare i periodi di maggior affluenza;

• Numero di conversioni;

• Studio delle universit`a con maggior potenziale.

Nella tabella seguente vengono specificati i requisiti per l’attivit`a di riferi-mento.

Figure 4: Requisiti HR

• (1) Per l’area `e molto importante capire qual `e l’universit`a con il mag-gior flusso di CV, in modo tale da concentrare magmag-giormente su queste il processo di recruiting;

• (2) Il numero di conversioni indica il numero di candidati che, una volta sostenuti i colloqui, vengono assunti dall’azienda;

• (3) Consente di capire la disponibilit`a delle Universit`a nei diversi periodi dell’anno, cos`ı da poter organizzare operazioni o eventi di recruiting in quelle finestre temporali;

• (4) Requisito utile per il censimento delle candidature ricevute.

L’analisi per periodo indicata nei requisiti va intesa come analisi per setti-mana, mese, trimestre e anno.

Figure 5: Report sul numero di colloqui per anno ed universit`a

Ecco un esempio di alcuni report raccolti durante l’analisi delle fonti dati fornite. Tali report sono stati realizzati a partire da estrazioni effettuate sui fogli excel contenenti i dati sulle candidature.

La dashboard presenta due diversi grafici:

1. Numero di colloqui per Universit`a di provenienza 2. Numero di colloqui per periodo (anno, trimestre, mese)

Di seguito vengono riportati ulteriori visualizzazioni dei grafici proposti, ot-tenute grazie ad un’operazione di Drill-down.

Figure 6: Report sul numero di colloqui per trimestre ed universit`a

2.1.5 Specifica dei requisiti

Di seguito si analizzano in modo pi`u approfondito i requisiti presentati nelle sezioni precedenti al fine di produrre una modulistica che evidenzi quali sono i fatti, le misure e le dimensioni coinvolte. Dai processi esposti in precedenza emergono 3 fatti interessanti:

• la gestione delle richieste / commesse ad opera degli owner dell’attivit`a SALES ;

• la gestione delle risorse sui progetti ad opera degli owner dell’attivit`a di PKM ;

• l’attivit`a di recruiting delle risorse ad opera degli owner dell’attivit`a di HR.

Nella seguente tabella vengono associati ad ogni requisito di analisi le di-mensioni, le misure e le aggregazioni coinvolte.

Figure 8: BR Sales

Figure 10: BR HR

Successivamente si specifica la granularit`a dei fatti, ovvero il liv-ello di dettaglio con il quale le informazioni vengono trattate.

Figure 11: Granularit`a dei fatti

Si elenca quindi la lista delle dimensioni ricavate evidenziandone la gran-ularit`a e la metodologia da utilizzare per il trattamento delle modifiche. Le tipologie di trattamento delle modifiche possibili sono 4:

• Tipo 1: si cambiano i valori degli attributi dell’entit`a della dimensione che ha subito modifiche. E’ la soluzione pi`u semplice e immediata, ma si alterano le analisi storiche;

• Tipo 2: si aggiunge una nuova riga alla tabella dimensionale, creando di fatto una entit`a nuova. Tutti i fatti precedenti alla modifica fanno riferimento alla vecchia entit`a, mentre tutti i fatti successivi alla modifica fanno riferimento a quella nuova. In questo modo il caricamento dei dati si complica e aumentano i dati della dimensione;

• Tipo 3: si prevede la possibilit`a di un cambiamento di attributo sos-tituendo l’attributo Attr con 3 attributi Attr, NuovoAttr, DataModifica; • Tipo 4: per le dimensioni che cambiano molto di frequente si possono

prevedere due tabelle dimensionali, una contenente gli attributi che ri-mangono immutati e una contenente gli attributi che variano.

Attualmente, la maggior parte delle dimensioni in analisi non richiede un particolare trattamento delle modifiche poich`e non variano nel tempo. Per quelle che cambiano molto raramente sar`a sufficiente variare il valore degli attributi. In futuro, con la specializzazione del modello verrano esaminate diverse strategie in base ai cambiamenti rilevati nel tempo.

Per ogni dimensione individuata vengono elencati gli attributi, descrivendo cosa essi rappresentano.

Richieste

Nome Descrizione

Cliente Cliente che inoltra la richiesta

Risorsa Risorsa proposta per la richiesta presentata

DataRichiesta Data in cui viene inoltrata la richiesta espressa nel formato GG/MM/YYYY

Esito Esito della

richiesta del cliente a seguito della presentazione della risorsa Rate Costo mensile della risorsa presentata

Clienti

Nome Descrizione

Cliente Indica il nome del cliente Table 2: Clienti dimension

Risorse

Nome Descrizione

Nome Indica il nome completo della risora

DataNascita Data nascita della risorsa espressa nel formato GG/MM/YYYY Universit`a Universit`a di provenienza della risorsa

Corso di laurea Corso di laurea della risorsa

RegioneProvenienza Regione di provenienza della risorsa

Genere Male of Female

Ruolo Indica il ruolo ricoperto dalla risorsa Table 3: Risorse dimension

Universit`a

Nome Descrizione

Facolt`a Indica il nome della facolt`a

Citt`a Nome citt`a di istanza dell’universit`a

Sigla Sigla che identifica univocamente l’universit`a Corso di laurea Corso di laurea afferente tale universit`a Classe Codice identificativo del corso

Colloqui

Nome Descrizione

Colloqui I Numero di colloqui step 1

Coll I OK Numero colloqui step 1 esito positivo Colloqui II Numero di colloqui step 2

Coll II OK Numero colloqui step 2 esito positivo Offerte Numero offerte presentate dall’azienda OfferteKO Numero offerte rifiutate

N inserimenti Numero inserimenti in organico Universit`a Nome universit`a provenienza risorsa

Table 5: Colloqui dimension

StatoRisorse

Nome Descrizione

Risorsa Nome risorsa

Et`a Et`a anagrafica risorsa

Anni permanenza Anni di permanenza della risorsa in azienda

Uscita Flag SI/NO

Data Data di uscita / registrazione permanenza NewSociet`a Nome cliente che assorbe la risorsa

Cliente Flag che indica se la nuova societ`a `e un cliente Lipari o meno Table 6: StatoRisorse dimension

Time

Nome Descrizione

Giorno Giorno espresso in GG Mese Mese espresso in MM Quarter Quarter espresso in Q Anno Anno espresso in YYYY

Table 7: Time dimension

Si descrivono ora le gerarchie esistenti tra gli attributi dimensionali.

Dimesnione Descrizione Gerarchia Tipo gerarchia Risorse Risorsa >Commerciale Ricorsiva Time Giorno>Mese >Quarter>Anno Bilanciata

Table 8: Hierarchy attributes

Nella tabella che segue si indicano tutte le misure, descrivendone la loro aggregabilit`a e, se sono derivate, la formula per derivarle e una breve descrizione.

Fatto Misura Descrizione Aggregabilit`a Derivata Processo di vendita Quantit`a richieste Rappresenta il numero di richieste OK o KO Additiva No Processo di vendita Costo di vendita Costo risorsa impiegata su un progetto Additiva No Processo di vendita Revenue Ricavi - Costi Additiva Si Gestione risorse Bont`a aziendale (BA) Indicatore sulla performance aziendale Additiva Si Gestione risorse Retention Indica la frazione di risorse che non vengono assorbite dai clienti Additiva Si Recruiting Quantit`a Indica la quantit`a di colloqui e assunzioni effetutati Additiva No Recruiting Conversioni N assunzioni / N colloqui Additiva Si

Table 9: Facts measures

Successivamente vengono rappresentati i requisiti in una forma tabellare che mette in evidenza quali misure e dimensioni sono in comune ai diversi processi.

Dimensione Processo di vendita Gesitone Risorse Recruiting Richieste x Clienti x x Risorse x x x Universit`a x Colloqui x StatoRisorse x Time x x x

Table 10: Dimension per fact

Misura Processo di vendita Gesitone Risorse Recruiting

Quantit`a x x Costo di vendita x Revenue x Conversioni x Bont`a aziendale x Retention x

Table 11: Measure per fact

2.2

Progettazione concettuale iniziale

Dopo aver descritto a fondo i requisiti di business emersi in questa prima fase di analisi, vengono mostrati gli schemi concettuali iniziali dei tre data mart candi-dati. Gli schemi sono una semplice riscrittura con il modello dimensionale dei fatti dei requisiti riportati nella modulistica presentata nella sezione precedente.

Figure 12: Schema concettuale iniziale data mart RECRUITING

Figure 14: Schema concettuale iniziale data mart SALES

2.3

Progettazione concettuale dei dati AS-IS

Come gi`a detto in precedenza, l’esigenza di un sistema di business intelligence nasce da un utilizzo massivo di fogli excel per la gestione dei dati aziendali. Ogni attivit`a difatti utilizza una serie di fogli elettronici che ad oggi risultano essere confusionari e non pi`u performanti in relazione alle nuove esigenze e al crescere della mole dei dati stessi.

La selezione dei dati in esame per l’implementazione del nuovo sistema `e stata fatta dunque a partire da numerosi excel forniti dai responsabili di ogni attivit`a. In conformit`a con il GDPR alcuni dei dati contenuti in questi file sono stati mascherati, alterati o addirittura omessi. Ci`o comunque non ha impedito un’esaustiva raccolta di informazioni utili per questa prima fase di progettazione. Ad ogni responsabile di attivit`a `e stato richiesto un archivio di questi file.

Ovvimente ognuno degli excel conteneva una struttura differente in quanto redatto da attori differenti. La raccolta e l’interpretazione di questi dati ha richiesto molto tempo vista la variabilit`a delli stessi.

Ogni file presenta una struttura tabulare simil-csv, con una serie di attributi customizzati, i quali verranno trattati e modificati per poter adattare i dati al modello di business descritto in precedenza. Tali fasi di estrazione e trasfor-mazione verranno trattate pi`u avanti.

Di seguito `e possibile apprezzare un estratto di tali file.

Figure 16: Esempio file excel PKM - statistiche

• HR Per quanto riguarda tale attivit`a, i file ricevuti contenevano dati relativi alle risorse interne e ai processi di selezione di queste. Gli excel sono due e fanno riferimento al periodo 2018/2019

– 2019 Elenco Risorse LC - GB.xlsx contenente l’elenco delle risorse presenti nell’organico aziendale fino ad oggi;

– 20171203 Visura Corsi di Laurea AFU Sistema Informativo.xlsx con-tenente tutte le informazioni sulle universit`a e sui corsi di laurea. All’interno del file si riscontra la presenza di alcune statistiche riguardanti la provenienza delle risorse. Ovviamente tali statistiche sono calco-late a mano o con formule excel.

Inoltre vi `e la presenza di uno sheet aggiuntivo contenente le metriche relative al processo di recruiting;

• PKM Gli excel relativi all’attivit`a di gestione del personale contengono informazioni riguardo il loro percorso in azienda e le loro attivit`a sui pro-getti nei quali sono stati inseriti.

A partire da questi file risulta interessante analizzare la retention delle risorse e le performance interne in relazione all’operato dei propri dipen-denti. Anche in questo caso gli excel sono due, ognuno dei quali contenente diversi sheet;

– 20190218 Retention review.xlsx contenente i dati necessari per l’analisi della retention delle risorse interne. I dati sono suddivisi per anno (2018-2019): per ogni periodo vengono riportate le statistiche per seniority, tipologia cliente e cliente.

– 20190227 DB KM v0.xlsx contenente le informazioni relative alle at-tivit`a delle risorse sui progetti. Anche qui i dati vegnono raggup-pati secondo diversi criteri: strumenti utilizzati, info clienti, industry, ruolo risorsa, ambito.

• SALES in questo caso le info sono contenute in un unico file excel for-nito, all’interno del quale sono stati redatti diversi sheet per le esigenze dell’attivit`a.

– Dati sales 2019.xlsx contenente i dati relativi alle opportunit`a e alle richieste ricevute dai clienti. Qui ritroviamo informazioni riguardanti gli incontri con i clienti, le risorse proposte (con relative skills), rate della risorsa, esito dell’incontro (nel caso positivo l’effettivo concretiz-zarsi dell’opportunit`a).

Di seguito un estratto degli excel relativi all’attivit`a SALES

Figure 18: Esempio file excel SALES - dati opportunit`a

Le informazioni contenute in tali excel non presentano alcun tipo di strut-tura che possa rispecchiare uno schema rapportabile ad una base di dati. Difatti sia i file che gli sheet al loro interno non sono parlanti da questo punto di vista. Per questo motivo, nella fase di trasformazione `e stato necessario collegare le informazioni attraverso l’introduzione di nuovi campi che mettessero in comu-nicazione le tabulazioni.

Nonostante ci`o si `e cercato di ricreare uno schema dei dati cos`ı da portare all’attenzione la necessit`a di un sistema che possa organizzare e sfruttare al meglio tutte queste informazioni.

Nel diagramma seguente dunque possiamo osservare una schematizzazione dei file excel presentati in precedenza. I contenuti dei vari file sono stati rapp-resentati tramite un diagramma siml-entit`a-relazione cos`ı da porre un punto di partenza per la migrazione di tali informazioni verso un sistema pi`u completo e complesso.

Figure 19: AS-IS data - 1

Per semplicit`a grafiche, alcune di queste tabelle sono state ridimensionate in termini di campi per poterne mostrare il contenuto.

All’interno di questi excel venivano riportate anche delle statistiche calcolate a mano dai responsabili di ogni area.

Esempi di queste sono:

• Numero di colloqui sostenuti durante l’intero iter per facolt`a;

• Classifica delle top 10 universit`a in base al numero di colloqui sostenuti durante l’intero iter di selezione;

• Numero di inserimenti;

• Distribuzione del numero di uscite dall’azienda per tipologia di societ`a destinazione;

• Distribuzione del numero di risorse che hanno lasciato l’azienda, per livello di seniority e clienti.

I dati AS-IS non sono in grado di contribuire a soddisfare le domande di business che sono trapelate a seguito dell’analisi dei requisiti del sistema. Per ci`o l’obiettivo `e quello di selezionare da queste sorgenti le informazioni rilevanti e di effettivo interesse, trasformarle e manipolarle per lo scopo prefissato.

2.4

Progettazione concettuale finale

A seguito di una prima progettazione dei data mart candidati e dell’analisi delle informazioni AS-IS vengono presentati gli schemi concettuali finali.

Figure 23: Schema concettuale finale data mart PKM

Figure 24: Schema concettuale finale data mart SALES

Tali differenze si concretizzano nei seguenti punti: • introduzione Time dimension;

• tutte le date sono state ricondotte alla dimensione precedentemente citata; • la data viene splittata nelle sue singole componenti

– G indica il giorno – M indica il mese

– Q indica il quarter (campo calcolato) – Y indica l’anno;

• il campo Facolt`a pu`o essere specializzato attraverso il campo CorsoLaurea.

2.5

Progettazione logica

Attualmente non `e ancora noto il sistema che gestir`a il data warehouse, ma nonostante ci`o possiamo ipotizzare uno snow-flake-schema per la strutturazione degli schemi concettuali finali. Questo poich`e ritroviamo alcuni collegamenti ref-erenziali tra dimensioni (Risorse con Universit`a)

Per ognuna delle tre tabelle dei fatti viene creata una tabella relazionale, con una chiave primaria surrogata e tutte le misure come attributi.

Successivamente viene creata una tabella relazionale per ogni dimensione pre-sente nello schema finale; le tabelle contengono una chiave primaria e tutti gli attributi presenti nella rispettiva dimensione. Le chiavi primarie introdotte saranno sempre surrogate in quanto per le dimensioni riscontrate non sono disponibili chiavi primarie sotto forma di codice.

Difatti tutte le chiavi primarie sono state ricavate attraverso l’utilizzo di interi incrementali (ID).

Figure 25: Schema logico del data mart Gestione Risorse

Figure 27: Schema logico del data mart Processo di Vendita

Dai diagrammi appena mostrati `e possibile osservare come le tabelle dei fatti condividano diverse tabelle dimensionali come: Risorsa, Cliente, Time. Solitamente fondere le dimensioni in comune in una sola tabella pu`o comportare la creazione di viste per rinominare o escludere alcuni attributi: in questo caso non si hanno problemi del genere e la fusione potrebbe essere fatta direttamente. Nella figura seguente si presenta lo schema logico complessivo del sistema con le dimensioni condivise dai data mart.

Figure 28: Schema logico del data mart Processo di Vendita

Oltre alle considerazioni precedentemente fatte `e possibile notare come ci sia un collegamento tra la dimensione Risorsa e Universit`a, questo perch`e `e impor-tante tenere traccia delle informazioni accademiche per ogni risorsa interna.

Tale relazioni non viene riportata per il data mart Recruiting, questo perch`e `

e possibile esprimerla attraverso la tabella del fatto. Questo approccio `e accetta-bile poich`e la tabella del fatto `e un’istantanea periodica in cui tutte le chiavi per tutte le dimensioni sono garantite per ogni periodo di reporting.

3

AMBIENTE DI SVILUPPO

Nel seguente capitolo verranno descritte tutte le tecnologie utilizzate per la real-izzazione di questo PoC. Alcune di queste sono gi`a state introdotte in precedenza poich`e `e stato gi`a affrontato e descritto l’utilizzo dei fogli excel da parte dei re-sponsabili di ogni attivit`a. Questo dunque rappresenta il punto di partenza delle analisi effettuate.

3.1

Dati AS-IS Excel

I dati manipolati durante la progettazione non erano stanziati in una vera e pro-pria base di dati operazionale ma in una serie di fogli elettronici gestiti dal tool Microsoft Excel della suite Office. L’utilizzo di questi file per la gestione delle informazioni `e stato adottato fin dai primi anni di operato aziendale, durante i quali la ridotta dimensione imprenditoriale, in termini di commesse e risorse, non suggeriva l’utilizzo di un sistema avanzato per la manipolazione dei dati d’interesse.

Inoltre l’utilizzo di excel era senza dubbio pi`u che familiare per i dipendenti e i responsabili delle singole aree. Per ci`o tale pratica `e risultata per diverso tempo rapida, performante ed affidabile.

La costante crescita aziendale, il vertiginoso aumentare delle richieste da parte dei clienti e conseguentemente l’innalzamento del numero di risorse interne ha fatto s`ı che tale strumento risultasse obsoleto e inadeguato. Questo non consente una corretta storicizzazione dei dati, elemento fondamentale per analisi sull’andamento aziendale ai fini di un raggiungimento del vantaggio competitivo nel proprio raggio d’azione, e limita fortemente la comunicazione tra le varie attivit`a.

Visto l’obiettivo di questo progetto, tutti i dati necessari per lo sviluppo di un prototipo persistono interamente in questi file. La restante parte delle

informazioni riguardo l’azienda, come ad esempio quelle relative alla pura am-ministrazione, sono presenti in RDBMS Microsoft SQL Server (12.0.5207.0), piattaforma sul quale verranno caricati i dati in scope per la successiva manipo-lazione.

3.2

Microsoft SQL Server

Microsoft SQL Server `e un DBMS relazionale (Relational Database Management System RDBMS), prodotto da Microsoft. Nelle prime versioni era utilizzato per basi dati medio-piccole, ma a partire dalla versione 2000 `e stato utilizzato anche per la gestione di basi dati di grandi dimensioni.

Rappresenta un un sistema di gestione di database relazionali, o RDBMS, che supporta un’ampia gamma di applicazioni di elaborazione delle transazioni, di business intelligence e di analisi negli ambienti IT aziendali. `E una delle tre tecnologie di database leader del mercato, insieme a Oracle Database e IBM DB2.

Come altri software RDBMS, Microsoft SQL Server `e basato su SQL, un lin-guaggio di programmazione standardizzato che gli amministratori di database (DBA) e altri professionisti IT utilizzano per gestire i database e interrog-are i dati che contengono. SQL Server `e legato a Transact-SQL (T-SQL), un’implementazione di SQL di Microsoft che aggiunge una serie di estensioni di programmazione proprietarie alla lingua standard.

A partire dal 1995 fino ad oggi, Microsoft ha rilasciato numerose e svariate versioni di SQL Server. Le prime versioni erano rivolte principalmente alle applicazioni dipartimentali e di gruppo di lavoro, ma Microsoft ha ampliato le capacit`a di SQL Server in quelle successive, trasformandolo in un DBMS relazionale di classe enterprise in grado di competere con Oracle Database, DB2 e altre piattaforme concorrenti per gli usi di database di fascia alta. Nel corso degli anni, Microsoft ha incorporato in SQL Server anche vari strumenti di

gestione dei dati e di analisi dei dati, oltre a funzionalit`a per supportare le nuove tecnologie emerse, tra cui il web, il cloud computing e i dispositivi mobili.

Con le ultime versioni della piattaforme sono sopraggiunte nuove funzionalit`a per l’ottimizzazione delle prestazioni, l’analisi operativa in tempo reale e la visualizzazione e reporting dei dati sui dispositivi mobili, oltre al supporto ibrido del cloud che consente ai DBA di eseguire database su una combinazione di sistemi locali e servizi cloud pubblici per ridurre i costi IT. Ad esempio, una tecnologia di Database Estensibile di SQL Server trasferisce i dati con accesso non frequente dai dispositivi di archiviazione locali al cloud di Microsoft Azure, mantenendo i dati disponibili per l’interrogazione, se necessario.

Come altre tecnologie RDBMS, SQL Server si basa principalmente su una struttura di tabella basata su righe che collega tra loro gli elementi di dati cor-relati in tabelle diverse, evitando la necessit`a di archiviare in modo ridondante i dati in pi`u posizioni all’interno di un database. Il modello relazionale fornisce diversi vincoli di integrit`a per mantenere l’accuratezza dei dati; tali controlli fanno parte di una pi`u ampia aderenza ai principi di atomicit`a, coerenza, iso-lamento e durata - collettivamente noti come propriet`a ACID e progettati per garantire che le transazioni del database siano elaborate in modo affidabile.

• atomicit`a: la transazione `e indivisibile nella sua esecuzione e la sua ese-cuzione deve essere o totale o nulla, non sono ammesse esecuzioni parziali; • consistenza: quando inizia una transazione il database si trova in uno stato coerente e quando la transazione termina il database deve essere in un altro stato coerente, ovvero non deve violare eventuali vincoli di integrit`a, quindi non devono verificarsi contraddizioni (inconsistenza dei dati ) tra i dati archiviati nel DB;

• isolamento: ogni transazione deve essere eseguita in modo isolato e in-dipendente dalle altre transazioni, l’eventuale fallimento di una transazione non deve interferire con le altre transazioni in esecuzione;

• durabilit`a: detta anche persistenza, si riferisce al fatto che una volta che una transazione abbia richiesto un commit work, i cambiamenti apportati non dovranno essere pi`u persi. Per evitare che nel lasso di tempo fra il momento in cui la base di dati si impegna a scrivere le modifiche e quello in cui li scrive effettivamente si verifichino perdite di dati dovuti a malfunzionamenti, vengono tenuti dei registri di log dove sono annotate tutte le operazioni sul DB.

Un processo di SW selection `e ancora in atto, tuttavia `e opinione comune procedere sfruttando tale prodotto nella sua STANDARD EDITION. Tale ver-sione offre le funzionalit`a di db complete per applicazioni mid-tier e data mart. Tra le tecnologie proposte troviamo:

• MOTORE DI DATABASE SQL SERVER Motore di database `e il servizio principale per l’archiviazione, l’elaborazione e la sicurezza dei dati. Motore di database assicura l’accesso controllato e l’elaborazione rapida delle transazioni per soddisfare i requisiti delle pi`u complesse applicazioni aziendali di gestione dei dati. Utilizzare Motore di database per creare database relazionali per i dati relativi all’elaborazione delle transazioni online o all’elaborazione analitica online, inclusa la creazione di tabelle per l’archiviazione di dati e oggetti di database, ad esempio indici, viste e stored procedure per la visualizzazione, la gestione e la protezione dei dati. `E possibile utilizzare SQL Server Management Studio per gestire gli oggetti di database e SQL Server Profiler per acquisire gli eventi del server.

• ANALYSIS SERVICE Analysis Services `e un motore dati analitici us-ato nell’analitica di business e supporto decisionale. Fornisce modelli di dati semantici per i report di business e applicazioni client quali Power BI, Excel, Reporting Services report e altri strumenti di visualizzazione dei dati.

Un tipico flusso di lavoro include la creazione di un modello di dati tabu-lari o multidimensionali in Visual Studio, sulla distribuzione del modello come database in un’istanza del server, configurare l’elaborazione dati ri-corrente e assegnazione di autorizzazioni per consentire l’accesso ai dati dagli utenti finali. Quando `e pronto per iniziare, il modello di dati seman-tico `e accessibile dalle applicazioni client che supportano Analysis Services come un’origine dati.

La disponibilit`a di pi`u approcci consente esperienze di modellazione com-misurate ai diversi requisiti di aziende e utenti. L’approccio multidimen-sionale `e una tecnologia avanzata basata su standard aperti, adottato da numerosi fornitori di software di Business Intelligence, ma pu`o essere dif-ficile da gestire. L’approccio tabulare offre una modellazione relazionale che molti sviluppatori trovano pi`u intuitiva. PowerPivot `e ancora pi`u sem-plice, poich´e offre una modellazione dei dati visiva in Excel, con supporto server tramite SharePoint.

• MODELLO MULTIDIMENSIONALE Una soluzione multidimen-sionale Analysis Services utilizza strutture cubo per l’analisi dei dati azien-dali in pi`u dimensioni. La modalit`a multidimensionale `e la modalit`a server predefinita di Analysis Services, in cui sono inclusi una query e un motore di calcolo per i dati OLAP, con modalit`a di archiviazione MOLAP, RO-LAP e HORO-LAP per bilanciare prestazioni con requisiti di dati scalabili. Il motore OLAP di Analysis Services `e un server OLAP leader del settore che funziona bene con gli strumenti di una vasta gamma di BI. La maggior parte delle distribuzioni di Analysis Services viene installata come server OLAP classico.

La compilazione di un modello multidimensionale di Analysis Services avviene principalmente per ottenere prestazioni veloci a seguito di query sui dati aziendali. Un modello multidimensionale `e costituito da cubi e di-mensioni che possono essere annotati ed estesi per supportare costruzioni

di query complesse. Gli sviluppatori di soluzioni di Business Intelligence creano cubi per supportare tempi di risposta rapidi e fornire una sola orig-ine dati per la creazione di report aziendali. Data l’importanza crescente della Business Intelligence a tutti i livelli di un’organizzazione, la disponi-bilit`a di una singola origine di dati analitici assicura che le discrepanze siano limitate al minimo, se non eliminate completamente.

Un altro importante vantaggio all’utilizzo di database multidimensionali di Analysis Services `e l’integrazione con gli strumenti di generazione di report di BI di uso comune quali Excel, Reporting Services e PerformancePoint, nonch´e di applicazioni personalizzate e soluzioni di terze parti.

• SQL SERVER REPORTING SERVICES Creare, distribuire e ge-stire report impaginati e per dispositivi mobili di Reporting Services in locale, con la gamma di strumenti e servizi pronti all’uso offerti da SQL Server Reporting Services (SSRS). SQL Server Reporting Services `e una soluzione che i clienti distribuiscono al loro interno per la creazione, la pubblicazione e la gestione di report, in modo da inviarli agli utenti giusti in diversi modi, tramite visualizzazione su Web browser, su un disposi-tivo mobile o come messaggio di posta elettronica nella casella di posta in arrivo. SQL Server Reporting Services offre una famiglia di prodotti aggiornata:

– Report impaginati ”tradizionali” aggiornati, in modo da poter creare report dall’aspetto moderno, con strumenti aggiornati e nuove fun-zionalit`a per crearli. Questo tipo di impaginazione `e molto utile per la generazione di documenti con layout fisso ad alta definizione ot-timizzati per la stampa, ad esempio file PDF e file di Word.

– Nuovi report per dispositivi mobili con un layout reattivo, in grado di adattarsi a diversi dispositivi e a diverse modalit`a di orientamento. – Un portale Web moderno visualizzabile in qualsiasi browser moderno. Nel nuovo portale `e possibile organizzare e visualizzare report

impag-inati e per dispositivi mobili e indicatori KPI di Reporting Services. `

E anche possibile archiviare cartelle di lavoro di Excel nel portale. • REPLICA SQL SERVER La replica `e costituita da un set di

tecnolo-gie per la copia e la distribuzione di dati e oggetti di database da un database a un altro e la successiva sincronizzazione dei database in modo che risultino consistenti. Usare la replica per distribuire dati a diverse posizioni e a utenti remoti o mobili tramite reti locali e WAN, connessioni remote, connessioni wireless e Internet. La replica transazionale viene in genere utilizzata negli scenari server-server con esigenze di elevata ve-locit`a effettiva, inclusi il miglioramento delle caratteristiche di scalabilit`a e disponibilit`a, funzionalit`a di data warehouse e di creazione di report, in-tegrazione di dati da pi`u siti, integrazione di dati eterogenei e ripartizione del carico di lavoro dell’elaborazione batch.

Le features appena descritte sono state estratte dai seguenti riferimenti: [7], [8], [9]

Il modello progettato `e stato implementato in un’istanza locale di SQL Server. Qui sono stati caricati tutti i dati selezionati e filtrati attraverso un processo di ETL customizzato. La scelta di utilizzare un database locale deriva da una questione legata alle tempistiche di realizzazione dell’infrastruttura e di selezione dei software di appoggio(db vendor, gestionali etc.). Per questo motivo il modello si traduce in un PoC in grado di dimostrare la raggiungibilit`a degli obiettivi prefissati.

3.2.1 Microsoft Power BI

Power BI `e un servizio di analisi business che offre informazioni dettagliate per favorire decisioni rapide e informative. E’ un supporto valido per la trasfor-mazione di dati in oggetti visivi, accattivanti e condivisibili con i colleghi tramite qualsiasi dispositivo. Permette di esplorare e analizzare visivamente i dati, in locale e sul cloud, in un’unica visualizzazione. utile per collaborazione e

condi-visione di dashboard personalizzate e report interattivi. [10]

Il prodotto `e stato testato sui dati selezionati e le relative dashboard sono state mostrate ai futuri utilizzatori del sistema. Il giudizio di questi ultimi relativo ai grafici proposti non `e stato positivo, ponendo perci`o maggiore attenzione su altri strumenti di reportistica.

3.3

Qlikview

QlikView `e una piattaforma di Business Discovery che fornisce funzioni di Busi-ness Intellingence (BI) self-service a tutti gli utenti aziendali delle organizzazioni. Con QlikView `e possibile analizzare i dati e utilizzare le proprie rilevazioni dati per supportare il processo decisionale. QlikView consente di porre domande, trovare le risposte e seguire percorsi che consentono di ottenere informazioni strategiche. Consente inoltre agli utenti aziendali di prendere decisioni in modo collaborativo.

Il cuore di QlikView `e un motore software brevettato, che genera nuove viste di dati sul momento. Comprime i dati e li mantiene in memoria, dove sono disponibili per l’esplorazione immediata da parte di pi`u utenti.Per tenere in memoria serie di dati molto grandi, QlikView esegue direttamente la connes-sione alla sorgente dati. QlikView offre un’esperienza associativa su tutti i dati utilizzati per l’analisi, indipendentemente da dove sono memorizzati. Gli utenti possono iniziare e arrivare in qualsiasi punto, in quanto non sono vincolati a utilizzare solo percorsi di analisi e dashboard predefiniti.

Quando si analizzano i dati con QlikView, `e possibile ottenere facilmente una panoramica generale degli stessi, scoprirne le relazioni e fare scoperte, an-che quando si gestiscono serie di dati ampie e complesse. `E possibile integrare le informazioni provenienti da sorgenti differenti e le informazioni possono es-sere rese rapidamente disponibili in rete, con la certezza che verranno inviate alla persona giusta. La tecnologia del modello di dati associativo su cui si

basa QlikView consente di creare un’interfaccia unica per la presentazione in-terattiva e l’analisi di qualsiasi tipo di informazioni. Il recupero dei dati nei sistemi tradizionali `e spesso un processo complesso che richiede una conoscenza approfondita della struttura dei database e della sintassi del linguaggio delle query. L’utente `e di sovente limitato a routine di ricerca predefinite. QlikView oltrepassa questi limiti rendendo possibile la selezione libera a partire dai dati visualizzati sullo schermo con un semplice clic del mouse.

Il prodotto presenta molte aree di applicazione. L’utente `e il solo a decidere il modo in cui utilizzare il programma. Risulta utile per l’acquisizione di una visione generale unificata e coerente dei dati in database differenti, di propriet`a dell’utente o di altre persone, centrali o locali. QlikView pu`o essere utilizzato praticamente con qualsiasi database.

Con QlikView `e possibile:

• Creare un’interfaccia dell’utente finale flessibile per un information ware-house.

• Ottenere snapshot delle relazioni tra i dati. • Realizzare presentazioni basate sui dati. • Creare grafici e tabelle dinamici. • Eseguire analisi statistiche.

• Collegare descrizioni e applicazioni multimediali ai propri dati. • Creare sistemi esperti personalizzati.

• Creare nuove tabelle, che uniscono informazioni da molte sorgenti. • Creare sistemi di Business Intelligence personalizzati.

La scelta di utilizzo di tale strumento per la produzione di questo PoC `e stata suggerita sia dalle preferenze degli owner delle aree aziendali che dall’esperienza maturata nel suo utilizzo nell’ambito di altri stream progettuali. [3] [4]

3.4

Anaconda - Jupyter

Per poter eseguire l’estrazione e le trasformazioni sui dati `e stato impiegato un puro linguaggio di programmazione: Python. La scrittura e l’esecuzione delle procedure scritte con questo linguaggio sono stati realizzati attraverso Ana-conda, una distribuzione open-source dei linguaggi di programmazione Python ed R per il calcolo scientifico e per la Data Science.

All’interno di Anaconda `e possibile sfruttare Jupyter Notebook, un’applicazione Web open source che consente di creare e condividere documenti che contengono codice in tempo reale, equazioni, visualizzazioni e testo narrativo. Gli usi in-cludono: pulizia e trasformazione dei dati, simulazione numerica, modellazione statistica, visualizzazione dei dati, apprendimento automatico e molto altro. [5] [6]

L’utilizzo di tale ambiente di sviluppo deriva dall’esperienza personale maturata durante il percorso accademico e professionale.

4

PROCESSO ETL - ESTRAZIONE,

TRASFOR-MAZIONE E CARICAMENTO

Si descrive il processo di estrazione, trasformazione e caricamento dei dati e se ne presentano alcune delle problematiche pi`u rilevanti.

Di seguito `e possibile osservare una descrizione visuale del processo in esame.

Figure 29: Data Flow

4.1

Il processo ETL

Il processo di ETL (Extract-Transform-Load) `e il fondamento su cui si pog-giano i sistemi di data warehouse: consiste nell’estrazione, la trasformazione, il consolidamento e l’inserzione di dati da sorgenti eterogenee a una base di dati di destinazione (tipicamente un data warehouse). Un sistema ETL ben diseg-nato estrae i dati da sorgenti separate, controlla e si assicura che i dati siano conformi a degli standard di qualit`a e di consistenza stabiliti al momento della progettazione del data warehouse, rende omogenei i dati delle diverse sorgenti e infine li inserisce nella base di dati di destinazione [1]. E’ bene notare che il funzionamento effettivo di un data warehouse `e influenzato in modo decisivo dalle procedure di ETL.

La costruzione del sistema di ETL `e un’attivit`a poco visibile agli utilizza-tori finali del data warehouse e che viene quindi spesso sottovalutata in fase di pianificazione e di allocazione delle risorse. Dal momento che in un data warehouse quello che conta sono i dati, non si pu`o non considerare l’importanza delle procedure di ETL, specialmente se si considera quanto valore aggiungano ai dati, poich´e,rimuovono errori e correggono dati mancanti, forniscono una certa misura di confidenza nei dati, consolidano dati provenienti da sorgenti differenti affinch`e la loro unione possa essere utilizzata in maniera corretta, strutturano i dati affinch´e siano usabili dagli strumenti di analisi interattiva.

Per concludere, capire l’obiettivo delle procedure di ETL `e sicuramente sem-plice e intuitivo, cos`ı come `e alla portata di tutti apprezzare delle metodologie che siano capaci di pulire e trasformare i dati per facilitarne la fruizione; tut-tavia questa semplicit`a viene meno nel momento in cui ci si trova ad affrontare nel dettaglio tutte le particolarit`a e le anomalie che possono derivare da:sorgenti dei dati mal concepite, software a disposizione non adeguato, applicazioni che devono fare uso del data warehouse con vincoli particolari o comunque poco comuni. [12]

Nel concepimento di questo progetto, la realizzazione di queste procedure ha richiesto non poco tempo e sforzo. Queste difficolt`a sono dovute a diversi fattori:

• nessun utilizzo di strumento alcuno presente sul mercato; • alta sparsit`a e alto livello di entropia nei dati;

• presenza di anomalie nei dati; • vincoli di integrit`a mancanti;

• formati dei dati differenti tra i diversi fogli excel;

• interpretazioni delle informazioni differenti in base all’autore del file; • assenza di dati;

• documentazione o linee guida mancanti; • trattamento dati sensibili.

4.2

Software ETL

Come detto in precedenza, non `e stato sfruttato alcun software di terze parti per poter eseguire le procedure di estrazione e trasformazione. Tali processi sono stati realizzati attraverso l’utilizzo di un linguaggio di programmazione puro: Python.

Le motivazioni che hanno spinto a questa scelta sono diverse:

• flessibilit`a illimitata nel trattare i dati;

• utilizzo di librerie esterne per la manipolazione autonoma di file excel e csv;

• controllo diretto delle trasformazioni effettuate e della consistenza dei dati; • rapidit`a nell’effettuare le analisi vista la quantit`a limitata di dati a

dispo-sizione.

L’utilizzo di tale strumento `e risultato performante in questa fase pilota, fornendo la possibilit`a di manipolare i dati AS-IS con rapidit`a al fine di produrre un PoC che risultasse soddisfacente per i futuri utilizzatori del sistema.

L’impiego di un linguaggio di programmazione verr`a accantonato nelle fasi successive in cui la mole di dati da trattare sar`a maggiormente impattante e verranno messi a disposizione strumenti ad hoc presenti sul mercato.

Per quanto concerne la fase di caricamento `e stato sfruttato SQL Server Management Studio. Si `e scelto di sfruttare tale strumento poich`e mette a disposizione la possibilit`a di caricare direttamente i dati attraverso dei flat file (csv).

4.3

Estrazione dei dati

Con l’utilizzo di Python e le sue librerie `e stato possibile customizzare in modo agevole questa fase.

I file excel sono stati convertiti in file csv cos`ı da poterne facilitare la lettura e la successiva manipolazione. In questa fase `e stata effettuata una prima selezione dei campi da portare avanti per il processo di etl, eliminando quelle colonne il cui potere informativo non riusltava impattante in relazione al contesto di sviluppo.

Tale intervento `e risultato decisivo e al tempo stesso critico poich`e i dati scelti sarebbero stati i candidati per poter rispondere alle domande di business ricavate dal processo di analisi dei requisiti. Dunque vi `e stata posta molta attenzione nella scelta delle informazioni da portare avanti, analizzando con cura ogni singola colonna presente nei file ricevuti.

L’ambito in cui questa selezione ha avuto maggiore riscontro `e stato per l’attivit`a Sales. Nei file afferenti venivano riportati dati relativi ad aspetti non interessanti per le analisi attuali, come:

• Dettagli sugli incontri con in clienti – Data singoli incontri;

– Attori presenti agli incontri; – Luogo dell’incontro.

• Informazioni aggiuntive riguardo i clienti (attualmente il livello di granu-larit`a scelto per il cliente non prevede un tale livello di dettaglio)

– Macro area cliente;

– Nome e cognome del referente; – Ruolo del referente.