Un tool di pianificazione per i fondi garanzia di una multinazionale del settore automotive

UNIVERSITÀ DI PISA

Dipartimento di Informatica

Corso di Laurea Magistrale in Informatica per l’economia e per l’azienda (Business Informatics)

TESI DI LAUREA

Un tool di pianificazione per i fondi garanzia di una multinazionale del settore automotive

Relatore Candidato

Prof. Roberto BRUNI Andrea SEDDA

All’interno del presente lavoro di tesi vengono descritte le varie fasi di realizzazione di una applicazione destinata a supportare gli utenti di una multinazionale del settore automotive nel processo di pianificazione delle risorse da destinare a copertura delle garanzie dei propri veicoli. Sono state illustrate le criticità presenti nel processo analizzato e le scelte progettuali effettuate al fine di superarle.

Durante il processo di implementazione sono stati definiti dei flussi ETL che alimentano l’applicazione sfruttando alcune sorgenti dati già presenti all’interno del data warehouse aziendale e utilizzando una serie di logiche volte a gestire le specificità proprie del processo d’interesse.

All’interno del documento viene inoltre descritta la parte front-end dell’applicazione contenente delle schede di input tramite le quali gli utenti abilitati possono inserire i dati di pianificazione e dei report sui quali vengono mostrati gli output prodotti dal processo.

Indice

Capitolo 1 - Introduzione ... 1

1.1 - L’azienda Pivot Consulting ... 2

1.2 - Contributo al processo di pianificazione ... 2

1.3 - Contenuto della tesi ... 3

Capitolo 2 - Il contesto di riferimento ... 4

2.1 - Definizione dei processi di pianificazione ... 4

2.2 - Criticità del processo di pianificazione e obiettivi del progetto ... 5

2.3 - Variabili alla base dei processi di pianificazione ... 7

2.4 - Definizione ed inquadramento temporale dei processi di pianificazione... 10

2.4.1 - Budget Rimborsi-Utilizzi ed Accantonamenti ... 10

2.4.2 - Forecast Rimborsi-Utilizzi, Accantonamenti e revisione del Fondo Garanzie..11

2.4.3 - Timeline di processo ... 11

2.5 - Il contesto tecnologico di riferimento... 12

2.5.1 - Definizione di ERP e storia di SAP... 13

2.5.2 - L’infrastruttura tecnologica presente all’interno dell’azienda committente.. 14

2.5.3 - SAP Business suite... 15

2.5.4 - SAP Business Warehouse... 16

2.5.5 - SAP Business Explorer... 18

2.5.6 - SAP Business Planning and Consolidation... 19

Capitolo 3 - Progettazione dell’applicativo... 21

3.3 - Definizione del livello di dettaglio della pianificazione... 27

3.4 - Schema logico dell’applicazione... 29

Capitolo 4 - Il processo di ETL... 31

4.1 - Definizione del processo di ETL... 31

4.2 - Struttura del modello di approvvigionamento dei dati... 32

4.3 - Flusso di caricamento costi per veicolo... 36

4.4 - Flusso di caricamento volumi di vendita... 49

4.4.1 - Volumi di Sell-in consuntivo... 50

4.4.2 - Volumi di Sell-out consuntivo... 51

4.4.3 - Volumi di Sell-in pianificato... 52

4.4.4 - Volumi di Sell-out pianificato... 53

Capitolo 5 - Il tool di pianificazione... 55

5.1 -Il Client di amministrazione... 55

5.2 - Menù amministratore... 58

5.2.1 - Attività preliminari... 59

5.2.2 - Inizializzazione parametri... 59

5.2.3 - Caricamento volumi di vendita... 61

5.2.4 - Finalizzazione versione... 61

5.3 - Menù technical user... 61

5.3.1 - Data extraction... 62

5.3.2 - Data adjustment... 64

5.4 - Menù Market Planner... 65

Conclusioni... 73 Bibliografia... 75

1

In ogni azienda di dimensioni medio-grandi i processi di pianificazione delle risorse finanziarie assumono un ruolo di primo piano. Essi consentono di sfruttare al massimo le capacità economiche e produttive dell’azienda cercando di allocare in maniera efficiente le risorse in modo da evitare che esse restino inutilizzate o che risultino insufficienti all’adempimento di determinati impegni.

Nel contesto di una azienda che produce beni materiali per il consumo, oltre ai costi di progettazione, realizzazione e distribuzione di un prodotto, vanno considerati anche dei costi legati al periodo temporale successivo alla vendita dello stesso. Alcuni di questi costi sono quelli relativi alla garanzia offerta al cliente al momento dell’acquisto.

Nel settore dell’automotive i costi legati a questo aspetto sono mediamente abbastanza elevati e dunque una corretta pianificazione delle risorse in questione riveste una grande importanza.

In questa tesi è descritta la realizzazione di una applicazione di pianificazione per le risorse economiche da destinare a copertura delle garanzie dei veicoli prodotti da una importante multinazionale del settore automotive.

L’azienda committente ha richiesto l’implementazione di un applicativo che guidasse gli utenti responsabili del processo nella definizione delle risorse da destinare agli interventi eseguiti sui propri veicoli in garanzia. Tale richiesta è stata tradotta nella realizzazione di un progetto di pianificazione denominato WAP, acronimo di “Warranties Accruals Planning”.

L’obiettivo prefissato in fase di definizione delle specifiche è stato quello di sviluppare un applicativo che superasse alcune importanti criticità presenti nel processo di pianificazione, realizzando uno strumento centralizzato che consentisse di eseguire in maniera precisa le operazioni necessarie.

Per la realizzazione del progetto sono state utilizzate le tecnologie SAP Business Warehouse e SAP Business Planning and consolidation.

L’applicazione è stata realizzata durante lo svolgimento di uno stage presso l’azienda di consulenza Pivot Consulting S.r.l., con sede a Pontedera.

2

1.1 L’azienda Pivot Consulting

Fondata nel 1999 a Pisa e successivamente trasferitasi a Pontedera, Pivot Consulting è una azienda operante nel settore della consulenza IT. Nel corso degli anni l’azienda ha lavorato con diverse tipologie di clienti sviluppando competenze nello sviluppo di soluzioni tecnologiche a supporto di vari settori quali ad esempio Automotive, Fashion, Manufacturing e Logistica.

Il core-business aziendale è sempre stato legato alla realizzazione di applicazioni basate su tecnologie a marchio SAP, tuttavia l’azienda opera anche mediante l’utilizzo di tecnologie sviluppate da altre software house.

Durante il periodo di stage ho avuto modo di lavorare all’interno di un team composto da tre persone, partecipando a tutte le fasi di realizzazione dell’applicazione ed agli incontri periodici col cliente.

1.2 Contributo al processo di pianificazione

Il processo di pianificazione di interesse, prima della realizzazione dell’applicativo, veniva gestito in maniera completamente manuale dagli utenti responsabili dello stesso. Essi reperivano i dati di partenza in maniera autonoma tramite delle estrazioni dati eseguite sul data warehouse aziendale. I dati estratti venivano poi elaborati all’interno di un cospicuo numero di fogli di lavoro excel che venivano successivamente salvati su cartelle condivise con gli altri utenti coinvolti nel processo. L’applicazione è stata realizzata con lo scopo di rendere il più possibile automatiche le operazioni in questione in modo da velocizzare i tempi di esecuzione del processo e minimizzare il rischio di errori.

Un’altra funzionalità importante offerta dall’applicazione è legata alla possibilità per i pianificatori di inserire degli aggiustamenti sui dati estratti dal sistema solamente se corredati da una motivazione che giustifichi la modifica in questione. In questo modo è stata garantita la tracciabilità delle operazioni e sono stati ridotti al minimo potenziali equivoci tra gli attori coinvolti nel processo. Queste ed altre criticità saranno meglio descritte nel capitolo successivo.

3

1.3 Contenuto della tesi

Verrà ora fatta una panoramica sugli argomenti trattati nei capitoli seguenti.

All’interno del capitolo 2 sono stati descritti i processi di pianificazione di interesse, sono state elencate le criticità presenti all’interno degli stessi nonché gli obiettivi migliorativi del progetto. Sono state inoltre illustrate le tecnologie utilizzate ai fini della realizzazione della soluzione.

Nel capitolo 3 sono state descritte le scelte di progettazione e le caratteristiche proprie di una applicazione realizzata con SAP Business Planning and Consolidation. Sono stati inoltre definiti il perimetro dimensionale di riferimento ed il livello di dettaglio della pianificazione.

Nel capitolo 4 viene descritto il processo di ETL implementato a supporto dell’approvvigionamento delle informazioni. Sono state illustrate le strutture dati coinvolte e le logiche definite per la gestione di alcune casistiche particolari.

Nel capitolo 5 è presente una panoramica della parte front-end dell’applicazione, con la descrizione delle funzionalità accessibili dalle diverse tipologie di utenti coinvolti nel processo.

4

In questo capitolo verrà illustrato il contesto generale di riferimento del progetto realizzato. Verranno descritte le problematiche principali affrontate e gli obiettivi prefissati. Verrà inoltre fatta una panoramica sull’infrastruttura tecnologica presente presso l’azienda committente al momento dell’implementazione.

2.1 Definizione dei processi di pianificazione

In ogni azienda di dimensioni medio-grandi, i sistemi di pianificazione e controllo rivestono un ruolo di importanza cruciale. I sistemi di controllo possono essere distinti in relazione al proprio orizzonte temporale di riferimento, [1]:

• Controllo antecedente (ex ante): I meccanismi di controllo sono implementati prima che si verifichino gli eventi aziendali di interesse. Ci si riferisce a questa fase anche coi termini di Pianificazione e di Programmazione.

• Controllo consuntivo (ex post): Sono meccanismi implementati dopo il verificarsi degli eventi aziendali di interesse. Il controllo consuntivo si distingue a sua volta in controllo Feed back, ovvero rivolto al passato, che si propone di intervenire sulle disfunzioni rilevate nei fatti analizzati, ed in controllo Feed forward, ovvero rivolto al futuro, che si propone di anticipare le eventuali disfunzioni future.

In linea generale si può dire che gli strumenti utilizzati per il controllo antecedente sono i Budget ed i piani operativi, mentre per il controllo consuntivo vengono adottati sistemi di Reporting e di Forecasting.

Il budget è lo strumento attraverso il quale l’azienda definisce il proprio piano d’azione, espresso in termini quantitativi o monetari, su un orizzonte temporale definito, tipicamente un anno.

5

Il processo di forecasting presenta molte affinità con quello di budgeting, tuttavia permette di produrre una pianificazione più accurata, aggiornata ad intervalli temporali più frequenti rispetto al budget.

Si può affermare che se il budget definisce quelli che sono gli obiettivi dell’azienda per l’intero anno di riferimento, il processo di forecast stima in maniera più precisa il risultato impiegando i dati reali raccolti nel tempo.

2.2 Criticità del processo di pianificazione e obiettivi del progetto

Uno dei processi di pianificazione utilizzati all’interno dell’azienda committente è quello legato alla pianificazione dei quantitativi monetari destinati a coprire gli interventi di riparazione sui veicoli in garanzia. Verranno nel seguito descritte le criticità del processo e la funzione degli output prodotti dallo stesso.

Al momento della richiesta di realizzazione dell’applicativo i cicli di pianificazione di Accantonamenti, Rimborsi-Utilizzi e Fondi Garanzia venivano completati in maniera manuale dagli utenti. L’intero processo era interamente gestito e sviluppato mediante l’ausilio di un cospicuo numero di fogli di lavoro Excel: si tratta di circa 300 fogli prodotti per i soli cicli di budget, senza considerare la pianificazione legata ai cicli di forecast.

La produzione dei documenti in questione da parte degli utenti incaricati alla definizione del Budget comportava la modifica, l’adattamento e l’armonizzazione di dati estratti da sistemi informativi centrali (provenienti dal data warehouse aziendale SAP) e di dati provenienti da altre fonti non centralizzate, tipicamente file locali.

Durante il ciclo di pianificazione gli output del processo venivano condivisi all’interno di cartelle di rete con gli utenti abilitati ad analizzarne il contenuto ovvero alcune figure facenti parte del reparto di assistenza tecnica e dell’area operativa del Controllo di gestione dell’azienda.

La metodologia di lavoro appena descritta presenta una serie di importanti criticità:

• Scarsa tracciabilità delle operazioni di pianificazione. Gli utenti abilitati possono infatti modificare il contenuto delle cartelle di rete in maniera libera e senza dover apporre alcuna nota a corredo dell’eventuale modifica del valore di un indicatore in favore di un altro generando possibili incomprensioni durante il processo di pianificazione.

6

• Tempi di produzione degli output di processo significativamente dilatati. La durata intercorrente tra l’inizio delle operazioni di reperimento dei dati elementari relativi alle variabili di partenza e la produzione degli output relativi al Budget era di circa due mesi.

• Armonizzazione e modifica manuale, spesso onerosa e potenziale causa di errori, dei dati estratti da sorgenti eterogenee.

• Aggiustamenti sui dati effettuati tramite input manuali eseguiti direttamente sugli output della pianificazione esistente, operazioni che espongono ad un elevato rischio di errore, visto l’elevato numero di schede prodotte.

• Mancanza di strumenti di simulazione e di reporting.

Il fatto che i dati di input del processo fossero prevalentemente recuperati da sistemi aziendali centralizzati ha reso possibile l’ipotesi di realizzazione di una soluzione che rendesse automatico l’approvvigionamento di tutte le variabili di partenza del processo. Tali variabili sono poi modificabili liberamente dal pianificatore, accompagnando una motivazione di tipo tecnico o gestionale alla modifica stessa.

I principali obiettivi del progetto in termini di miglioramento del processo di pianificazione sono identificabili con i seguenti:

• Creazione di uno strumento centralizzato in grado di rendere più veloci e quanto più possibile automatiche le operazioni di reperimento e di preparazione dei dati necessari alla pianificazione del Budget Rimborsi-Utilizzi ed Accantonamenti.

• Prevedere una soluzione in grado di gestire in maniera coerente l’abilitazione specifica utente-ruolo-funzionalità. Ciò consente di tenere traccia dell’autore di qualsiasi operazione effettuata a sistema nonché di separare in maniera definita i compiti assegnati ai vari attori del processo di pianificazione.

7

• Ottimizzazione della metodologia attualmente seguita durante la pianificazione per mezzo di uno strumento centralizzato, finalizzato a supportare gli utenti durante i cicli di Forecast, di Revisione e di Analisi del Fondo Garanzie.

• Definizione di un flusso di processo che permetta di guidare in maniera ordinata i pianificatori nelle loro attività di definizione degli output.

• Storicizzazione dei dati di input e di output in al fine di garantire la disponibilità di ogni misura coinvolta nel processo per una eventuale implementazione successiva di strumenti di reportistica.

2.3 Variabili alla base dei processi di pianificazione

Nel corso dei cicli di pianificazione oggetto di implementazione all’interno del progetto WAP, vengono estratte una serie di variabili che, opportunamente combinate e distribuite, portano al calcolo delle grandezze di output legate ai processi stessi. Sarà data nel seguito una definizione di quelle che sono le variabili che stanno alla base dei processi di pianificazione. Le variabili in oggetto non sono state definite in fase di realizzazione dell’applicazione ma sono parte di un processo ben consolidato nell’ambito aziendale.

• Sell-In Actual: Il Sell-In Actual, altrimenti detto Sell-In Consuntivo, è la grandezza che identifica il numero di veicoli venduti dall’azienda alla propria rete di concessionari. Essendo un dato consuntivo, la grandezza in oggetto non viene utilizzata in fase di definizione dei budget bensì in fase di preparazione degli output relativi ai cicli di forecast semestrali.

• Sell-In Planned: Il Sell-In Planned o Sell-In pianificato è la grandezza che identifica il numero di veicoli che, in fase di pianificazione, l’azienda stima di vendere ai concessionari nel periodo di riferimento.

8

• Sell-Out Actual: Il Sell-Out Actual o Sell-Out Consuntivo è la grandezza relativa al numero di veicoli immatricolati nel periodo di riferimento. Tale dato consuntivo viene solitamente reperito e aggregato da diverse fonti esterne, come ad esempio i dati delle immatricolazioni presso gli uffici delle motorizzazioni civili.

• Sell-Out Planned: Il Sell-Out Planned o Sell-Out Pianificato è la grandezza relativa al numero di veicoli che l’azienda stima verranno immatricolati nel periodo di riferimento. Tale dato, al momento della pianificazione dei processi interessati dal progetto, non era presente all’interno di nessuna struttura sui sistemi aziendali. Esso veniva infatti definito per mezzo di una stima fornita dai membri del dipartimento di Marketing Analysis tramite l’utilizzo di un file inviato ai pianificatori.

• Net Stock 31.12: Lo Stock di Rete al 31.12 è il dato che identifica quanti veicoli sono presenti nella rete dei concessionari del gruppo alla data del 31 dicembre dell’anno precedente all’anno di pianificazione. Il dato è calcolato mediante la formula seguente (si consideri l’anno Y come anno di pianificazione):

Net Stock(31.12 Y-1) = Net Stock(31.12 Y-2) + Sell-In Actual(Y-1) – Sell-Out Actual(Y-1)

• C/V: Il C/V o Costo per Veicolo è il dato che sta alla base dei processi di pianificazione presi in esame. Le componenti che lo determinano vengono estratte da alcune strutture dati presenti sul sistema di datawarehousing aziendale dai pianificatori dei vari mercati, applicando diversi perimetri di analisi. Vengono utilizzati il C/V a 6 mesi sul periodo di delibera e i C/V a 6 e 24 mesi su periodo di vendita.

I primi identificano i costi degli interventi in garanzia relativi ai sei mesi successivi alla data di emissione di un ordine. I secondi identificano i costi degli interventi in garanzia relativi ai sei e ai 24 mesi successivi alla data effettiva di vendita di un veicolo.

• % Net: La percentuale di costo netto sul costo totale è estratta dal data warehouse direttamente dai pianificatori ed è determinata dalla formula seguente:

9

% Net = (Costo Industriale Ricambio + Costo Manodopera) / (Totale Costo Garanzia)

• % Cost (1st _{Y), % Cost (2}nd_{Y), % Cost (3}rd _{Y): Le percentuali di costo della garanzia sul}

primo, secondo e terzo anno di vita del veicolo sono estratte dal data warehouse direttamente dai pianificatori considerando il periodo di vendita. Esse identificano la frazione del costo totale della garanzia associata ad ognuno degli anni inclusi nella garanzia stessa.

• % Spare Gross (1st _{Y), % Spare Gross (2}nd _{Y), % Spare Gross (3}rd_{Y): Le percentuali di}

costo dei ricambi sul costo lordo della garanzia nel primo, secondo e terzo anno di vita del veicolo sono estratte da SAP BW direttamente dai pianificatori e sono determinate dalla seguente formula:

% Spare Gross = (Totale costo garanzia - Costo Manodopera) / Totale costo garanzia

• % Spare Net (1st _{Y), % Spare Net (2}nd_{Y), % Spare Net (3}rd_{Y): Le percentuali di costo dei}

ricambi sul costo netto della garanzia nel primo, secondo e terzo anno di vita del veicolo sono estratte da SAP BW direttamente dai pianificatori e sono determinate dalla seguente formula:

% Spare Net = Costo Industriale / (Costo industriale + Costo Manodopera)

• ParQ e ParG: I parametri di qualità e gestione sono dei parametri correttivi del C/V inseriti manualmente dai pianificatori sulle schede di input per tenere conto di iniziative gestionali o di miglioramento della qualità finalizzate alla riduzione del C/V per un determinato contesto di riferimento.

• Significatività Sell-Out: La soglia di significatività del Sell-Out identifica il volume di Sell-Out al di sotto del quale un C/V non viene considerato, appunto, significativo ai fini della pianificazione. Ciò porta il pianificatore a dover compiere alcune azioni correttive in fase di elaborazione degli output.

10

• % Spar Infl. (1st _{Y) , % Spare Infl. (2}nd _{Y), % Spare Infl. (3}rd _{Y): Si tratta della percentuale}

di inflazione annuale del costo ricambio. La percentuale solitamente è uguale per tutti e tre gli anni.

• % Labour Infl. (1st _{Y), %Labour Infl. (2}nd _{Y), % Labour Infl. (3}rd _{Y): Si tratta delle}

percentuali di inflazione annuali del costo manodopera. La percentuale solitamente è uguale per tutti e tre gli anni.

2.4 Definizione ed inquadramento temporale dei processi di pianificazione

Nel presente paragrafo verrà data una breve descrizione di quelli che sono i processi oggetto di definizione all’interno dell’applicativo, illustrandone anche la collocazione temporale all’interno dell’anno di pianificazione.

2.4.1 Budget Rimborsi-Utilizzi ed Accantonamenti

Il processo di pianificazione relativo al Budget Rimborsi-Utilizzi ed Accantonamenti inizia tipicamente nel mese di settembre e la produzione degli output avviene solitamente intorno al mese di dicembre.

La pianificazione dei Rimborsi-Utilizzi viene effettuata a partire dai volumi di Sell-Out consuntivo degli ultimi due anni e del Sell-Out pianificato dell’anno seguente.

Il processo di pianificazione in oggetto è legato al parco veicoli circolante coperto da garanzia e permette di pianificare i rimborsi per tutto l’arco di validità della copertura offerta, ovvero i tre anni successivi rispetto alla definizione dell’output.

La pianificazione degli Accantonamenti viene effettuata a partire dalla grandezza di Sell-in pianificato dell’anno seguente e permette di calcolare le coperture economiche legate alle garanzie dell’intero parco veicoli presente presso la rete dei concessionari. In entrambe le tipologie di pianificazione riveste particolare interesse la variabile di C/V o Costo per Veicolo, estratto secondo diversi criteri a seconda delle tipologie di parametrizzazioni richieste nelle varie fasi della pianificazione.

11

2.4.2 Forecast Rimborsi-Utilizzi, Accantonamenti e revisione del Fondo Garanzie

I processi di revisione dei Rimborsi-Utilizzi, degli Accantonamenti e di calcolo ed attualizzazione del Fondo Garanzie permettono di riattualizzare le stime di Budget utilizzando i dati consuntivi di Sell-Out, di Sell-In ed i valori relativi allo Stock di rete year to date.

Ai sopra citati cicli di pianificazione si accompagnano attività mensili di analisi dei dati consuntivi e rettifiche manuali che vengono talvolta effettuate per completare la riattualizzazione del Fondo Garanzie.

La definizione del Fondo Garanzie consente all’azienda di determinare quante risorse economiche andranno accantonate per far fronte alle spese future relative agli interventi da compiere sui veicoli coperti da garanzia.

2.4.3 Timeline di processo

La tabella 2.1 illustra in maniera schematica la timeline del processo di pianificazione delle garanzie in essere al momento della richiesta della realizzazione dell’applicativo.

Considerando un anno “Y” come anno di riferimento per la pianificazione corrente, si può vedere come nel mese di gennaio venga effettuata la revisione del fondo garanzie relativo all’anno precedente.

A cavallo tra maggio e giugno vengono svolte le attività preliminari per la revisione semestrale del fondo con la raccolta e l’elaborazione dei dati relativi ai consuntivi. Nel mese di luglio vengono redatte le semestrali vere e proprie, relative ai fondi garanzie. La redazione dei budget rimborsi/utilizzi e accantonamenti relativi all’anno solare successivo comincia nel mese di settembre e termina invece nel mese di ottobre. Si nota dunque immediatamente quanto i tempi di produzione degli output siano piuttosto lunghi e infatti, come affermato in precedenza, uno degli obiettivi principali del progetto è quello di accorciare in maniera considerevole la durata dei processi. Il raggiungimento di tale obiettivo presenta vari vantaggi tra cui quello di consentire agli utenti di lavorare con un livello maggiore di attenzione al dettaglio e di effettuare un numero più elevato di simulazioni. Ciò si traduce nella possibilità concreta di ottenere stime maggiormente accurate.

12

Timeline processo pianificazione garanzie anno Y

01.Y Revisione fondo FINE ANNO Y-1

02.Y

03.Y

04.Y

05.Y

Revisione fondo Y SEMESTRALE (Fase preliminare) 06.Y

07.Y Revisione fondo Y SEMESTRALE

08.Y

09.Y Budget Rimborsi/utilizzi Y+1 (Fase preliminare) Budget accantonamenti Y+1 (Fase preliminare)

10.Y Budget Rimborsi/utilizzi Y+1 Budget accantonamenti Y+1

11.Y

12.Y

Tabella 2. 1: Flusso temporale del processo di pianificazione

2.5 Il contesto tecnologico di riferimento

All’interno dell’azienda committente sono presenti diverse soluzioni tecnologiche a supporto della gestione dei dati che riguardano tutte le aree aziendali e che si differenziano a seconda del contesto applicativo.

Tutta l’infrastruttura tecnologica è basata su soluzioni a marchio SAP. In questo paragrafo verrà fatta una panoramica degli strumenti utilizzati per l’implementazione dell’applicazione. Ai fini della scrittura dei contenuti di questo paragrafo sono stati consultati il sito ufficiale dell’azienda, [5] e il portale della community ufficiale SAP, [7].

13

2.5.1 Definizione di ERP e storia di SAP

SAP, acronimo di “System analyse und Programmentwicklung” (Tradotto in inglese come “System Analysis and Program development”) è un’azienda informatica fondata nel 1972 a Mannheim in Germania da cinque ex dipendenti del colosso statunitense dell’informatica IBM,[5].

All’epoca le soluzioni informatiche utilizzate dalle grosse aziende erano implementate su misura delle esigenze specifiche di ognuna di esse.

In pochi anni SAP è stata in grado di ampliare in maniera considerevole il portafoglio clienti tramite la realizzazione di un sistema modulare di gestione delle aree aziendali di base come la contabilità finanziaria, gli acquisti e le vendite.

Attualmente le soluzioni a marchio SAP consentono di gestire con dei pacchetti standard un numero elevatissimo di processi di business predefiniti: si va dalla gestione del magazzino quella delle vendite, passando per la contabilità e la gestione delle risorse umane. Un sistema di questo tipo, che consente la gestione modulare dei dati relativi a diverse aree aziendali, è chiamato ERP, acronimo di “Enterprise Resource Planning”. Un ERP è solitamente caratterizzato dalla presenza di un database condiviso da una serie di moduli. Ogni singolo modulo presenta una serie di caratteristiche che lo rende pronto a gestire tutta una serie di casistiche standard relative all’ambito applicativo corrispondente. Le caratteristiche standard dell’ERP possono essere adattate o ampliate in modo da soddisfare i requisiti richiesti dall’azienda in cui esso viene implementato. Nel 1979 SAP lanciò sul mercato la seconda versione del suo ERP, denominata SAP R/2 (la R sta per “Real-time”) che adottò l’organizzazione modulare basata su un database comune implementato su dei mainframe. Questa soluzione consentiva di ridurre notevolmente i costi legati al data entry e la modularità del sistema era molto ben vista dalle aziende che potevano dotarsi dei soli elementi di interesse per il proprio contesto di business. Ciò portò l’azienda tedesca a conquistare fette sempre più considerevoli di mercato e ad investire nello sviluppo del proprio prodotto.

Nei primi anni 90 vide la luce la terza versione dell’ERP targato SAP, chiamata R/3. Questa versione introduceva importanti novità sia in termini di organizzazione che di elaborazione delle informazioni.

14

In termini di elaborazione si registrò un passaggio dal paradigma mainframe-based a quello client-server. I dati dunque non venivano più elaborati in maniera centralizzata da costosi mainframe ma in maniera distribuita da una serie di server collegati tra loro in rete che rendevano poi le informazioni disponibili agli utenti per mezzo di una serie di macchine client.

Un’altra innovazione importante fu quella che consentì di integrare i dati presenti nei diversi moduli mediante l’utilizzo di un componente centrale. Ciò consentiva di vedere tutte le diverse operazioni aziendali come un unico processo consolidato di business. La versione R/3 di SAP ebbe un enorme successo e fu installata presso migliaia di aziende di dimensioni medio-grandi, consacrando SAP come una delle compagnie più importanti e redditizie del panorama IT.

Nel 2013 SAP ha introdotto un’altra versione del proprio ERP, denominata S/4HANA. Questa versione è stata realizzata su misura in modo da poter sfruttare le potenzialità del nuovo database di SAP chiamato per l’appunto HANA. Tale database utilizza un’organizzazione delle informazioni di tipo colonnare e utilizza una tecnologia in-memory per migliorare le performance ed essere sfruttato in contesti innovativi come quelli legati al cloud.

2.5.2 L’infrastruttura tecnologica presente all’interno dell’azienda committente

L’azienda committente adotta soluzioni tecnologiche a marchio SAP per gestire le varie aree operative aziendali mediante l’utilizzo di vari componenti. Uno schema di base delle componenti utilizzate e delle tecnologie che utilizzano l’ERP stesso come base dati di partenza è mostrato nella figura 2.1. In seguito verrà data una descrizione più dettagliata delle varie componenti presenti.

15 BW (Business Warehouse) SCM (Supply Chain Management) PLM (Product Lifecycle Management) Other SAP Module SRM (Supply Relationship Management) HCM (Human Capital Management)

ECC (ERP Central Component)

Bex (Business Explorer) BPC (Business Planning and Consolidation) Other Front-end application

Figura 2. 1: Architettura tecnologica presente nel contesto aziendale

2.5.3 SAP Business suite

Nella parte bassa della figura 2.1 si possono vedere alcuni dei componenti facenti parte della SAP Business suite, una raccolta di software realizzati da SAP implementata presso l’azienda che ha commissionato la realizzazione dell’applicativo.

Ognuno di questi moduli supporta la gestione di specifiche operazioni aziendali. Il software SCM (Supply Chain Management) permette all’azienda di gestire tutte quelle che sono le operazioni legate alla gestione della catena di distribuzione come ad esempio la gestione degli approvvigionamenti e del magazzino.

Il software SRM (Supply Relationship Management) è utilizzato per la gestione giornaliera delle operazioni di approvvigionamento dei beni e dei servizi necessari al corretto funzionamento dell’azienda.

Il software HCM (Human Capital Management) è utilizzato per la gestione delle risorse umane facenti capo all’azienda.

Il software PLM (Product Lifecycle Management) consente all’azienda di gestire quello che è l’intero ciclo di vita del prodotto: dalla fase di progettazione al lancio sul mercato fino al suo ritiro dal commercio.

16

Questi ed altri moduli sono collegati tra loro da quello che è il componente centrale del sistema ERP di SAP, denominato ECC (ERP Central Component) che consente di accedere ai dati relativi a un gran numero di processi aziendali diversi.

2.5.4 SAP Business Warehouse

Al di sopra del sistema di ERP, in figura 2.1, è presente quello che è il software di datawarehousing realizzato da SAP, chiamato Business Warehouse, spesso abbreviato in BW.

Il data warehouse permette di gestire i dati provenienti dagli altri componenti SAP o da sorgenti esterne, effettuare trasformazioni sui dati stessi e consolidarli. Esso fornisce i servizi di base tipici di un data warehouse:

• Servizi di ETL: BW consente di gestire le operazioni di estrazione da sorgenti data eterogenee, offre strumenti che permettono di trasformare le informazioni per renderle conformi alle analisi da svolgere e consente il caricamento dei risultati su strutture dati dedicate.

• Servizi di storage: All’interno del data warehouse è possibile salvare le informazioni in diversi tipi di strutture dedicate, utilizzate anche come aree di staging all’interno di flussi ETL.

• Motore OLAP: Il motore OLAP (On Line Analytical Processing) permette di accedere alle informazioni contenute nel data warehouse utilizzando funzionalità di navigazione analitica come filtri, calcoli a run-time, controlli autorizzativi e conversioni valutarie.

• Servizi di presentazione: BW offre anche degli strumenti per la presentazione delle informazioni; il principale di questi è chiamato Business Explorer e sarà descritto nel paragrafo successivo.

17

possono soddisfare differenti esigenze di utilizzo. Per le finalità legate alle analisi multidimensionali vengono solitamente utilizzati quelli che sono chiamati “Infocubi” e altro non sono che l’implementazione di un data mart.

Un infocubo consente di specificare una serie di dimensioni di analisi coi relativi attributi e di definire una serie di misure che nel data warehouse di SAP prendono il nome di “Key Figures”.

SAP BW fornisce anche altre strutture dati a supporto dell’analisi multidimensionale. Tra queste, una delle più utilizzate è chiamata “Multiprovider”. Questa tipologia di struttura consente di accedere in maniera flessibile e di utilizzare in maniera analitica il contenuto di tutte le strutture dati legate al multiprovider stesso. Ad esempio, in un contesto di reportistica legato alla marginalità di un’azienda, spesso i costi ed i ricavi vengono gestiti utilizzando due infocubi separati. Utilizzando un multiprovider si possono semplificare alcune operazioni che richiedono l’apporto di informazioni provenienti da entrambe le fonti. Multiprovider Marginalità Infocubo Costi Infocubo Ricavi

18

2.5.5 SAP Business Explorer

Le funzionalità di presentazione dei dati su BW sono assolte principalmente dal software chiamato Business Explorer, spesso abbreviato in “Bex”. Il business explorer di SAP è a sua volta costituito da vari componenti dei quali i principali sono i seguenti:

• Bex Query Designer. Si tratta dello strumento mediante il quale è possibile definire delle query sulle strutture presenti all’interno del data warehouse. Ciò viene fatto utilizzando delle semplici funzionalità di drag and drop che consentono di includere nella query dimensioni, attributi e misure e di definire il grado di flessibilità e navigabilità della query stessa una volta eseguita.

• Bex Query Analyzer. Si tratta dello strumento che permette di eseguire le query implementate tramite il Query designer. Lo strumento è definito come un add-on dell’applicazione Microsoft Excel e dunque permette di visualizzare i risultati della query su un foglio di lavoro. Alle funzionalità di navigazione ed elaborazione offerte da Bex Analyzer si vanno dunque ad aggiungere tutte le funzionalità offerte da Excel come ad esempio Grafici e Macro scritte in linguaggio VBA.

• Bex Web Application Designer. Si tratta di uno strumento che permette di generare, a partire da delle query Bex o da delle strutture BW, delle pagine HTML che consentono all’utente di accedere via web alle risorse ed alle funzionalità tipiche della reportistica di BW. All’interno del Web Application Designer è possibile realizzare dei Web templates definiti in maniera modulare tramite un editor visuale che consente di gestire i contenuti includendoli in dei blocchi chiamati Web Items. Ogni Web item è costituito da del codice HTML generato in maniera automatica che l’utente ha la possibilità di personalizzare a proprio piacimento.

19

2.5.6 SAP Business Planning and Consolidation

Il software utilizzato per la realizzazione della parte front-end dell’applicazione è stato SAP Business Planning and Consolidation (BPC) nella sua versione 7.5.

Il software permette di gestire le operazioni di pianificazione finanziaria tramite una serie di strumenti predefiniti che possono essere ampliati mediante l’impiego di componenti tipici di BW o tramite l’utilizzo degli strumenti offerti dalla suite office, su cui BPC si appoggia per fornire i servizi di front-end.

La scelta di utilizzare tale strumento, pensato in realtà per una tipologia di processi maggiormente standardizzata relativa alla pianificazione finanziaria, è dovuta al fatto che esso è largamente impiegato presso l’azienda committente ed è dunque familiare alla maggior parte degli utenti. Inoltre, il fatto che esso sia basato su un add-on di Microsoft Excel rende l’utilizzo più semplice anche da parte degli utenti che non hanno familiarità con BPC. Esso offre inoltre un elevato grado di flessibilità sia nell’implementazione che nell’utilizzo.

BPC, nella sua versione 7.5, prevede la creazione di un “Application set” che identifica un contesto operativo di riferimento come può essere ad esempio la pianificazione finanziaria. All’interno di un Application Set possono essere definite una o più “Application” che vanno a generare su BW, per ognuna di esse, dei data mart contenenti gli schemi dimensionali corrispondenti. Nel caso di un Application set legato alla pianificazione finanziaria si può pensare ad una serie di Applications legate ad esempio a costi operativi, spese per il capitale o ricavi.

Le componenti principali di BPC sono:

• Il software di amministrazione, chiamato Business Planning and Consolidation Administration Client. Tramite il client di amministrazione è possibile gestire una serie di aspetti relativi all’applicazione come ad esempio le autorizzazioni o le anagrafiche delle dimensioni. Questo ultimo aspetto viene gestito in maniera semplice ed intuitiva in quanto anche all’interno del client di amministrazione è disponibile l’interfaccia Excel che consente di aggiornare le anagrafiche dimensionali in maniera semplice ed intuitiva come mostrato nell’esempio in figura 2.3. Si può infatti vedere come l’inserimento di un nuovo elemento

20

all’interno dell’anagrafica avvenga semplicemente scrivendo le informazioni nelle celle excel corrispondenti. Una volta terminati gli inserimenti dei dati relativi alla dimensione è possibile rendere disponibile il contenuto per l’utilizzo per mezzo del comando “process dimension” situato nel pannello a lato dell’area di lavoro excel ed evidenziato in rosso all’interno della figura 2.3.

La gestione delle anagrafiche dimensionali è molto importante su BPC in quanto non è possibile inviare dei dati a sistema se i valori dimensionali sui quali si vuole effettuare l’invio non sono contenuti all’interno delle anagrafiche stesse. Un altro vincolo importate legato a questo aspetto è dovuto al fatto che ogni elemento contenuto nelle dimensioni, identificato da un ID, deve avere un nome univoco non solo all’interno della dimensione ma anche dell’intera applicazione.

Figura 2. 3: Esempio di aggiornamento dell'anagrafica di una dimensione su BPC

• Report BPC: Utilizzano Microsoft Excel come base per poter visualizzare i dati contenuti sui data mart dell’Application set, offrendo anche la possibilità di navigare i dati stessi effettuando delle analisi multidimensionali.

• Input schedules BPC: Si tratta di schede realizzate su base Excel combinando le funzioni standard di BPC con quelle dei fogli di lavoro. Queste tipologie di schede possiedono tutte le caratteristiche dei Report BPC. La peculiarità che li distingue dai Report è quella che gli consente di inviare al data mart associato all’applicazione i dati scritti in delle aree apposite del foglio. Esistono una serie di templates standard, forniti allo scopo di gestire le casistiche tipiche della pianificazione finanziaria ma è possibile costruire delle Input schedules anche da zero, utilizzando le funzioni fornite da BPC in modo da poter realizzare una scheda che incontri pienamente le esigenze di qualsiasi contesto di pianificazione.

21

In questo capitolo verranno illustrate le scelte effettuate in fase di progettazione dell’applicativo e verrà mostrato il modello dati predisposto per poter venire incontro alle esigenze di pianificazione.

La progettazione di un applicativo di pianificazione di questo tipo è diversa da quella che viene effettuata generalmente in un contesto di reportistica standard.

Ciò è dovuto al fatto che, oltre ad essere pensato per uno scopo differente, esistono anche dei limiti tecnici imposti dal tipo di strumento utilizzato per la realizzazione dell’applicativo.

3.1 Caratteristiche di una applicazione di pianificazione su BPC

Lo strumento scelto per la realizzazione dell’applicazione, ovvero SAP BPC nella sua versione 7.5, porta a considerare, in fase di progettazione, una serie di aspetti che verranno ora descritti. Per la scrittura di questo paragrafo sono state consultate le voci [6] e [7] della bibliografia.

BPC utilizzata un data mart, contenuto all’interno del data warehouse aziendale, che permette di immagazzinare ed interrogare i dati relativi alla pianificazione. Il data mart contiene una serie di dimensioni che permettono di identificare il contenuto di un valore scritto a sistema. È possibile scrivere un record sul cubo di pianificazione solamente se i valori legati ad ognuno dei campi relativi a ciascuna dimensione sono contenuti all’interno delle anagrafiche dei valori corrispondenti. Non è possibile inoltre inviare un record che abbia un campo relativo ad una dimensione vuoto. Il data mart non viene creato direttamente sul data warehouse ma viene generato in maniera automatica da BPC una volta definita la struttura dell’applicazione sul client di amministrazione.

Una particolarità importante dei cubi generati da questa versione di BPC è che essi contengono una sola misura, denominata “Signed Data”. Per poter capire che cosa contenga il valore numerico immagazzinato nel campo Signed Data all’interno di un record, viene utilizzata una dimensione denominata “Account”.

22

L’anagrafica della dimensione Account, all’interno del contesto della pianificazione finanziaria, contiene dei codici che identificano delle voci di ricavo o di costo che vanno poi a comporre i piani operativi.

Una applicazione BPC solitamente richiede l’inclusione delle seguenti tipologie di dimensione:

• Account: Contiene i codici delle voci di ricavo o di costo sui quali si ha la necessità di pianificare.

• Category: Contiene i codici di quelli che sono i contesti di pianificazione. Permette dunque di individuare un record relativo alla pianificazione di budget o di un qualsiasi piano operativo.

• Entity: Contiene i codici che indicano tipicamente delle aree aziendali o delle aziende facenti parte di un gruppo.

• Time: Contiene il dettaglio temporale, tipicamente mensile, da utilizzare per associare ad ogni record la propria collocazione di riferimento.

• Currency: Contiene le sigle che identificano le diverse valute utilizzabili all’interno del contesto di applicazione

• TCurrency: Il Type Currency contiene le tipologie di valute utilizzabili all’interno del contesto di pianificazione. Tipicamente si può distinguere tra valuta locale, legata al mercato sul quale si pianifica, e valuta di gruppo. Quest’ultima è la valuta legata alla sede fiscale dell’azienda ed è quella in cui vengono redatti i bilanci.

La versione di BPC utilizzata richiede obbligatoriamente che ogni applicazione contenga almeno una dimensione per ognuna delle tipologie appena elencate. Tali dimensioni possono essere definite anche tramite l’utilizzo di nomi differenti.

23

3.2 Perimetro dimensionale dell’applicazione

Per le esigenze di pianificazione legate all’applicativo sono state estese le dimensioni indicate nel paragrafo precedente con delle altre di tipo custom. Nella tabella 3.1 sono indicate le dimensioni utilizzate all’interno dell’applicazione e la tipologia di dimensione BPC corrispondente. Dimensione Tipologia BPC ACCOUNT Account PLANNING_CYCLE Category SEGMENT Entity TIME Time CURRENCY Currency TCURRENCY TCurrency BRAND Brand MARKET Custom DATASRC Custom VERSION Custom

Tabella 3. 1: Elenco delle dimensioni utilizzate sul cubo di pianificazione

Ognuna delle dimensioni contenute all’interno del data mart possiede una anagrafica che contiene tutti gli ID utilizzabili ed eventuali attributi dimensionali contenenti informazioni supplementari relative ad ognuno degli ID. Nel contesto BPC gli attributi dimensionali vengono chiamati “Proprietà”.

Le anagrafiche delle dimensioni di una applicazione BPC vengono manutenute tramite un client di amministrazione, descritto nel capitolo 5, che consente di inserire nuovi elementi utilizzando una interfaccia intuitiva basata su Microsoft Excel.

Pur essendo consentita la presenza di gerarchie associate alle dimensioni, esse possono essere utilizzate solamente in fase di lettura dei dati. Nel caso di inserimento di valori di pianificazione tramite schede di input o caricamenti tramite programmi, devono essere

24

utilizzati solamente dei codici relativi ai livelli foglia delle eventuali gerarchie legate alle dimensioni che vanno a comporre il contesto di un valore inviato a sistema.

Verrà ora data una descrizione della funzione di ciascuna delle dimensioni utilizzate.

• ACCOUNT: La dimensione Account, nel contesto progettuale analizzato, viene utilizzata per identificare la tipologia di dato contenuta in un record. Ad ogni misura caricata sul cubo tramite il processo di ETL viene associato un account presente in anagrafica. Alcuni degli account presenti in anagrafica non esprimono alcuna misura di interesse in realtà sono stati creati per delle motivazioni tecniche. Ad esempio l’anagrafica contiene degli account che identificano dei flag utilizzati per decidere quali combinazioni di dati visualizzare in alcune delle schede dell’applicativo front-end.

• VERSION: La dimensione Version è di tipo custom e all’interno della sua anagrafica è possibile inserire i codici relativi a una serie di versioni di lavoro differenti. In questo modo è possibile pianificare all’interno di uno stesso ciclo utilizzando approcci differenti come ad esempio stime ottimistiche o pessimistiche. In anagrafica è inclusa anche una versione finale che contiene la pianificazione definitiva relativa ad un singolo ciclo.

• PLANNING_CYCLE: Questa dimensione è della tipologia Category. Essa contiene in anagrafica i codici associati ai vari cicli di pianificazione disponibili all’interno dell’applicazione e consente di identificare a quale ciclo appartiene un record. Oltre ai dati relativi all’Actual, attualmente sono utilizzati solamente i cicli di budget e due cicli di forecast semestrale per ogni anno di pianificazione. Questa dimensione contiene anche una serie di attributi dimensionali che vengono utilizzati principalmente per motivazioni tecniche. Le specifiche di progetto hanno richiesto infatti che durante l’utilizzo dell’applicazione non sia possibile modificare dal front-end, in maniera flessibile, il ciclo di pianificazione e la versione di lavoro utilizzati. Per questo motivo è stato scelto di includere nell’anagrafica di questa dimensione un record tecnico. Il record in questione possiede delle informazioni, contenute in degli attributi, che vanno ad identificare il ciclo di pianificazione e la

25

versione attivi al momento dell’utilizzo dell’applicazione. La figura 3.1 mostra l’interfaccia del pannello di amministrazione che consente l’inserimento dei record in anagrafica. Si può notare la presenza dei diversi ID legati ai cicli di pianificazione corrispondenti e la presenza del record tecnico appena citato, avente come ID “PC_SERVICE”. Esso consente, tramite le informazioni contenute nei suoi attributi, di definire il ciclo di pianificazione e la versione attivi. Le informazioni contenute in questo record vengono lette sia dagli strumenti di back-end che da quelli di front-end per conoscere il ciclo e la versione da utilizzare per contestualizzare i dati al momento dell’esecuzione di operazioni di scrittura o di lettura dei dati.

Figura 3. 1: Anagrafica della dimensione PLANNING_CYCLE

• SEGMENT: La dimensione Segment è definita come dimensione di tipo Entity ed è utilizzata per definire i prodotti oggetto di pianificazione. Questa dimensione contiene in anagrafica tutti i codici relativi ai veicoli sui quali è possibile pianificare. Tutti i codici esistenti sono contenuti in una gerarchia in cui l’unico nodo consente di aggregare tutti i prodotti per visualizzare ad esempio dei valori totali pianificati su un mercato.

• TIME: La dimensione Time è una dimensione standard BPC e la sua anagrafica contiene il dettaglio temporale sui quali è possibile inserire i dati della pianificazione. Questo tipo di dimensione è pensata per i processi di pianificazione legati ai singoli mesi. I mesi costituiscono il livello di dettaglio massimo di una

26

gerarchia che comprende anche i trimestri e gli anni. Tuttavia per il processo analizzato non vengono utilizzati i dettagli mensili ma la pianificazione avviene sull’intero anno; vengono dunque utilizzati dei codici fittizi nella forma “ANNO.DUMMY”.

• TCURRENCY: La dimensione è di tipo standard e contiene i codici relativi alle tipologie di valute utilizzabili, come indicato nel paragrafo precedente. All’interno del contesto del progetto realizzato viene utilizzata solamente la valuta di gruppo. In ogni record scritto a sistema viene dunque sempre inserito il codice legato a questa tipologia di valuta ovvero “T_RPT”.

• CURRENCY: La dimensione Currency è di tipo standard e contiene i codici relativi alle valute associate ai mercati su cui opera l’azienda. Sebbene in anagrafica siano contenute tutte le valute, al momento l’unica valuta utilizzata è quella di gruppo ovvero l’Euro.

• BRAND: La dimensione Brand contiene in anagrafica cinque diversi codici che identificano i diversi brand tramite i quali l’azienda commercializza i propri prodotti sul mercato. Questa dimensione viene trattata in maniera separata da quella relativa ai veicoli. Non sarebbe strano infatti poter ipotizzare l’inclusione del brand come nodo gerarchico da porre ad un alto livello all’interno di una gerarchia legata ai prodotti. Tuttavia all’interno di tutti i processi aziendali il brand non rientra nella gerarchia dei prodotti per una ragione precisa. Questa ragione va ricercata nel fatto che l’azienda commercializza alcuni veicoli associandoli a brand diversi a seconda del mercato di destinazione. Ciò è dovuto a motivazioni di tipo commerciale come ad esempio il diverso livello di forza di un marchio all’interno dei vari mercati in cui l’azienda vende i propri prodotti.

• MARKET: La dimensione contiene in anagrafica i codici di tutti i mercati su cui opera l’azienda.

• DATASRC: La dimensione Data Source viene utilizzata comunemente nei contesti di pianificazione su BPC e la sua anagrafica contiene dei codici che vanno ad

27

identificare l’origine dei record inseriti a sistema. Si distingue tra dati caricati tramite logiche di back-end e dati inseriti a mano dalle schede di front-end.

3.3 Definizione del livello di dettaglio della pianificazione

I dati raccolti dalle diverse fonti di approvvigionamento dell’applicazione presentano, nella maggior parte dei casi, livelli di granularità molto bassi.

Nel caso dei processi presi in esame, il livello di dettaglio massimo della pianificazione è dato dalla terna Brand/Mercato/Segmento produttivo, il tutto all’interno di un singolo anno di pianificazione.

All’interno di ogni ciclo di pianificazione dunque, nell’intervallo temporale di riferimento, ovvero l’anno, vengono elaborati gli output per ognuno dei segmenti produttivi associati ad ognuno dei Brand presenti in un dato mercato.

Le informazioni vengono dunque aggregate in fase di caricamento in modo da contenere il dettaglio utilizzato nel presente contesto.

Per quanto riguarda il Brand, come già affermato nel paragrafo precedente, la pianificazione è ammessa su cinque diverse occorrenze che identificano appunto i cinque brand tramite i quali l’azienda commercializza i propri veicoli.

Per quanto riguarda i mercati invece occorre premettere che l’azienda utilizza, in altri ambiti, dei raggruppamenti gerarchici su più livelli. Tuttavia, all’interno del contesto relativo al progetto realizzato, è stato scelto di pianificare e visualizzare i risultati solamente in relazione ai singoli mercati, senza l’utilizzo di alcuna gerarchia.

Per quello che riguarda il segmento produttivo citato in precedenza, occorre fornire una descrizione più approfondita di come sia gestita l’organizzazione dei prodotti all’interno del contesto aziendale.

Ad ognuno dei prodotti realizzati dall’azienda viene associato un codice. I codici dei veicoli prodotti sono inclusi in una serie di gerarchie, che possono differire a seconda del contesto operativo.

La gerarchia più utilizzata in azienda, chiamata spesso “gerarchia standard” per questa ragione, prevede sette livelli di dettaglio più un ulteriore livello che identifica il colore della verniciatura del veicolo. Quest’ultimo livello viene tuttavia utilizzato solamente in

28

contesti che richiedono un livello di dettaglio molto elevato come ad esempio quello legato al processo di pianificazione della produzione.

La gerarchia in questione è descritta nella tabella 3.2.

Livello gerarchico Descrizione nodo 1 Tipologia prodotto 2 Tipologia veicolo 3 Segmento Veicolo 4 Famiglia veicolo 5 Modello veicolo

6 Veicolo Scolorato con allestimento 7 Scolorato con allestimento per mercato 8 Veicolo colorato

Tabella 3. 2: Gerarchia standard dei prodotti

Si può notare come la gerarchia parta da una prima suddivisione per tipologia di prodotto: si distingue tra veicoli, ricambi ed accessori.

Il secondo livello divide i veicoli per tipologia di impiego: veicoli commerciali oppure veicoli per privati.

Il livello 3 della gerarchia suddivide i veicoli per fasce di cilindrata del motore. Il livello 4 identifica la famiglia produttiva del veicolo sulla base di alcune caratteristiche tecniche da esso possedute.

Il livello 5 definisce quelli che sono i modelli veri e propri tramite i quali i veicoli vengono commercializzati ed identificati dalla clientela sul mercato.

I codici di livello 6 e di livello 7 definiscono invece il livello di dettaglio massimo degli allestimenti associati a ciascun modello.

Il livello 7 in particolare comprende dei codici che specificano, per ogni allestimento di livello 6, anche il mercato di destinazione del veicolo. Infatti lo stesso mezzo, destinato a mercati diversi, può presentare una serie di differenze legate ad esempio ai diversi sensi

29

di marcia adottati in paesi diversi. A seconda del senso di marcia infatti, due veicoli possono avere caratteristiche costruttive differenti pur avendo lo stesso allestimento.

Un esempio non banale e al tempo stesso significativo può essere legato all’orientamento dei fari. Normalmente i fari di un qualsiasi veicolo stradale hanno un orientamento che consente di illuminare con un raggio più ampio il lato della carreggiata rispetto al lato del senso di marcia opposto. In questo modo si evita di disturbare eccessivamente gli altri conducenti e si riesce ad avere una migliore visuale su quelli che possono essere potenziali pericoli provenienti dal lato della carreggiata come pedoni o animali. I veicoli, pur montando la stessa tipologia di fanali, a seconda del mercato di vendita devono dunque tenere conto anche di questa piccola differenza e montare dei fanali orientati in maniera corretta.

Nel contesto aziendale i codici di livello 7 vengono generalmente identificati utilizzando il termine “Scolorato”, ovvero il massimo livello di dettaglio della definizione di un prodotto ad esclusione del colore della verniciatura.

I codici di livello 8, come già anticipato, definiscono anche il dettaglio del colore della verniciatura ma sono completamente out of scope per ciò che riguarda la descrizione dei processi trattati in questo progetto. Infatti tutti i dati di input reperiti dai sistemi centrali, come ad esempio i volumi di vendita pianificati, presentano un livello di dettaglio del prodotto che si attesta sul livello 7 della gerarchia appena illustrata. La pianificazione delle garanzie avviene invece al livello 3 della gerarchia ed in alcuni casi al livello 5; si parla infatti di pianificazione per Segmenti e Modelli ed è questo il motivo per cui la dimensione relativa ai prodotti prende il nome di Segment. La pianificazione relativa ai modelli è legata a delle particolari eccezioni che verranno descritte nel capitolo successivo. Durante il processo di ETL i dati, reperiti con bassa granularità dalle strutture sorgenti, dovranno dunque essere aggregati tenendo conto anche delle eccezioni e delle regole definite in fase di setup dell’applicazione che verranno descritte nel capitolo successivo.

3.4 Schema logico dell’applicazione

Osservando la figura 3.2 è possibile vedere lo schema logico del data mart utilizzato dall’applicazione BPC. Si può immediatamente notare come la struttura sia quella di un

30

classico star schema e come le dimensioni posseggano pochi attributi dimensionali. Ciò è dovuto al fatto che lo strumento realizzato non è destinato ad un utilizzo legato alla reportistica. Vengono dunque utilizzati principalmente gli ID dei vari elementi presenti in anagrafica e le loro descrizioni per avere una migliore leggibilità all’interno delle schede utilizzate all’interno dell’applicazione front-end.

Si può vedere come la dimensione Time contenga di default anche degli attributi che consentono di ottenere le informazioni relative al mese, all’anno e al trimestre corrispondenti a ciascun Time ID.

La dimensione Planning Cycle contiene invece una serie di attributi che consentono di ottenere alcune informazioni legate al ciclo di pianificazione e alla versione attivi, come illustrato nel paragrafo precedente.

Al centro della figura si può osservare la tabella dei fatti relativa al progetto WAP, con l’unica misura utilizzata all’interno del data mart.

Brand ID Description Brand Currency ID Description Currency Account Account ID Description Planning Cycle ID Description Year Previous Year Active Planning Cycle Active Version Previous Planning Cycle

Planning Cycle Time ID Description Month Quarter Year Time Segment ID Description Segment Version ID Description Version Data Source ID Description Data Source Type Currency ID Description TCurrency Market ID Description Market WAP Signed Data

31

In questo capitolo verrà illustrata la procedura definita al fine di estrarre i dati necessari all’utilizzo dell’applicazione. Verranno inoltre descritte le strutture dati e gli strumenti utilizzati per portare a compimento tali operazioni.

4.1 Definizione del processo di ETL

Una volta definita la struttura del cubo che andrà a contenere i dati di pianificazione si è reso necessario predisporre un processo di ETL (Extract, Transform and Load). L’acronimo “ETL” sta ad indicare proprio le tre fasi principali di cui il processo è composto ovvero estrazione, trasformazione e caricamento, [2]. Questo processo consente di caricare sul data warehouse i dati prelevati da basi di dati transazionali dopo averli opportunamente manipolati al fine di adattarli alle esigenze di reporting.

• Extract: In questa fase i dati vengono estratti, tipicamente da database transazionali, e resi disponibili per l’elaborazione.

• Transform: Questa fase può comprendere sia la trasformazione dei dati estratti che la pulizia degli stessi. Per “pulizia” si intende il processo mediante il quale vengono analizzati i dati al fine di eliminare eventuali errori di rappresentazione o di completare eventuali informazioni mancanti. La trasformazione può essere invece di due tipi:

1. Sintattica: In questo caso vengono armonizzati dei dati aventi lo stesso significato semantico ma espressi in maniera diversa; si pensi ad esempio ad un valore riportato con due unità di misura diverse o ad un attributo di genere espresso come (M,F) o come (Maschio, Femmina).

2. Semantica: In questo caso i dati nella sorgente possono avere diversi significati; se per esempio ci trovasse di fronte a sorgenti contenenti sia dati

32

mensili che dati giornalieri occorrerebbe armonizzarli per poterli trattare in maniera uniforme sul data warehouse.

• Load: I dati trasformati ed armonizzati vengono caricati sul data warehouse.

A differenza di un processo classico di ETL, nell’ambito del progetto realizzato, i dati non vengono reperiti da basi di dati transazionali ma, come verrà illustrato nel proseguo del capitolo, quasi totalmente da strutture già presenti all’interno del data warehouse aziendale.

Nel contesto progettuale l’obiettivo del processo di ETL non è fornire una collezione di dati navigabili da strumenti di reportistica bensì il caricamento dei dati di partenza che permettano ai pianificatori di poter redigere i propri piani operativi, utilizzando il cubo non solo come sorgente ma anche come destinazione delle misure di riferimento.

4.2 Struttura del modello di approvvigionamento dei dati

L’applicazione realizzata ha richiesto l’approvvigionamento dei dati di partenza da diverse sorgenti. Il modello dati realizzato è costituito da una serie di strutture di staging, organizzate su livelli differenti, destinate a contenere le diverse tipologie di variabili utilizzate per l’inizializzazione dell’applicazione.

Il modello realizzato è rappresentato nella figura 4.1. Per ragioni di leggibilità le strutture di staging sono identificate in figura tramite i loro nomi tecnici definiti a sistema. Le rispettive associazioni funzionali e la relativa descrizione dei dati contenuti al loro interno verrà data nel seguito del paragrafo.

Osservando lo strato di estrazione presente alla base del modello, si può vedere come esso si interfacci con altre strutture dati già presenti all’interno dell’azienda e legate ad altri contesti applicativi.

Il modello dati qui illustrato può essere idealmente diviso in due parti: nella parte sinistra del modello sono presenti i flussi che eseguono il caricamento delle componenti relative ai costi per veicolo; nella parte destra si possono invece osservare i quattro flussi relativi al caricamento dei volumi di vendita pianificati e consuntivi. Queste due sezioni saranno trattate in maniera separata nei paragrafi successivi.

33

Warranties Accrual Planning

ZO_WAP04 ZO_WAP01 ZO_WAP21 ZO_WAP22 ZO_WAP23 ZO_WAP31 ZO_WAP32

ZO_WA_01A ZO_WA_21A ZO_WA_22A ZO_WA_23A ZO_WA_31A ZO_WA_32A ZO_WA_04A

Bex query CV Data delibera APD Bex query CV Data vendita APD Bex query Costi per data effettuazione APD

Bex Query Distribuzione costi per data effettuazione APD Bex query CV Data vendita APD Bex query CV Data vendita APD Bex query Costi per data effettuazione APD

ZO_WAP05 ZO_WAP06 ZO_WAP07

Data Source ZO_WAP08 File CSV BFP Standard margin Reporting commerciale Area Sales Sellout

Figura 4. 1: Modello approvvigionamento dati dell'applicazione

Verranno ora illustrate le tipologie delle strutture dati rappresentate in figura. Per la scrittura dei punti elencati nel seguito sono stati consultati i testi alle voci [3] e [4] e i portali ufficiali alle voci [6] e [7] della bibliografia.

• Query BEx: Una query BEx è una query costruita tramite lo strumento BEx Query designer. Al suo interno è possibile indicare le dimensioni e le misure da rappresentare, l’ordine di visualizzazione dei dati, nonché impostare le varie opzioni di navigabilità dei report. È inoltre possibile specificare delle variabili che consentono, mediante un prompt visualizzato al momento dell’esecuzione, di parametrizzare l’estrazione dei dati in base ai valori inseriti. Normalmente le query vengono eseguite tramite appositi strumenti front-end di analisi ma nel caso analizzato vengono utilizzate solamente come sorgente dati per il modello.

• Variante query BEx: Una variante di una query BEx è costituita da una prevalorizzazione delle variabili definite all’interno della query stessa. Per ogni query è possibile specificare una serie di varianti che contengono un insieme di

34

valori relativi alle variabili create al fine di parametrizzare l’estrazione dei dati da parte della query stessa.

• Infocubo real time: In cima al modello è presente quella che è la destinazione del processo di ETL, ovvero il data mart utilizzato per la gestione dei dati elaborati in fase di pianificazione. I data mart su SAP sono comunemente chiamati “infocubi”. Gli infocubi standard sono ottimizzati in maniera tale che vengano velocizzate le operazioni di lettura a discapito di quelle di scrittura; ciò è utile nel caso di utilizzo degli stessi da parte di strumenti di reportistica ma può creare dei problemi in presenza di strumenti di pianificazione. Le applicazioni BPC utilizzano una tipologia particolare di infocubi detta real time. Un infocubo real time rende possibile la lettura e la scrittura simultanea di dati da parte di utenti diversi. Proprio questa peculiarità lo rende particolarmente adatto per l’utilizzo all’interno di contesti di pianificazione in cui i vari utenti possono avere la necessità di scrivere i dati di propria competenza in maniera simultanea sul cubo di pianificazione. Gli infocubi rappresentati nella parte in basso a destra della figura sono invece di tipo standard, e vengono utilizzati per la reportistica di altre aree aziendali.

• Data store object (DSO): Le strutture di staging dedicate all’applicazione, rappresentate in figura da dei cilindri azzurri, sono state implementate utilizzando dei Data store objects (convenzionalmente identificati tramite l’acronimo DSO). Un DSO è una struttura dati sulla quale è possibile eseguire delle query bex e specificare dei campi chiave. Nella sua versione standard consente di immagazzinare i dati all’interno di due tabelle distinte: una tabella contiene i dati attivi, che sono disponibili per il reporting; la seconda tabella contiene i record pervenuti per mezzo di trasferimenti dati ma che non sono ancora stati inclusi nel processo di attivazione. Eseguendo il comando di attivazione dei dati, i record selezionati vengono eliminati dalla tabella dei dati appena caricati e vengono inclusi nella tabella dei dati attivi. I DSO presenti nel livello superiore illustrato in figura sono di questa tipologia.

Una seconda tipologia di DSO, utilizzata nel livello inferiore delle strutture illustrate in figura, è detta Data store object for direct update. I DSO di questa