Business intelligence per il controllo di gestione di un intermediario finanziario

(1)

UNIVERSIT `A DI PISA Dipartimento di Informatica

Corso di Laurea Magistrale in Data Science and Business Informatics

TESI DI LAUREA

Business Intelligence per il controllo di gestione di un intermediario finanziario

Relatore

Prof. Salvatore Ruggieri

Candidato Angela Tanga

(2)

INDICE

1 INTRODUZIONE ₁

1.1 Presentazione del problema . . . 1

1.2 Rassegna della letteratura . . . 4

1.3 Contenuto della tesi . . . 5

2 IL CASO DI STUDIO ₇ 2.1 La societ`a committente: Alba Leasing . . . 7

2.2 La societ`a esecutrice: Sadas . . . 8

2.3 Ambito di riferimento . . . 10

2.3.1 Il leasing . . . 10

2.3.2 Il controllo di gestione . . . 14

2.3.3 Il bilancio d’esercizio in Alba Leasing . . . 17

2.3.4 La relazione sulla gestione e gli indicatori aziendali 18 2.4 Indicatori di interesse per il progetto di tesi . . . 21

3 GLI STRUMENTI UTILIZZATI ₂₃ 3.1 Il DBMS Sadas Engine . . . 23

3.1.1 L’organizzazione fisica dei dati . . . 24

3.1.2 Sadas Engine . . . 26

3.2 La suite SadasBI . . . 28

3.3 Qlik Sense . . . 31

3.3.1 Creazione del modello dati e applicazioni QVF . . 33

3.3.2 Qlik IndeXing Engine (QIX Engine) . . . 34

4 DATA MART PER L’ANALISI DEI PIANI DI AM-MORTAMENTO ₃₈ 4.1 Progettazione del data mart . . . 39

4.1.1 Analisi dei requisiti . . . 40

4.1.2 Progettazione concettuale iniziale del data mart . 52 4.1.3 Progettazione concettuale candidata e finale del data mart . . . 52

(3)

4.1.4 Progettazione logica del data mart . . . 55

5 POPOLAMENTO DEL DATA MART ₅₆ 5.1 Il processo di ETL . . . 58

5.2 ETL in Qlik Sense . . . 63

6 I DUE STRUMENTI DI BI A CONFRONTO ₇₅ 6.1 L’accesso ai dati . . . 76

6.2 Il tempo di caricamento dei dati . . . 76

6.3 L’utilizzo delle componenti hardware . . . 78

6.4 Il sistema di selezione dei dati . . . 80

6.5 Conclusioni . . . 84

7 I RISULTATI FINALI ₈₅ 7.1 La reportistica in SadasBI e Qlik Sense . . . 86

7.2 Considerazioni . . . 95

(4)

Sommario

Si presenta la progettazione e la realizzazione di un’applicazione di Business Intelligence per il controllo di gestione di un intermediario fi-nanziario, operante nell’ambito del leasing, con l’obiettivo di analizzare l’andamento dei piani di ammortamento dei contratti stipulati con i pro-pri clienti.

Vengono descritte tutte le fasi della progettazione del data mart di sup-porto all’applicazione: dalla raccolta dei requisiti fino alla progettazione concettuale e logica. Viene presentata la procedura di ETL, finalizzata al popolamento del data mart, la quale consiste nell’estrazione dei dati dalla sorgente operazionale, nel caricamento delle informazioni in area di staging per la trasformazione e nel trasferimento definitivo dei dati nel data mart.

La reportistica dell’applicazione `e stata realizzata utilizzando due distin-te distin-tecnologie di Business Indistin-telligence: la suidistin-te SadasBI e la piattaforma Qlik Sense.

La tesi include un’analisi comparativa dei due strumenti che evidenzia le loro peculiarit`a, pregi e difetti, rilevati durante lo sviluppo del progetto.

(5)

Capitolo 1

INTRODUZIONE

1.1 Presentazione del problema

Il controllo di gestione `e un sistema volto a guidare la gestione dell’at-tivit`a aziendale mediante il compimento di azioni strategiche, definite in fase di pianificazione, utili per il raggiungimento degli obiettivi prefissa-ti.

Per monitorare la situazione economica e finanziaria della gestione e constatare un miglioramento rispetto al passato oppure l’effettivo conse-guimento degli obiettivi vengono valutati degli indicatori finanziari, in-formazioni sintetiche che permettono di verificare aspetti distintivi della gestione aziendale. Tali indicatori possono contenere valori consuntivi o preventivi. Lo studio rivolto ad un solo indicatore, in realtà, non è suf-ficiente per svolgere una corretta analisi. Conclusioni migliori, invece, si ottengono paragonando molteplici indicatori: ad esempio, confrontando quelli costituiti da valori consuntivi, generalmente relativi al periodo ap-pena terminato, con indicatori contenenti o dati consuntivi, ma connessi, ad esempio, ad uno o più esercizi precedenti, oppure valori preventivi,

(6)

1 – INTRODUZIONE

definiti in fase di pianificazione strategica. Il management acquisisce cos`ı un’indicazione in merito all’andamento dell’azienda ed attua procedure diverse che dipendono dall’esito della comparazione appena descritta. In particolare, se si evidenzia una differenza negativa, avvia un’indagine che verifichi le cause e le possibili azioni correttive da eseguire per risanare l’attivit`a; in caso contrario, identifica gli elementi e i processi che hanno contribuito ai risultati raggiunti.

Il lavoro di tesi si colloca esattamente in questo contesto. Nello spe-cifico, la società committente, rappresentata da un’azienda operante nel settore del leasing, ha individuato un determinato indicatore finanziario connesso alla rimuneratività dell’azienda. L’obiettivo è non solo di met-tere a confronto i valori a consuntivo dell’esercizio appena concluso con quelli dell’anno precedente, ma studiare accuratamente i componenti di cui esso è costituito. Questi ultimi sono elementi principali dei piani di ammortamento dei contratti di leasing stipulati dalla società committen-te con i propri clienti. Da ciò nasce l’esigenza di esaminare l’andamento di tali piani di ammortamento.

La societ`a committente ha richiesto, inoltre, lo sviluppo della reportistica inerente alla problematica esposta per scrutare ed esaminare al meglio i dati, scegliendo uno tra i principali strumenti di Business Intelligence (d’ora in avanti, BI ) predominanti sul mercato: Qlik Sense.

Il presente elaborato include, oltre a ci`o, l’impiego di un’altra tecnologia, la suite SadasBI, proprietaria della societ`a esecutrice, con l’obiettivo di sviluppare la medesima applicazione implementata in Qlik Sense.

(7)

1 – INTRODUZIONE

Lo scopo è di presentare un confronto fra le due soluzioni, studiare le loro proprietà, ponendo in risalto i punti di forza e di debolezza, evi-denziando in quali situazioni è più conveniente adottare una tecnologia piuttosto che l’altra.

Il risultato della comparazione ha varie finalità: per la società esecu-trice, espone i vantaggi e gli svantaggi nell’utilizzo della suite SadasBI rispetto a strumenti di mercato come Qlik Sense; per la società com-mittente, consente di valutare se la piattaforma scelta è effettivamente adeguata alle proprie necessità e di apprendere una conoscenza meto-dologica di entrambe le tecnologie che potrebbe rivelarsi utile per la realizzazione di eventuali progetti futuri.

(8)

1 – INTRODUZIONE

1.2 Rassegna della letteratura

Per la stesura del presente lavoro di tesi sono state consultate nume-rose fonti.

Per le informazioni riguardanti i soggetti coinvolti, si `e fatto rife-rimento ai siti web ufficiali dell’azienda committente [AlbaLeasing] e dell’azienda esecutrice [Sadas].

Per la descrizione dettagliata del leasing `e stato consultato il sito di Assilea [Assilea], mentre per la parte economica si `e fatto riferimento a due fonti principali: [Marasca-13] per la descrizione dell’ambito di riferimento, il controllo di gestione, e [Allegrini-16] per il dettaglio dei componenti del bilancio.

Riguardo alla progettazione del data mart, dalla raccolta dei requisiti al disegno finale, `e stato consultato [Albano-17], materiale utilizzato an-che durante il corso di studi. Per la formalizzazione del processo di ETL, che ha lo scopo di alimentare il data mart progettato, `e stato considerato quanto descritto in [Golfarelli-06].

Per la definizione del sistema SADAS si `e fatto riferimento a [Albano-08]. In particolare, la documentazione presente in [SadasBI-17] ha permesso di delineare il sistema di BI, la suite SadasBI.

Invece, per quanto concerne Qlik Sense sono presenti diversi riferi-menti, in base all’argomento affrontato: [Overview] per una panoramica generale della tecnologia; [Architecture-17] per l’architettura del soft-ware; [DataSource-18] per la connessione alla sorgente dati;

(9)

1 – INTRODUZIONE

[DynamicCalculation-13], [LogicalInference-13] e [SymbolTable-12] per la descrizione del motore QIX; [DataManager-18] per presentare un me-todo offerto da Qlik Sense per la gestione dei dati; [PrecedingLoad-18], [ComandScript-18] e [SyntaxScript-18] per la sintassi adottata negli script di Qlik Sense e [LoadScript-18] per eseguire il caricamento dei dati at-traverso gli script implementati; [FileQVD-18] per la descrizione del fi-le QVD; [SyntheticKey-13] per definire il ruolo delfi-le chiavi sintetiche ed, infine, [SetAnalysis-18] per la descrizione della funzionalit`a di Set Analysis.

1.3 Contenuto della tesi

Il presente lavoro di tesi `e il prodotto del progetto formativo svolto presso Sadas S.r.l. di Milano.

La relazione sintetizza l’attivit`a di analisi e progettazione di un data mart finalizzato al controllo di gestione di un intermediario finanziario e, nello specifico, all’analisi dell’andamento dei piani di ammortamento dei contratti stipulati.

Il progetto propone lo sviluppo di un’applicazione di BI mediante il sup-porto di due tecnologie: la suite SadasBI e la piattaforma Qlik Sense.

Il Capitolo 1 introduce gli argomenti trattati ed offre una breve de-scrizione delle fonti da cui si `e attinto.

(10)

1 – INTRODUZIONE

committente e la societ`a esecutrice e si descrivono i concetti chiave ine-renti all’elaborato quali il controllo di gestione, che definisce il settore aziendale, il leasing, ossia l’attivit`a principale dell’azienda committente, ed uno sguardo generale al bilancio d’esercizio e agli indicatori aziendali inclusi.

Il Capitolo 3 illustra gli strumenti di BI adottati per lo sviluppo dell’ap-plicazione in oggetto.

Il Capitolo 4 mostra la soluzione proposta per la realizzazione del data mart di supporto, dalla raccolta dei requisiti fino alla progettazione lo-gica.

Il Capitolo 5 descrive il processo di ETL per lo sviluppo e il popolamento del data mart ed il procedimento per la creazione del data model in Qlik Sense.

Il Capitolo 6 presenta uno studio comparativo delle caratteristiche delle due tecnologie utilizzate.

Il Capitolo 7 espone la reportistica in SadasBI e in Qlik Sense che sod-disfa i requisiti richiesti.

(11)

Capitolo 2

IL CASO DI STUDIO

In questo capitolo vengono brevemente presentati i soggetti coinvolti: l’azienda committente, Alba Leasing Spa, e l’azienda esecutrice, Sadas Srl. In seguito, viene definito il concetto di leasing e si delinea l’am-bito di riferimento del progetto, il controllo di gestione, spiegando il motivo per cui la nostra attenzione si `e rivolta principalmente all’analisi dell’andamento dei piani di ammortamento dei contratti di leasing.

2.1 La societ`

a committente: Alba Leasing

Alba Leasing `e un’azienda finanziaria specializzata nel leasing fonda-ta nel 2010 su iniziativa di alcune tra le pi`u importanti Banche Popolari italiane. Attualmente ha sede a Milano ma opera in tutta Italia, distri-buendo i propri prodotti attraverso una rete formata da 5.700 sportelli delle Banche socie (Banco BPM, BPER Banca, Banca Popolare di Son-drio e Credito Valtellinese) e di altre importanti Banche convenzionate. Inoltre, la rete distributiva include un gruppo di affidabili vendor in continuo sviluppo.

(12)

2 – IL CASO DI STUDIO

L’azienda propone contratti di leasing finanziario. In particolare offre Leasing Strumentale per l’acquisto di beni, impianti e macchinari per le imprese di ogni settore e dimensione; Leasing Immobiliare per il fi-nanziamento integrale di immobili per attivit`a di impresa commerciale, industriale, di servizi e di ogni altro settore produttivo; Leasing Targato riservato a imprese e professionisti per l’acquisto di ogni genere di veicolo (Leasing Auto, Leasing Veicoli Commerciali, Leasing Veicoli Industriali); Leasing Aeronavale finalizzato all’acquisizione di imbarcazioni e aeromo-bili da parte di aziende e professionisti.

La Figura 2.1 mostra il logo ufficiale dell’azienda.

Figura 2.1: Logo ufficiale di Alba Leasing

Per approfondimenti si rimanda alla pagina web ufficiale [AlbaLeasing].

2.2 La societ`

a esecutrice: Sadas

SADAS `e un’azienda informatica nata nel 2013 come spinoff del grup-po Advanced Systems che da oltre 30 anni sviluppa e distribuisce solu-zioni software per il mondo bancario, per la Pubblica Amministrazione e per il settore della riscossione. `E presente sul mercato nazionale, con sedi a Milano, Roma e Napoli, e internazionale, a Parigi. Ha inoltre delle rappresentanze commerciali in Inghilterra, a Bath, e negli Stati Uniti, a San Francisco.

(13)

L’azienda si dedica principalmente allo sviluppo di soluzioni per la BI, applicazioni per l’analisi dei dati e strumenti di DWH basati su una tecnologia all’avanguardia. Le soluzioni spaziano dall’antiriciclaggio al marketing, dai servizi tradizionali a quelli pi`u innovativi del cloud per il mondo finance, per il mercato dei media fino a quello retail.

Sadas è da sempre in rapida e continua espansione: il suo personale è in costante aumento e, ad oggi, è una delle aziende riconosciute come leader della crescita 2019 presenti nella classifica stilata da Statista per Il Sole 24 Ore.

La Figura 2.2 mostra il logo ufficiale dell’azienda.

Figura 2.2: Logo ufficiale di Sadas

(14)

2.3 Ambito di riferimento

Prima di esporre i dettagli del progetto di tesi `e opportuno spiegare cosa si intende per leasing e definire il ramo aziendale di interesse, il controllo di gestione, con riferimento alla fonte [Marasca-13].

2.3.1 Il leasing

Il leasing è un contratto in cui una parte (da qui, concedente) concede ad un’altra (da qui, utilizzatore) - per un periodo di tempo prefissato e ad un corrispettivo periodico - il godimento di un bene (anche detto cespite). Alla scadenza del contratto, l’utilizzatore può, in base al tipo di leasing scelto e ai propri bisogni, restituire il bene al concedente, estendere la durata del contratto oppure acquistarne la proprietà contro il versamento di un prezzo prestabilito (il riscatto).

Il leasing `e una forma di finanziamento destinata ad ogni tipo di clientela, dagli artigiani ai professionisti, dalle piccole e medie aziende fino alle grandi imprese e alla pubblica amministrazione.

Spesso viene scelto in quanto offre diversi vantaggi:

– `e un servizio flessibile che si adatta alle diverse esigenze del cliente (molteplici combinazioni sono possibili tra la durata del contratto, la periodicit`a e l’importo dei canoni, il valore di riscatto del bene, ecc.);

(15)

– consente al termine del contratto, se previsto, di acquisire la pro-priet`a del bene.

Come tutti i servizi, presenta anche degli svantaggi:

– il pagamento di un canone iniziale di importo anche elevato (il cosiddetto acconto) e l’eventuale rata finale per il riscatto;

– fino all’avvenuto riscatto, il bene non pu`o essere venduto o affittato dall’utilizzatore a terzi (salvo specifici accordi);

– contrariamente ai beni di propriet`a, non pu`o essere iscritta ipoteca sui beni in leasing.

Assilea, l’Associazione Italiana Leasing che rappresenta le Societ`a di leasing presso le organizzazioni del settore che operano nelle varie sedi istituzionali, nazionali ed internazionali, definisce nella documentazione [Assilea] le tre forme principali di leasing esistenti sul mercato:

• il leasing finanziario: prevede che il concedente, rappresentato da una banca o da un intermediario finanziario, ha l’obbligo di acqui-stare o far costruire il bene secondo le indicazioni dell’utilizzatore, che si assume tutti i rischi legati al bene, compreso il perimento. Per poter effettivamente godere del cespite, l’utilizzatore deve ver-sare l’acconto (di solito superiore all’importo del canone periodico) e dei canoni periodici generalmente di importo costante che tengono conto del prezzo di acquisto o di costruzione e della durata del con-tratto. L’elemento essenziale, e che distingue il leasing finanziario

(16)

dagli altri, `e la previsione dell’opzione finale di acquisto del bene a favore dell’utilizzatore ad un prezzo prestabilito. Pertanto, alla scadenza del contratto, l’utilizzatore ha il diritto di divenire proprie-tario del bene esercitando l’opzione di riscatto; in caso contrario ha l’obbligo di restituire il bene al concedente.

La Figura 2.3 schematizza il procedimento di un contratto di leasing finanziario.

Figura 2.3: Contratto di leasing finanziario

• il leasing operativo: a differenza del leasing finanziario, non prevede un’opzione di riscatto e non è necessariamente un’operazione trila-terale ovvero la parte concedente può coincidere con il produttore del bene. Inoltre, i rischi legati al cespite, come quello di obso-lescenza, sono a carico del concedente. Al termine del contratto l’utilizzatore può scegliere se restituire il bene o estendere la du-rata del contratto. L’assenza dell’opzione finale di acquisto rende tale schema contrattuale particolarmente adatto ai beni per i quali

(17)

l’interesse all’impiego da parte dell’utilizzatore coincide con la sola durata contrattuale;

• il sale & lease-back: è un contratto in base al quale l’impresa o il professionista vende alla società di leasing il bene e la società di leasing concede (retroloca) lo stesso bene in leasing al vendi-tore. Quest’ultimo quindi si trasforma da proprietario del bene ad utilizzatore, ottenendo disponibilità liquide senza accedere alle tradizionali forme di finanziamento.

Negli ultimi anni il leasing sta vivendo il suo periodo pi`u roseo dovu-to ad una progressiva espansione sul mercadovu-to. Le banche propongono e promuovono sempre di pi`u questo strumento ai propri clienti che, gra-zie ad una serie di vantaggi e agevolazioni, risulta essere una soluzione frequentemente scelta.

(18)

2.3.2 Il controllo di gestione

Il controllo di gestione `e un sistema di strumenti, processi, ruoli e solu-zioni informali che inducono a comportamenti individuali e organizzativi in linea con il raggiungimento degli obiettivi aziendali.

Il controllo di gestione insieme alla pianificazione aziendale genera un sistema efficace ed efficiente che può essere di vitale importanza per l’a-zienda, per consentire e facilitare la sopravvivenza e lo sviluppo della stessa. Sia il controllo che la pianificazione rappresentano il fulcro delle attività di supporto aziendale, con lo scopo di affrontare eventi casua-li interni o esterni all’organizzazione. Nello specifico, la pianificazione strategica consiste nel definire gli obiettivi a breve e lungo termine della gestione aziendale e le linee guida da seguire per raggiungerli mentre il controllo serve all’azienda per accertarsi che ciò che è stato definito in sede di pianificazione venga rispettato. Gli esiti ottenuti dall’attività aziendale vengono confrontati con i fini prestabiliti e, in caso di scosta-menti, si avviano delle azioni correttive.

Riassumendo, il controllo di gestione si suddivide essenzialmente in tre fasi:

• Monitoraggio e verifica dei vincoli da rispettare e delle risorse da utilizzare in seguito al processo di pianificazione strategica;

• Misurazione e controllo dei risultati;

• Analisi degli scostamenti tra i valori raggiunti e gli scopi predefiniti, delineandone le cause ed attuando eventuali azioni correttive.

(19)

Il controllo di gestione si concretizza in base alle esigenze e alle attività svolte dall’azienda, supervisionando lo svolgimento dell’operato indivi-duale dei dipendenti e dirigenti, risorse fondamentali ed indispensabili. Dal punto di vista organizzativo, il controllo di gestione viene attuato dai cosiddetti centri di responsabilità, unità organizzative definite, al fine di responsabilizzare le persone coinvolte. Queste ultime devono essere in grado di raggiungere gli incarichi a loro assegnati, in linea con gli scopi aziendali.

La misurazione dei risultati `e la fase chiave del controllo ed `e realiz-zabile tramite uno dei due metodi principali:

– feed-back : procedimento ampiamente diffuso che si basa sulla mi-surazione dei risultati al termine di determinati intervalli tempo-rali. Questo tipo di controllo ha il vantaggio di offrire una visione completa della gestione (i risultati realmente conseguiti) in rap-porto agli obiettivi, ma ha lo svantaggio di fornire tali indicazioni solo alla fine del periodo, con la conseguente difficolt`a di attivare tempestivamente azioni correttive;

– feed-forward : si attua potenziando il sistema informativo per la mi-surazione dei risultati intermedi sulla base di idonei modelli di tipo probabilistico-predittivo. In questo modo `e possibile evidenziare gli scostamenti prima della loro effettiva realizzazione, consentendo il ripristino del sistema prima che le disfunzioni si realizzino.

(20)

la capacità di gestire le relazioni su cui si basa il modello predittivo, per agevolare una corretta interpretazione delle previsioni e degli scostamenti segnalati. In secondo luogo, deve essere garantita l’at-tendibilità dei dati che alimentano il modello predittivo e valutata l’utilità dello stesso in termini di supporto decisionale.

Infine, l’analisi degli scostamenti costituisce una delle fasi pi`u criti-che all’interno del processo di controllo, criti-che prevede un confronto tra gli esiti raggiunti a consuntivo con specifici termini di paragone, come ad esempio i valori programmati. Al contempo, la tecnica degli scostamenti rappresenta un importante “strumento” del controllo di gestione, volto a scomporre i differenziali tra il consuntivo e il preventivo oppure il con-suntivo del periodo precedente, con la finalit`a di identificare le molteplici cause di ciascuna variazione.

Nella maggior parte delle organizzazioni aziendali la rilevazione degli scostamenti si manifesta unicamente in fase di redazione del bilancio d’esercizio.

(21)

2.3.3 Il bilancio d’esercizio in Alba Leasing

Alba Leasing è una società per azioni (S.p.A.), un tipo di società di capitali dotata di personalità giuridica in cui le partecipazioni dei soci sono rappresentate dalle azioni. Inerente al tipo di società, Alba Leasing redige il bilancio annuale di esercizio che deve essere portato a conoscen-za dei terzi attraverso la sua pubblicazione, resa obbligatoria dalla legge. Come previsto dall’art.2423 del Codice Civile, ”Il bilancio deve essere redatto con chiarezza e deve rappresentare in modo veritiero e corretto la situazione patrimoniale e finanziaria della società e il risultato econo-mico dell’esercizio”. In altre parole, il bilancio ha non solo la funzione di evidenziare in maniera reale e trasparente il reddito dell’esercizio ma rappresenta anche uno strumento sia di controllo a consuntivo e a preven-tivo della gestione aziendale che informapreven-tivo sulle condizioni di equilibrio economico e finanziario. È diretto principalmente agli stakeholder, sog-getti interni ed esterni interessati all’andamento dell’attività.

In riferimento a [Allegrini-16], il bilancio `e formato da diverse compo-nenti, obbligatorie o facoltative a seconda del tipo di societ`a:

• lo stato patrimoniale: schema a sezioni contrapposte con attivit`a e passivit`a;

• il conto economico: prospetto scalare che esplicita la classificazione di proventi ed oneri;

• la nota integrativa: descrizione dei criteri di valutazione adottati e delle informazioni utili alla comprensione del bilancio (impegni,

(22)

garanzie, compensi degli amministratori);

• il rendiconto finanziario: prospetto che riassume i flussi di cassa in un certo periodo;

• la relazione della societ`a di revisione: esito di un’analisi approfon-dita del bilancio di esercizio da parte di una societ`a di revisione contabile esterna;

• la relazione del collegio sindacale: espone la coerenza dell’opera-to degli amministradell’opera-tori rispetdell’opera-to ai fini stabiliti dall’assemblea e con riguardo allo statuto della societ`a; inoltre esprime giudizio sul-la corrispondenza del bisul-lancio alle scritture contabili e alle norme vigenti;

• la relazione sulla gestione: contiene un’analisi fedele, equilibrata ed esauriente della situazione della societ`a e dell’andamento del risul-tato della gestione, nel suo complesso e nei vari settori in cui essa ha operato.

Nello specifico, il bilancio di Alba Leasing contiene tutti gli elementi appena descritti. Il nostro studio si `e focalizzato sulla relazione sulla gestione, redatto dai responsabili del controllo di gestione.

2.3.4 La relazione sulla gestione e gli indicatori aziendali La relazione sulla gestione costituisce uno dei principali documenti allegati al bilancio d’esercizio. Il suo scopo `e fornire una visione globale

(23)

che consenta al lettore di comprendere, in aggiunta ai principali rischi e incertezze a cui la società è esposta, la sua posizione nell’ambiente in cui opera e l’andamento della gestione. Il tutto è definito in chiave attuale e prospettica, dando la possibilità di svolgere l’analisi degli scostamen-ti che, solitamente, include la verifica e la comparazione di indicatori aziendali. Questi ultimi esplicitano sinteticamente e chiaramente i punti di forza e debolezza dell’organizzazione.

In particolare, gli indicatori sono informazioni:

• critiche: in quanto su di esse il management opera le proprie scelte; • sintetiche: perch´e espresse da una variabile quantitativa o

qualita-tiva, semplice o composta;

• significative: in quanto ben rappresentano i fenomeni aziendali ai quali si riferiscono;

• prioritarie: per la loro natura irrinunciabile nei cicli di pianifica-zione e controllo a tutti i livelli aziendali (strategico, direzionale, operativo);

Grazie ad essi, il management pu`o valutare le performance dell’atti-vit`a aziendale e pianificare le azioni da intraprendere per ottimizzare gli esiti riscontrati.

(24)

Esistono essenzialmente due tipi di indicatori:

– finanziari : evidenziano informazioni connesse alla gestione finan-ziaria e patrimoniale e all’aspetto economico, soprattutto in riferi-mento alla redditivit`a;

– non finanziari : valutati nell’ottica di fornire informazioni utili ai fini della comprensione della situazione e della performance azien-dale. Esempi rilevanti sono gli indicatori relativi al posizionamen-to sul mercaposizionamen-to, alla soddisfazione della clientela e alla propensione all’innovazione.

(25)

2.4 Indicatori di interesse per il progetto di tesi

Nel caso specifico, Alba Leasing sfrutta diversi indicatori di gestio-ne riguardanti fondamentalmente la gestiogestio-ne economica, l’efficienza, la produttivit`a e i rischi dell’organizzazione aziendale.

Tra questi, si è deciso di focalizzare l’attenzione su uno degli indicatori finanziari che rispecchia la rimuneratività della società. Tale indicatore è ottenuto dal rapporto tra gli interessi attivi, che rappresentano i profitti percepiti, e il capitale medio, ossia la quota media investita per offrire servizi di leasing ai propri clienti.

L’azienda quindi ha necessit`a di monitorare non solo l’indicatore in og-getto ma anche gli elementi di cui esso `e costituito. Gli interessi e il capitale investito sono estratti dai piani di ammortamento dei contratti di leasing registrati.

Un piano di ammortamento `e un prospetto che mostra la restituzio-ne rateale di un debito, dalla stipula del contratto fino alla scadenza. Il debito, per Alba Leasing, corrisponde all’investimento sostenuto per l’acquisto o la costruzione del bene ceduto in leasing e viene restituito dall’utilizzatore in maniera rateale (a quote costanti), abbinato al paga-mento di interessi.

Difatti, Alba Leasing adotta l’ammortamento “alla francese” o “a rate costanti”, il quale prevede rate tendenzialmente omogenee e invariabili (salvo le possibili fluttuazioni del tasso di interesse), ognuna delle quali `e formata da una quota interessi, che ha un andamento decrescente nel

(26)

tempo ed `e calcolata sul debito residuo non ancora restituito, e da una quota capitale, con trend crescente. Man mano che le rate vengono ri-scosse, il debito residuo diminuisce in misura pari alla quota capitale e la restante parte (gli interessi) rappresenta il ricavo effettivo per l’azienda. Da qui la scelta di analizzare l’andamento dei piani di ammortamento dei contratti remunerativi.

(27)

Capitolo 3

GLI STRUMENTI UTILIZZATI

In questo capitolo vengono descritte la composizione e le funzionalit`a delle tecnologie adottate per lo sviluppo dell’applicazione di BI. In det-taglio, viene presentata la struttura del DBMS di Sadas (Sadas Engine), con particolare riguardo alla suite SadasBI, e la piattaforma Qlik Sense.

3.1 Il DBMS Sadas Engine

SADAS Engine `e un DBMS colonnare specializzato nell’interrogazio-ne di archivi statici di grandi dimensioni. Consente l’analisi e la na-vigazione in real-time di basi di dati di grandi volumi ed `e impiegato principalmente per applicazioni di Data Warehousing.

L’architettura `e rappresentata in figura 3.1.

Le elevate performance del sistema SADAS Engine sono legate all’in-troduzione di elementi innovativi nella progettazione ed implementazione del DBMS:

• una nuova architettura dei dati basata sull’organizzazione per co-lonna (column-based);

(28)

3 – GLI STRUMENTI UTILIZZATI

• un uso spinto della ridondanza delle forme di rappresentazione dei dati (indici e strutture di supporto);

Figura 3.1: Architettura generale - SADAS

Si precisa che la documentazione per la stesura del paragrafo 3.1 e dei sotto paragrafi 3.1.1 e 3.1.2 `e estratta da [Albano-08], mentre per il paragrafo 3.2 si fa riferimento a [SadasBI-17].

Di seguito si descrive l’organizzazione fisica dei dati in Sadas, la struttura e le caratteristiche di Sadas Engine e la suite SadasBI.

3.1.1 L’organizzazione fisica dei dati

Il modello logico più diffuso per i DBMS in commercio è il model-lo relazionale, nel quale è usuale visualizzare una relazione (tabella bi-dimensionale) con le colonne identificate dagli attributi e con le righe

(29)

contenenti i valori delle ennuple. La memorizzazione fisica dei dati sto-ricamente è avvenuta memorizzando i dati come un insieme di pagine contenenti uno o più righe, a loro volta contenenti i valori dei singoli attributi. In questo modo, ogni volta che si deve accedere ad un solo attributo, è necessario leggere tutta la riga, quindi tutti gli attributi, per estrarre i valori.

Questo approccio funziona bene per l’esecuzione di transazioni del tipo OLTP, in quanto necessitano in genere di accessi rapidi all’insieme degli attributi del singolo record.

Nelle elaborazioni di tipo OLAP, che in generale coinvolgono dati stati-ci (con aggiornamenti effettuati periodicamente) e molti valori di pochi attributi, l’organizzazione orizzontale non `e pi`u adatta in quanto richie-derebbe una lettura completa di tutte le pagine fisiche, utilizzandone solo una piccola frazione di informazioni.

Nel caso di elaborazioni analitiche è più efficiente utilizzare il partizio-namento verticale (column based), principio portante di tutto il sistema SADAS. Secondo tale criterio, le tabelle caricate vengono partizionate verticalmente, creando un file (CLN) per ogni attributo e poi, per ognu-no di questi singoli file (o per opportune combinazioni di essi), si crea una serie di strutture accessorie. L’i-esimo valore del file della colonna del singolo attributo corrisponde al valore dello stesso attributo nell’i-esima riga nell’organizzazione orizzontale. In questa fase sui file colonna viene fatta un’ottimizzazione al fine di ridurre ancora la loro dimensio-ne. Per ciascun file colonna, la lunghezza in byte dei singoli valori è resa

(30)

costante ed è pari alla lunghezza massima necessaria a rappresentare nella forma scelta tutti valori del dominio di quell’attributo (lunghezza di stato). Grazie alla staticità dei dati e quindi alla lunghezza costante delle colonne, l’accesso ad un determinato valore può essere effettuato moltiplicando il RID (Record Identifier), ossia il progressivo del record, per la lunghezza di stato.

Successivamente si eseguono varie operazioni sui file CLN che hanno lo scopo di creare un indice (e i corrispondenti file che lo compongono) per ogni attributo di ogni tabella al fine di ottimizzare le operazioni di selezione [Albano-08].

3.1.2 Sadas Engine

L’architettura generale del motore Sadas `e rappresentato in figura 3.2. Sadas Engine si divide in due entit`a logiche: Macchina Logica e Macchina Fisica.

(31)

In corrispondenza di un comando SQL, la macchina logica provve-de a trasformare l’interrogazione (script SQL) in un piano di accesso. Quest’ultimo rappresenta la strategia di esecuzione dell’interrogazione a costo minimo; esso `e costituito da un albero di operatori fisici, ognuno dei quali `e un algoritmo che realizza un operatore dell’algebra relazionale o un metodo di accesso disponibile nella macchina fisica. In Sadas Engine esiste un’implementazione proprietaria di tutti i moduli della macchina logica, mostrati in Figura 3.2.

La macchina fisica provvede a trasformare il piano di accesso in una sequenza di metodi di accesso (operatori che la macchina fisica offre al-l’esecutore dei piani d’accesso) per eseguire i comandi e accedendo quindi ai dati nel database. In Sadas Engine non esiste un’implementazione pro-prietaria di tutti i moduli della macchina fisica, ma molte funzionalit`a sono delegate al Sistema Operativo [Albano-08].

(32)

3.2 La suite SadasBI

La suite SadasBI permette di progettare e visualizzare cruscotti di-rezionali e reportistica in maniera semplice e interattiva. Lo scopo `e di supportare i processi decisionali e, in generale, tutte le operazioni gior-naliere di un’attivit`a di business, facilitando il disegno di report completi ed efficaci.

La suite SadasBI `e composta da due sezioni: SadasBI Manager e Sa-dasBI.

SadasBI Manager `e il modulo adottato per la progettazione e modifica delle dashboard, visualizzazioni interattive create per mostrare ed esplo-rare dati. Alle dashboard `e possibile aggiungere semplici componenti grafici (liste e chart) per poter meglio interpretare i dati, effettuare ma-nipolazioni per personalizzare le informazioni (filtri), organizzare i dati su pagine multiple per fornire un flusso logico di navigazione, e cos`ı via. Offre, inoltre, la gestione personalizzata dei template, layout customiz-zabili e l’integrazione dei dati provenienti da fonti eterogenee.

SadasBI rappresenta, invece, il modulo diretto alla visualizzazione e navigazione delle dashboard sviluppate in SadasBI Manager.

All’interno della suite SadasBI, ogni dashboard viene identificata da un progetto. Quest’ultimo pu`o essere visualizzato tramite SadasBI o essere rilasciato come applicazione web stand-alone. Ogni progetto de-finisce e contiene tutti gli elementi che utilizza, come le connessioni al DB da cui si estraggono i dati mediante semplici query SQL, le pagine

(33)

da visualizzare e i relativi componenti.

Durante il flusso di navigazione tra le pagine che compongono una dashboard, vengono continuamente raccolti dati, tra cui filtri impostati e record selezionati su liste e grafici. Queste informazioni non vanno perse, ma vengono ereditate, rendendo dinamici componenti e pagine che formano i progetti, tenendo traccia durante il flusso di navigazione delle chiavi di ricerca impostate e dei record selezionati. I dati ereditati possono essere utilizzati per effettuare diversi tipi di operazioni, dalle più semplici, come la visualizzazione, alle più complesse, come il con-dizionamento delle query utilizzando una specifica sintassi. In SadasBI Manager la tracciabilità dei dati ereditati è affidata ai parametri. Il pas-saggio di parametri avviene da pagina a pagina o all’interno della stessa pagina, stabilendo una gerarchia padre-figlio tra i vari componenti (ad esempio filtri, liste e chart) che la costituiscono.

La Figura 3.3 mostra un esempio di passaggio di parametri tra diversi componenti e pagine differenti.

(34)

Figura 3.3: Passaggio di parametri in SadasBI Manager

Sulla HomePage, il componente Filter definisce il parametro A. Il componente List collegato al filtro eredita il parametro A e definisce il parametro B. Infine il componente Chart eredita entrambi A e B, definendo il nuovo parametro C. Tutti i componenti di Pagina1 collegata al Chart ereditano tutti e tre i parametri.

(35)

3.3 Qlik Sense

Qlik Sense è una piattaforma che offre agli utenti la possibilità di creare visualizzazioni dei dati, report e dashboard personalizzati e inte-rattivi da più sorgenti dati, come definito sul sito ufficiale [Overview]. `

E caratterizzato da un’intuitiva tecnologia drag-and-drop, da una gam-ma di oggetti visivi (presenti di default e ampliabile con le estensioni) e dal motore d’indicizzazione Qlik IndeXing Engine (QIX Engine) che consente di esplorare grandi quantit`a di dati e le relazioni che esistono tra essi.

Qlik Sense `e progettato per supportare la visualizzazione self-service in modo scalabile e sicuro.

L’architettura, raffigurata e descritta in [Architecture-17], `e rappresen-tata in figura 3.4

(36)

In particolare `e costituita, lato server, da:

• Qlik Sense Proxy (QPS): rappresenta il ponte tra l’interfaccia utente e il motore QIX. Ha il compito di gestire le sessioni, le licenze e il load balancing tra i componenti;

• Qlik Sense Engine (QIX): il motore di indicizzazione associa-tivo dei dati. Questo livello offre visualizzazioni, ricerche e calcoli altamente interattivi in runtime;

• Qlik Sense Scheduler (QSS): il componente di scheduling che coordina i carichi di dati;

• Qlik Sense Repository (QRS): il repository contenente informa-zioni sulla configurazione e gestione della piattaforma (ad esempio, la sicurezza del servizio);

• Applicazioni Qlik Sense (.QVF): comprendono i dati e i modelli finali su cui si basano le visualizzazioni. Queste applicazioni sono memorizzate in modo persistente sul file system e vengono caricate in memoria dal motore QIX su richiesta dell’utente.

Di seguito si descrivono i processi (lato client) di connessione e cari-camento dei dati per la creazione del modello finale e delle applicazioni QVF e i meccanismi su cui si basa il motore QIX.

(37)

3.3.1 Creazione del modello dati e applicazioni QVF

All’avvio di Qlik Sense viene visualizzato l’hub, componente che mo-stra all’utente tutte le app sviluppate. L’app è l’elemento principale della piattaforma e rappresenta un vero e proprio contenitore di dati. Per creare una nuova app, il primo passaggio è accedere ai dati. Facen-do riferimento alla Facen-documentazione ufficiale [DataSource-18], Qlik Sense offre varie soluzioni tra cui il caricamento di un file locale (o di rete) op-pure il collegamento ad un sistema di gestione di database (DBMS) con ODBC (installando un driver ODBC per il DBMS in questione e creando un’origine dati DSN) o ad una sorgente dati ODBC con connettori di database ODBC, già predisposti (come Microsoft SQL Server, MySQL Enterprise, Oracle, PostgreSQL e Teradata) o da installare. Negli ultimi due casi, la connessione dati viene salvata nella piattaforma per consen-tire di selezionare le sorgenti utilizzate di frequente.

Dopo aver definito la sorgente, si passa al caricamento dei dati. Qlik Sen-se fornisce due metodi, descritti in [DataManager-18] e [LoadScript-18]: aggiungere dati con l’ausilio del data manager oppure utilizzare l’editor di caricamento dati. Nella prima soluzione, l’utente può selezionare, modificare e filtrare manualmente le tabelle e i relativi campi e, succes-sivamente, creare le relazioni tra le varie entità; nella seconda soluzione, invece, l’utente ha la possibilità di sviluppare uno script, con una spe-cifica sintassi, che consente non solo di modificare la struttura dei dati utilizzando espressioni e istruzioni dello script, ma anche di generare

(38)

automaticamente le relazioni tra le tabelle. Durante il caricamento dei dati, infatti, Qlik Sense identifica i campi comuni (con lo stesso nome) provenienti da tabelle diverse, generando cos`ı una relazione tra di loro. In entrambi i casi, se il processo ha esito positivo, i dati vengono memo-rizzati nell’app e salvati in un file QVF in modo da rendere il sistema persistente. Il risultato finale, su cui si baser`a la reportistica, `e uno schema a stella (star schema) detto modello dati.

3.3.2 Qlik IndeXing Engine (QIX Engine)

La necessità di rispondere a numerose business question e analizzare un’elevata quantità di dati richiede uno strumento capace di superare la semplice presentazione visiva delle informazioni. E indispensabile,` quindi, un componente in grado di rivelare le associazioni nascoste e di esplorare, tramite selezioni interattive, grandi insiemi di dati, offrendo visualizzazioni e operazioni runtime. Questi sono i motivi per cui è fonda-mentale un potente motore di indicizzazione associativo che rappresenta il cuore della logica in Qlik Sense: QIX Engine.

Come illustrato in [SymbolTable-12], considerando una o pi`u tabelle in input, per ottimizzare le prestazioni il motore QIX genera due tipi di tabelle:

• tabella dei simboli: viene creata per ogni attributo della tabella in input, eseguendo un vero e proprio partizionamento verticale del-la tabeldel-la origine. La tabeldel-la dei simboli di un singolo attributo

(39)

mostra, associato ad ogni valore distinto, un numero binario che lo rappresenta, chiamato indice;

• tabella dati: contiene gli stessi attributi della tabella origine ma, in sostituzione al valore di ogni attributo, espone il rispettivo indice (estratto dalla tabella dei simboli).

Gli indici sono cifre binarie composti da un numero di bit opportuno per rappresentare i valori distinti dell’attributo. Se si hanno 4 valori diffe-renti baster`a un indice a 2 bit. Ci`o implica che ad un elevato numero di valori distinti ne segue una maggiore lunghezza degli indici e righe aggiuntive nella tabella dei simboli, provocando un ulteriore uso della RAM e della CPU.

Gli indici binari e le tabelle dei simboli, se impiegati adeguatamente, danno l’opportunit`a al motore QIX di comprimere i dati ed elaborarli rapidamente.

Quando un utente interagisce con un’applicazione, egli osserva ed esamina, mediante filtri e selezioni, diversi sottoinsiemi di dati su cui `e possibile eseguire anche calcoli complessi.

(40)

Il motore QIX garantisce il buon esito di queste operazioni tramite un processo composto da due fasi (Figura 3.5):

Figura 3.5: Processo QIX Engine - Qlik Sense

• Logical Inference: come descritto in [LogicalInference-13], `e un pro-cesso che consente di ottenere un subset di dati definito da una o pi`u selezioni apportate dall’utente. I filtri, come mostra la Figura 3.6, vengono applicati e propagati in tutte le tabelle del modello dati, mantenendo soltanto i valori che soddisfano i vincoli espressi nella selezione.

Quando l’inferenza logica `e terminata si passa alla fase successiva;

(41)

• Dynamic Calculation: compie i calcoli e le aggregazioni richieste. Come descritto in [DynamicCalculation-13], in Qlik Sense i calcoli sono svolti a runtime o, se una procedura è già stata elaborata, viene riproposta grazie all’utilizzo di una cache interna al motore QIX. Questa fase richiede in genere molto tempo: spesso oltre il 90% del tempo di risposta è dovuto ai calcoli. Come mostrato in figura, i calcoli sono asincroni e multi-thread su più livelli: ogni oggetto viene calcolato con un singolo thread o, in caso di funzioni di aggregazione, si avvale di un numero maggiore di thread in modo da ottimizzare la computazione. Al termine del processo gli oggetti vengono mostrati aggiornati e, dato che il calcolo non è sincrono, alcuni di loro potrebbero manifestarsi prima rispetto ad altri.

(42)

Capitolo 4

DATA MART PER L’ANALISI

DEI PIANI DI

AMMORTAMENTO

In questo capitolo vengono presentati la progettazione e lo sviluppo del prototipo finalizzato all’analisi dell’andamento dei piani di ammorta-mento dei contratti di leasing. In particolare, si evidenziano le propriet`a e la finalit`a di un piano di ammortamento, gli aspetti implementativi del prototipo, dalla progettazione alla realizzazione della base dati di supporto alla reportistica finale.

(43)

4 – DATA MART PER L’ANALISI DEI PIANI DI AMMORTAMENTO

4.1 Progettazione del data mart

Per la progettazione del data mart `e stato adottato il metodo appreso durante il corso di studi e spiegato in [Albano-17], il quale consiste in diverse fasi:

• Analisi dei requisiti: procedimento composto da due sottofasi prin-cipali di cui la prima produce una specifica dei requisiti in linguaggio naturale mentre la seconda genera una descrizione dei requisiti in un formato che facilita la progettazione concettuale;

• Progettazione concettuale iniziale del data mart: la prima proget-tazione concettuale del data mart `e definita analizzando i requisiti degli utenti esposti nella fase precedente. Si adotta il DFM (Di-mensional Fact Model) per rappresentare fatti, dimensioni, attributi delle dimensioni e eventuali gerarchie dimensionali;

• Progettazione concettuale candidata del data mart guidata dai dati operazionali : prevede la progettazione del data mart considerando i dati operazionali disponibili. Si definiscono le tabelle e gli attri-buti di interesse ai fini dell’analisi. Tale processo `e essenziale per assicurare che i fatti da modellare abbiano un riscontro nei dati operazionali;

• Progettazione concettuale finale del data mart: partendo dal con-fronto tra il data mart iniziale e il data mart candidato e, general-mente, unendo le parti in comune dei due, si ottiene il data mart

(44)

finale, ossia la progettazione di ciò che è disponibile, dal punto di vista dei dati, ed è utile in base alle richieste degli utenti;

• Progettazione logica del data mart: supponendo che il modello mul-tidimensionale sia implementato con un sistema ROLAP (Relatio-nal On-Line A(Relatio-nalytical Processing), ogni data mart fi(Relatio-nale viene tra-dotto in uno schema relazionale, decidendo se creare uno schema a stella o uno snowflake (nel caso specifico `e stata adottata la prima tipologia). Da qui, integrando i vari schemi di data mart in uno unico, si ottiene il modello logico del data warehouse.

Nei capitoli successivi si dettagliano le fasi appena descritte, parten-do dall’analisi informale e formale dei requisiti fino alla progettazione concettuale finale e logica del data mart sviluppato per le finalit`a del progetto.

4.1.1 Analisi dei requisiti

I responsabili del controllo di gestione devono essere in grado di con-trollare lo sviluppo dei contratti a reddito mediante l’evoluzione tempo-rale dei rispettivi piani di ammortamento. Una caratteristica rilevante di questi ultimi è la storicità: bisogna osservare non solo i dati consun-tivi, ossia connessi ad un determinato mese e anno di riferimento, ma anche come questi mutano nel tempo, i cosiddetti dati preventivi, cioè riferiti ad un determinato mese e anno proiettivo, successivo al periodo di riferimento.

(45)

Il piano di ammortamento `e un prospetto che mostra la restituzione rateale di un debito. Generalmente, esso viene elaborato in fase di pro-posta di un contratto di leasing tra il concedente, di cui ci interessano il codice identificativo e il nome, e l’utilizzatore del bene.

Per ogni contratto interessano il numero identificativo (codice) com-posto dal numero di rapporto e dal modulo (inizializzato a 1) che rap-presenta eventuali integrazioni al contratto originale, il tipo di modulo e la data di stipula.

Ogni contratto ha per oggetto un prodotto, di cui interessano il codice identificativo, il nome e la categoria di appartenenza.

Per ogni piano di ammortamento ci interessano:

• la rata: quota risultante dalla somma della quota capitale e della quota interesse;

• la quota capitale: importo che costituisce parte del capitale resti-tuito all’azienda cedente;

• la quota interesse: quota calcolata sul debito residuo a seconda del tasso di interesse applicato e rappresenta il profitto per l’azienda cedente;

• la durata residua (mensile): numero di mesi necessari per estinguere il debito;

• il debito residuo: l’importo totale che l’utilizzatore deve sostenere per usufruire del bene.

(46)

Inoltre, bisogna considerare i valori strettamente inerenti alle quote in-teresse. Tra questi il tasso effettivo annuo, cio`e il tasso di interesse concretamente sostenuto dall’utilizzatore, ed il tasso nominale annuo, ossia il tasso di interesse previsto dal contratto di leasing.

Infine, volendo calcolare la quota degli interessi al netto di spese, `e do-veroso individuare gli oneri dell’azienda cedente quali i costi di commis-sioni, cio`e il corrispettivo ceduto alle banche che coprono il rischio di credito (detto anche rischio di insolvenza) dell’utilizzatore, e i costi di provvigioni, ossia il compenso che spetta all’intermediario a fronte della prestazione effettuata.

I requisiti appena presentati vengono poi formalizzati e schematizzati in Tabella 4.1, mostrando, per ognuno di essi, le dimensioni, le misure e le metriche coinvolte.

(47)

N Requisiti di analisi Dimensioni Misure Metriche

1

L’importo totale della rata, della quota capitale e della quota

interessi e la media del tasso effettivo e nominale, per contratto in un determinato mese e anno di riferimento ed un mese e anno proiettivo Contratto (Codice) Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Rata Quota capitale Quota interessi Tasso effettivo Tasso nominale SUM (Rata) SUM (Quota capitale) SUM (Quota interessi) AVG (Tasso effettivo) AVG (Tasso nominale) 2

La media del debito residuo (in ordine decrescente) per contratto in un determinato mese e anno di riferimento Contratto (Codice) Data (Anno/mese di riferimento) Debito residuo AVG (Debito Residuo)

(48)

3

Il totale del debito residuo e

della durata residua (espressa

in mesi e anni) e la media del tasso effettivo e nominale per prodotto e macro-prodotto, in un determinato mese e anno di riferimento ed un mese e anno proiettivo Prodotto (macro-prodotto, nome prodotto) Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Debito residuo Durata residua (mensile) Tasso effettivo Tasso nominale SUM (Debito Residuo) SUM (Durata residua (mensile)) SUM (Durata residua (mensile)) /12 AVG (Tasso effettivo) AVG (Tasso nominale) 4 Numero di contratti e totale debito residuo per concedente e prodotto Contratto (Codice) Concedente (Nome) Prodotto (nome prodotto) Debito Residuo COUNT (DISTINCT Contratto) SUM (Debito Residuo)

(49)

5 Indicatore della redditività lorda annuale del 2017 e del 2018= Totale quota interessi/ capitale medio Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Quota interessi Capitale medio SUM (Quota interessi) /SUM (Capitale medio) 6 Indicatore della redditività netta annuale del 2017 e del 2018= Totale quota interessi - (oneri interessi) /capitale medio Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Quota interessi Provvigioni Commissioni Capitale medio SUM (Quota interessi- Provvigioni-Commissioni) /SUM (Capitale medio) 7 Indicatore della redditività lorda mensile del 2017 e del 2018= Totale quota interessi /debito residuo Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Quota interessi Debito residuo SUM (Quota interessi) /SUM (Debito residuo)

(50)

8 Indicatore della redditivit`a netta mensile del 2017 e del 2018= Totale quota interessi - (oneri interessi) /debito residuo Data (Anno/mese di riferimento) Data (Anno/mese proiettivo) Quota interessi Provvigioni Commissioni Debito residuo SUM (Quota interessi- Provvigioni-Commissioni) /SUM (Debito residuo)

Tabella 4.1: Requisiti di analisi

Prima di procedere alla progettazione concettuale, è importante chia-rire la granularità del fatto, ossia il livello di dettaglio dei dati su cui svolgere l’analisi. In generale è opportuno privilegiare un’alta granularità per elaborare analisi più dettagliate.

(51)

Descrizione Dimensioni Preliminari Misure Preliminari Il fatto rappresenta lo stato di un piano di ammortamento di un contratto di leasing, in un mese e anno di riferimento e proiettivo. Prodotto, Contratto, Data (mese/anno di riferimento, mese/anno proiettivo), Concedente Rata, Quota capitale, Quota interesse, Debito residuo, Durata residua, Provvigioni, Commissioni, Tasso effettivo, Tasso nominale

Di seguito si descrivono le dimensioni specificando il nome, la descri-zione e la granularit`a.

Nome Descrizione Granularit`a

Contratto Il contratto di leasing stipulato tra concedente e utilizzatore

Un contratto

Data Mese e anno di riferimento temporale o proiettivo del contratto

Un mese

Prodotto Il bene, l’oggetto del contratto di leasing Un prodotto

Concedente L’intermediario finanziario che cede il bene in leasing

(52)

Per ogni dimensione, si mostra una breve descrizione degli attributi. CONTRATTO

Attributo Descrizione

Codice contratto Numero identificativo del contratto Tipo modulo Il tipo di integrazione al contratto originale Data stipula Data in cui il contratto `e stato stipulato

DATA Attributo Descrizione Mese Un mese Anno Un anno PRODOTTO Attributo Descrizione

Codice prodotto Numero identificativo del prodotto

Nome prodotto Nome del prodotto

Nome macro-prodotto Nome della categoria di appartenenza del prodotto

(53)

CONCEDENTE

Attributo Descrizione

Nome concedente Rappresenta il tipo di societ`a

concedente (associate, convenzionate, vendor) Codice concedente Codice identificativo del concedente

Per le gerarchie dimensionali, rientrano in questa categoria le dimen-sioni Data e Prodotto, entrambe gerarchie bilanciate.

Dimensione Descrizione gerarchia

Data Mese → Anno

Prodotto Nome prodotto → Nome macro-prodotto

Infine, vengono elencate le misure e, per ognuna di esse, una breve descrizione e il tipo di aggregabilit`a. Si precisa che tutte le misure sono non derivate, tranne il capitale medio che `e pari alla media annuale del debito residuo.

(54)

Misura Descrizione Aggregabilit`a

Rata L’importo della rata da pagare Semi-Additiva

Quota capitale

Parte della rata che rappresenta il capitale restituito

Semi-Additiva

Quota interesse

Gli interessi maturati al fronte del servizio

Semi-Additiva

Durata residua

La durata mensile del debito, fino alla sua estinzione

Semi-Additiva

Provvigioni Compenso per l’intermediario Additiva

Commissioni

Compenso per le banche che coprono il rischio di insolvenza

dell’utilizzatore

Additiva

Debito residuo Il debito rimanente da saldare Semi-Additiva Capitale medio La media annuale del debito residuo Semi-Additiva

Tasso effettivo

Tasso di interesse che realmente grava sull’utilizzatore

Non Additiva

Tasso nominale

Tasso di interesse previsto dal contratto

(55)

Come mostrato nella tabella, la maggior parte delle misure utilizzate sono semi-additive, in quanto l’aggregazione `e significativa soltanto se `e definito un mese e anno di riferimento ed un mese e anno di proiezione. Fanno eccezione le misure additive relative alle provvigioni e alle com-missioni, mentre come misure non additive i tassi di interesse (effettivo e nominale) che esprimono percentuali.

(56)

4.1.2 Progettazione concettuale iniziale del data mart

Formalizzati i requisiti e definiti la tabella del fatto, dimensioni e misure utili per l’analisi, si delinea il modello concettuale iniziale del data mart mostrato in Figura 4.1, progettato appositamente per soddisfare le richieste dettate dai responsabili del controllo di gestione.

Figura 4.1: Schema concettuale iniziale del data mart

4.1.3 Progettazione concettuale candidata e finale del data mart

Per ritrarre un data mart finale che sia corretto e completo, bisogna verificare non solo che il modello soddisfi a pieno i requisiti riportati, ma che sussista un opportuno riscontro nei dati operazionali.

Il database sorgente, da cui si sono ricavati i dati utili ai fini della no-stra analisi, contiene numerose tabelle, ognuna delle quali, a loro volta,

(57)

include molteplici attributi. Dopo un’attenta analisi sul significato dei dati presenti, sono state considerate soltanto le tabelle (e gli attributi) ritenute valide per i nostri scopi:

• Fend rapp rata: contiene la descrizione delle rate e il dettaglio dei tassi di interesse associati ai contratti stipulati;

• Fend rapp prodotto: accoglie le caratteristiche dei prodotti ceduti;

• Fend rapp contratto modulo: ritrae i dettagli dei contratti, come ad esempio il tipo di modulo e la data di stipula;

• Fend anag ndg: include le informazioni personali dei concedenti;

Come descritto in [Albano-17], per identificare i fatti, le misure, le di-mensioni e le gerarchie dimensionali possibili, le tabelle devono essere classificate in una delle tre categorie:

– Entità Evento: sono tabelle che rappresentano eventi di interesse per l’analisi condotta. Questo tipo di entità possiede due carat-teristiche fondamentali: descrivere eventi che si verificano in un certo istante temporale e contenere misure o quantità che posso-no essere aggregate. Questi requisiti soposso-no soddisfatti dalla tabella Fend rapp rata che contiene informazioni definiti nel tempo (inclu-de mese e anno di riferimento e proiettivo) e valori aggregabili (ad esempio gli importi relativi alle rate e alle commissioni);

(58)

– Entità Componente: sono tabelle direttamente collegate, median-te una relazione una a molti, alle entità evento. Esse definisco-no i dettagli per ogni entità evento e rappresentano la base per la progettazione delle dimensioni nel modello concettuale. Le tabelle Fend rapp prodotto, Fend rapp contratto modulo e Fend anag ndg rappresentano questo tipo di entità;

– Entità di Classificazione: sono tabelle collegate ad una entità com-ponente da una catena di relazioni uno a molti; queste entità in genere rappresentano gerarchie e attributi dimensionali.

Poich´e non si presentano rilevanti differenze con il data mart iniziale, il modello finale `e esattamente il medesimo riportato in Figura 4.1.

(59)

4.1.4 Progettazione logica del data mart

Il modello concettuale finale di un data mart mette a disposizione tutti gli strumenti fondamentali per sviluppare il modello logico.

Nel nostro caso, come si osserva in Figura 4.2, il modello logico si pre-senta con uno schema a stella (star schema): al centro `e raffigurata la tabella del fatto in cui sono elencate le chiavi esterne, una per ogni di-mensione, e le misure. Collegata a questa sono presenti tante tabelle quante sono le dimensioni, ognuna delle quali, a loro volta, contiene la propria chiave primaria e gli attributi.

(60)

Capitolo 5

POPOLAMENTO DEL DATA

MART

La fase successiva prevede lo sviluppo dell’ ETL (Extract Transform Load) finalizzato a procurare i dati che popoleranno il data mart pro-gettato.

Come descritto nella documentazione [Golfarelli-06], l’ETL `e composto da tre processi:

• l’estrazione: consente di estrapolare i dati da una o pi`u sorgenti. Essa pu`o essere statica o incrementale: in linea teorica, l’estrazione statica viene effettuata quando il data mart deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali; l’estrazione incrementale viene usata per l’aggior-namento periodico del data mart e cattura solamente i cambiamenti avvenuti nelle sorgenti dall’ultima estrazione;

• la trasformazione: si suddivide, in realt`a, in due sottofasi: la prima mira ad un processo di miglioramento della qualit`a dei dati e alla risoluzione di errori quali dati duplicati e/o mancanti, l’uso non previsto di un campo, valori impossibili o errati; la seconda punta

(61)

5 – POPOLAMENTO DEL DATA MART

alla modifica del formato per rendere omogenei dati provenienti da sorgenti differenti, dove necessario.

• il caricamento: consiste nell’inserimento dei dati nel data mart e pu`o avvenire secondo due modalit`a:

– Refresh, in cui i dati vengono riscritti integralmente, sostituen-do quelli precedenti. Questa tecnica viene solitamente utilizza-ta, in abbinamento all’estrazione statica, per popolare inizial-mente il data mart;

– Update, dove solo i cambiamenti occorsi nei dati sorgente ven-gono aggiungi nel data mart, tipicamente senza distruggere o alterare quelli esistenti. Questa tecnica viene utilizzata, in abbinamento all’estrazione incrementale, per l’aggiornamento periodico.

Sia SadasBI Manager che Qlik Sense estraggono i dati da un unico data mart, creato appositamente per le nostre analisi. SadasBI Ma-nager, per sua natura, sfrutta un collegamento diretto con la sorgente dati (mediante interrogazioni SQL), mentre Qlik Sense attua un’ulterio-re procedura per il caricamento e la cun’ulterio-reazione del modello dati.

Nei paragrafi successivi si descrivono il processo di ETL per la creazione e il popolamento del data mart e il procedimento aggiuntivo eseguito in Qlik Sense.

(62)

5.1 Il processo di ETL

Il data mart proposto `e situato all’interno del Sadas Engine (il DBMS di Sadas) ed `e il risultato del processo di ETL dettagliato in questa se-zione.

La prima fase, l’estrazione dei dati, ha come unica sorgente il data ware-house gi`a esistente in Sadas Engine, a sua volta generato da varie fonti dati, che contiene tutte le informazioni connesse al sistema di controllo di gestione di Alba Leasing.

Per interagire con il DBMS è stato ampiamente utilizzato il tool Sadas - Database Control Manager, sviluppato da Sadas, che permette, tra le varie funzionalità, di interfacciarsi con le basi di dati presenti mediante interrogazioni (guidate e non) di query SQL e di creare nuovi database. L’autenticazione al DBMS Sadas Engine è mostrata in Figura 5.1.

Figura 5.1: Schermata di autenticazione

Per identificare le informazioni relative ai piani di ammortamento e ai contratti a reddito, si `e svolta un’analisi dettagliata sui dati che ha

(63)

condotto all’individuazione di tabelle e campi utili. Questo processo ha interessato una buona parte (in termini di tempo) del progetto. Le difficolt`a principali si sono riscontrate nel significato di alcuni campi (spesso rinominati con nomi tecnici e/o privi di documentazione) e la loro applicazione nel contesto aziendale. A tal proposito, sono stati implementati vari cruscotti di analisi utilizzando la suite SadasBI al fine di comprendere meglio l’organizzazione dei dati nel DWH.

Grazie a questi cruscotti, inoltre, `e stata studiata la struttura detta-gliata del piano di ammortamento di ciascun contratto di leasing. Essa contiene la descrizione rateale del debito, distribuita nel tempo dal mese e anno di riferimento e dal mese e anno di proiezione. Nello specifico:

• i mesi e anni di riferimento presentano valori per l’intera durata del contratto, dalla data di stipula fino alla chiusura;

• identificato un mese e anno di riferimento, i mesi e anni proietti-vi contengono valori dal dicembre dell’anno precedente (rispetto a quello di riferimento) fino al mese e anno di chiusura del contratto; • identificato un mese e anno di riferimento, il mese e anno proiettivo pari a dicembre dell’anno precedente mostra i valori aggregati fino a quella data, mentre i successivi, dal mese di gennaio dell’anno di riferimento fino al mese e anno di termine del contratto, evidenziano, ad ogni riga, i dettagli della singola rata.

Ad esempio, dato un contratto, si suppone che la data di stipula sia gennaio 2016 e il termine del contratto `e previsto per dicembre 2020.

(64)

Scegliendo un mese e anno di riferimento casuale, ma appartenente al periodo in cui il contratto `e a reddito, come marzo 2017, i mesi e anni proiettivi presentano valori nell’intervallo da dicembre 2016 a dicembre 2020 (data di chiusura del contratto). Per il mese e anno proiettivo pari a dicembre 2016, il piano di ammortamento mostra attributi aggregati, ad esempio il totale delle rate, della quota capitale e della quota interesse da gennaio a dicembre 2016; per i successivi, il piano di ammortamento evidenzia il dettaglio della specifica rata prevista in quel mese e anno proiettivo, cos`ı fino alla chiusura del contratto.

Ci`o implica una significativa ridondanza con conseguenze sulle dimen-sioni della tabella dei fatti in termini di righe. Non potendo eliminare tale ridondanza, in quanto gli importi delle rate, della quota capitale, degli interessi e di tutti i valori legati a questi potrebbero modificarsi nel tempo, l’unica soluzione `e la riduzione delle colonne, ossia individuare quelle indispensabili per le nostre analisi ed eliminare le superflue.

Individuate le tabelle e i campi funzionali per l’analisi, sono state ge-nerate delle tabelle di appoggio come “staging area” su cui poter svolgere la fase di trasformazione, senza modificare quelle originali. In partico-lare, la trasformazione dei dati ha riguardato la rimozione di attributi ritenuti irrilevanti, l’eliminazione di righe duplicate, la creazione di nuo-vi campi che rispettassero le dipendenze funzionali (ad esempio, mese e anno di riferimento o il numero di contratto e il relativo modulo) e la cancellazione di record che rappresentano contratti chiusi, dato che il

(65)

nostro progetto ha lo scopo di analizzare soltanto i contratti attualmen-te redditizi. Per quest’ultimo si sono sfruttaattualmen-te le logiche utilizzaattualmen-te nel DWH di origine per distinguere i contratti a reddito da quelli chiusi o sospesi.

Successivamente alla fase di manipolazione e trasformazione, si è giun-ti al caricamento dei dagiun-ti. Create le engiun-tità rappresentanti la tabella del fatto e le dimensioni, specificando le relazioni con chiavi primarie ed esterne, il caricamento dei dati è stato eseguito mediante query SQL, trasferendo le ennuple dalle tabelle di appoggio a quelle definitive.

Nella Figura 5.2 `e mostrata la query SQL per la creazione della tabella del fatto. Come si osserva, l’interrogazione `e composta da due parti principali: con la keyword CREATE TABLE si genera la tabella vuota e si definiscono le chiavi esterne e gli attributi della tabella indicando, per ognuno di essi, il tipo e la lunghezza del campo; con la keyword REWRITE TABLE la stessa tabella viene popolata estrapolando i dati dalle strutture di appoggio.

(66)

Il data mart finale `e rappresentato in Figura 5.3.

(67)

5.2 ETL in Qlik Sense

Qlik Sense, pur non offrendo un tool ufficiale dedicato all’ETL, pro-pone due soluzioni alternative per simulare ed approssimare le tre fasi: il data manager, mediante procedure manuali, oppure l’editor di carica-mento dei dati, tramite lo sviluppo di script. La scelta della soluzione migliore varia principalmente in base alla mole dei dati - `e preferibile scegliere la seconda alternativa nel caso in cui la quantit`a dei dati sia considerevole - e alle competenze tecniche dell’utente che possiede i di-ritti per la creazione di app, da qui chiamato sviluppatore.

Il procedimento da seguire cambia a seconda dell’approccio selezionato. Se si opta per il data manager, tutte le operazioni vengono svolte manualmente dallo sviluppatore. Per la descrizione di questa soluzione si fa riferimento alla documentazione ufficiale [DataManager-18], dove sono definiti tutti i passaggi utili per creare il modello dati. La prima fase, l’estrazione, inizia scegliendo la sorgente da cui estrapolare i dati. La figura 5.4 mostra i vari tipi di origine dati: file locali, sorgenti di dati esterne, inserimento manuale. Inoltre, `e possibile specificare delle condizioni di filtro per estrarre solamente dati specifici.

La fase di trasformazione e manipolazione dei dati riguarda opera-zioni svolte a discrezione dello sviluppatore, come la modifica del tipo e del formato dei valori di un campo, l’aggiunta di un campo calcolato, la concatenazione di due tabelle in una unica con campi combinati. In que-sta fase `e prevista anche la gestione delle associazioni delle tabelle dati.