Tesi Sgrignuoli

U NIVERSITÀ P OLITECNICA DELLE M ARCHE
FACOLTÀ DI I NGEGNERIA
Dipartimento di Ingegneria dell’Informazione
Corso di Laurea Magistrale in Ingegneria Informatica e dell’Automazione
T ESI DI L AUREA
Attività di migrazione e conversione dall’attuale sistema ERP SAP

ECC al nuovo sistema SAP S/4HANA per conto di una
multinazionale italiana
Migration and porting activities from the current ERP SAP ECC to
the new SAP S/4HANA for an italian multinational company
Relatore Candidato
Prof. Domenico Ursino Piero Sgrignuoli
A NNO A CCADEMICO 2021-2022

i
Abstract
Negli ultimi anni sempre più aziende si stanno imbarcando nella complessa e sfidante
migrazione dal sistema ERP SAP ECC al nuovo sistema SAP S/4HANA. La motivazione
principale risiede nell’annuncio, da parte della stessa SAP, della fine del supporto a SAP ECC.
Lo scopo della presente tesi, dunque, è quello di analizzare un reale progetto di migrazione a
SAP S/4HANA intrapreso da una nota multinazionale italiana.
Nello specifico, vengono presentati i vantaggi, le sfide e i rischi associati al processo di
migrazione e viene analizzata la strategia adottata dall’azienda per far fronte ad un progetto di
questa portata. Tale progetto, infatti, impatta ogni area dell’azienda e comporta un notevole
effort da parte di tutte le persone coinvolte. Inoltre, rende necessario un re-engineering
di alcuni dei processi aziendali, nonché modifiche, anche sostanziali, alle infrastrutture
hardware per la gestione dei dati.
Keyword: SAP ECC, SAP S/4HANA, ERP Systems, Digital Transformation, In-Memory
Databases, New Generation Databases, NoSQL Databases.
Indice
Introduzione 1
1 I database NoSQL 3
1.1 Dal modello relazionale al movimento NoSQL . . . . . . . . . . . . . . . . . . 3
1.1.1 Breve storia del modello relazionale . . . . . . . . . . . . . . . . . . . . 3
1.1.2 La nascita del movimento NoSQL . . . . . . . . . . . . . . . . . . . . . 4
1.2 NoSQL database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Conseguenze della replicazione del dato . . . . . . . . . . . . . . . . . 8
1.2.2 Classificazione dei database NoSQL . . . . . . . . . . . . . . . . . . . . 10
2 In-memory database e SAP HANA 14

2.1 Overview dei database in-memory . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 Caratteristiche dei database in-memory . . . . . . . . . . . . . . . . . . 15
2.1.2 Differenze tra i sistemi tradizionali e sistemi in-memory . . . . . . . . 17
2.1.3 Esempi di database in-memory . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Breve panoramica delle soluzioni SAP . . . . . . . . . . . . . . . . . . . 22
2.2.2 Overview di SAP HANA . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Panoramica generale del processo di migrazione 25

3.1 Situazione aziendale attuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Vantaggi della migrazione . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 Sfide delle migrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.3 Motivazioni della migrazione . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Processo di migrazione a SAP S/4HANA . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Best Practices SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Metodologia SAP Activate . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.3 Custom Code Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Strategia di migrazione adottata . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1 Struttura del team di progetto . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Tipologie di approccio alla migrazione . . . . . . . . . . . . . . . . . . . 39
3.3.3 Tools Renovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ii
INDICE iii
4 Implementazione del tool per la gestione delle tolleranze 41

4.1 Analisi dei requisiti di business . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Introduzione al processo aziendale . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Traduzione dei requisiti di business in requisiti tecnici . . . . . . . . . 43
4.2 Implementazione dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1 ZMRPE_GP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2 ZUPD_CONTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Migrazione del tool Price List Management 51

5.1 Analisi dei requisiti di business . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1 Introduzione al processo aziendale . . . . . . . . . . . . . . . . . . . . . 51
5.1.2 Caratteristiche attuali del tool . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Implementazione dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1 ZPLM: Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.2 ZPLM: New Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Discussione in merito al lavoro svolto 62

6.1 Lezioni apprese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Generalizzazione dell’approccio proposto . . . . . . . . . . . . . . . . . . . . . 64
7 Conclusioni 65
Bibliografia 67
Ringraziamenti 70
Elenco delle figure
1.1 Esempio di schema logico relazionale . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Una comparazione tra dati strutturati e dati non strutturati . . . . . . . . . . . 5
1.3 Evoluzione dell’interesse nel tempo per le soluzioni NoSQL e RDBMS . . . . 6
1.4 Schema riassuntivo della replicazione in MongoDB . . . . . . . . . . . . . . . 8
1.5 Diagramma riassuntivo del CAP Theorem . . . . . . . . . . . . . . . . . . . . . 9
1.6 Rappresentazione grafica delle quattro macro-categorie del NoSQL . . . . . . 11
1.7 Una schematizzazione del modello chiave-valore . . . . . . . . . . . . . . . . . 11
1.8 Una schematizzazione del modello column-oriented . . . . . . . . . . . . . . . 12
1.9 Una schematizzazione del modello basato su documenti . . . . . . . . . . . . 12
1.10 Una schematizzazione del modello basato su grafo . . . . . . . . . . . . . . . . 13
2.1 Differenza tra i tempi di accesso tipici dei vari componenti . . . . . . . . . . . 14

2.2 Schematizzazione del pipelined parallelism e del data parallelism . . . . . . . 16
2.5 Schema dell’architettura di TimesTen . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Schema dell’architettura di Redis . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Schema della gestione della memoria da parte di SAP HANA . . . . . . . . . 23
3.1 Panoramica delle aree impattate da SAP S/4HANA . . . . . . . . . . . . . . . 28

3.2 Panoramica delle motivazioni per cui le aziende evitano la transizione a SAP
S/4HANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Interfaccia della libreria delle SAP Best Practices . . . . . . . . . . . . . . . . . 32
3.4 Aree toccate dalla raccolta di best practice per SAP S/4HANA . . . . . . . . . 33
3.5 Dettaglio della libreria delle best practice per SAP S/4HANA . . . . . . . . . 33
3.6 Diagramma di flusso della metodologia SAP Activate . . . . . . . . . . . . . . 34
3.7 Schematizzazione grafica della Custom Code Remediation . . . . . . . . . . . 36
3.8 Diagramma di flusso della Custom Code Remediation . . . . . . . . . . . . . 37
3.9 Rappresentazione dei pillar aziendali . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 Roadmap della prima fase di migrazione . . . . . . . . . . . . . . . . . . . . . 38
3.11 Modello di Governance del progetto . . . . . . . . . . . . . . . . . . . . . . . . 39
3.12 Modello di Governance del progetto . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Videata di un contratto SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Videata di un contratto SAP: dettaglio di una posizione . . . . . . . . . . . . . 42
iv
ELENCO DELLE FIGURE v
4.3 Diagramma del processo aziendale di riferimento . . . . . . . . . . . . . . . . 43

4.4 Videata di un gruppo prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Diagramma di flusso per il tool ZMRPE_GP . . . . . . . . . . . . . . . . . . . . 44
4.6 Schermata di selezione per ZMRPE_GP . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 Schermata principale di ZMRPE_GP . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.8 Dettaglio della ALV per l’inserimento dati . . . . . . . . . . . . . . . . . . . . . 47
4.9 Schermata generata dal pulsante “Aggiungi eccezione” . . . . . . . . . . . . . 47
4.10 Schermate generate dai pulsanti “Mostra mat. eccezione” e “Rimuovi eccezione” 47
5.1 Esempio di un contratto in SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 Diagramma del flusso elaborativo dell’MRP . . . . . . . . . . . . . . . . . . . . 52
5.3 Diagramma del processo acquisti . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Esempio dell’interfaccia di SAP SRM . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Gestione delle famiglie di materiali in SRM . . . . . . . . . . . . . . . . . . . . 55
5.6 Gestione degli item del listino in SRM . . . . . . . . . . . . . . . . . . . . . . . 55
5.7 Processo AS IS del tool PLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.8 Processo TO BE del tool PLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9 Esempio del template adottato per l’upload tramite file Excel . . . . . . . . . . 57
5.10 Schermata principale di ZPLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Schermata di creazione di un nuovo listino . . . . . . . . . . . . . . . . . . . . 58
5.12 Schermata di modifica di un listino . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.13 Schermata per l’invio del listino in approvazione . . . . . . . . . . . . . . . . . 59
5.14 Schermata pop-up per la visualizzazione dei messaggi di errore . . . . . . . . 60
5.15 Diverse schermate della web app di approvazione . . . . . . . . . . . . . . . . 60
Elenco delle tabelle
2.1 Differenze tra query OLTP e OLAP . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Confronto dei tempi di esecuzione nel caso di organizzazione per righe e di
organizzazione per colonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
vi
Elenco dei listati
1.1 Un esempio di file JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Definizione della schermata di selezione . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Query di selezione sul database SAP . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Salvataggio delle modifiche sul database SAP . . . . . . . . . . . . . . . . . . . 48
4.4 Query per la selezione dei gruppi prodotto recentemente modificati . . . . . . 49
4.5 Query per la selezione delle posizioni di contratto da aggiornare . . . . . . . . 49
vii
Introduzione
Nel mercato competitivo odierno i sistemi di Enterprise Resource Planning (ERP) sono
diventati la linfa vitale per i moderni modelli di business delle aziende. I sistemi ERP rappre-
sentano un insieme di applicazioni che contengono molteplici moduli software integrati per
la pianificazione delle risorse aziendali. Essi, inoltre, permettono di integrare la gestione dei
processi di business e la condivisione delle informazioni in un’unica soluzione, sia all’interno
dell’azienda che con i suoi partner. La capacità di elaborare le informazioni risulta cruciale per
il decision making aziendale e per operare in maniera efficace. A questo riguardo, le aziende
spesso ricorrono a soluzioni ERP che supportano workflow di analisi dei dati e intelligenza
artificiale, delle quali SAP rappresenta la società leader del settore. Essa, difatti, possiede un
altissimo market share ed i suoi tool sono utilizzati da oltre 22 mila aziende globalmente.
Negli anni SAP si è evoluto molto, presentando ai propri clienti delle soluzioni sempre
nuove per far fronte alle necessità di business moderne; un notevole punto di svolta è stato
il rilascio della suite ERP SAP S/4HANA nel 2015. Tale suite basa la propria architettura
sul moderno DBMS HANA che sfrutta la tecnologia in-memory per garantire performance
irraggiungibili dai tradizionali DBMS relazionali. Inoltre, integrando al proprio interno
moduli per la Data Analytics, il Machine Learning e la Business Intelligence si propone come una
soluzione all-in-one per tutti i business need di un’organizzazione.
Nonostante i numerosi vantaggi apportati dalla nuova versione del famoso ERP, agli inizi
del 2019 soltanto un modesto numero di clienti aveva già effettuato l’upgrade a S/4HANA.
SAP, a questo punto, incurante delle numerose critiche ricevute, annunciò comunque di voler
terminare il supporto alla versione attualmente più usata del software, ovvero SAP ERP
Central Component (SAP ECC) entro il 2025. Tale annuncio spinse moltissime aziende, seppur
controvoglia, ad intraprendere la migrazione al nuovo sistema. Tuttavia, l’implementazione
di un software come SAP S/4HANA, che presenta sostanziali differenze architetturali rispetto
alla precedente versione, è un’operazione complessa, che comporta notevoli cambiamenti
all’interno di un’organizzazione. In base alle specifiche esigenze aziendali, l’intera operazione
di migrazione può richiedere diversi anni e impattare praticamente ogni persona all’interno
dell’organizzazione.
Pertanto, per raggiungere gli obiettivi organizzativi in termini di budget, qualità del
prodotto e tempo, è importante che il processo di migrazione sia pianificato ed eseguito
utilizzando una metodologia solida e comprovata. Oltre ai requisiti tecnici associati alla
configurazione e al funzionamento del sistema S/4HANA, è necessario redigere un accurato
piano di progetto, ponendo le dovute attenzioni su questioni come la governance di progetto,
l’allineamento strategico dei business need, il re-engineering dei processi, la gestione del
cambiamento e la formazione delle risorse umane.
1
2
Lo scopo della presente tesi è quello di descrivere la partecipazione fattiva ad un reale

progetto di migrazione a SAP S/4HANA intrapreso da una nota multinazionale italiana.
Inizialmente, saranno introdotte le tecnologie e le metodologie di interesse, tra cui i DBMS
NoSQL, le tecnologie relative all’in-memory computing e alcuni dettagli tecnici in merito al
DBMS HANA. Si passerà, poi, alla discussione dell’effettivo processo di migrazione in merito
al quale verranno analizzate le sfide e i rischi che esso comporta, gli aspetti critici su cui porre
maggior attenzione e la metodologia di migrazione adottata.
Nello specifico, verrà analizzata la metodologia SAP Activate, utilizzata dall’azienda
per portare avanti il progetto, discutendo in dettaglio le varie fasi progettuali di cui essa
si compone. Verrà esposta, inoltre, la struttura aziendale, evidenziandone i vari pillar e
l’impatto del progetto su di essi. Successivamente, saranno evidenziate delle aree di intervento
aggiuntive, specifiche dell’azienda in esame, che si integrano alla roadmap di progetto
consigliata da SAP.
Concludendo, verranno analizzate con maggior dettaglio due delle attività di nostra
competenza nell’ambito del progetto. La prima riguarda l’implementazione di un nuovo tool
aziendale a supporto degli utenti, mentre la seconda segue il processo di porting tecnologico
di un tool preesistente. In particolare, verrà dapprima esposta l’analisi dei requisiti effettuata,
in seguito, saranno analizzati i relativi dettagli implementativi per entrambi i tool.
La tesi in oggetto è composta da sette capitoli, strutturati come di seguito specificato:
• Nel Capitolo 1 verrà brevemente introdotto il modello relazionale, a seguire, si parlerà

del movimento NoSQL e dei database di nuova generazione. Per questi ultimi verranno
evidenziate, le varie tipologie disponibili oggi sul mercato.
• Nel Capitolo 2 verrà introdotta la tecnologia in-memory, l’in-memory computing e alcuni

dei database che fanno uso di tale tecnologia. Sarà, poi, posta maggior attenzione al
DBMS HANA, analizzandone il funzionamento.
• Nel Capitolo 3 saranno inizialmente introdotti i vantaggi, le sfide, i rischi e le motiva-

zioni della migrazione a SAP S/4HANA. Si passerà, poi, a discutere della metodolo-
gia generale del processo di migrazione; infine, sarà esposta la struttura aziendale e
l’effettiva strategia di progetto adottata.
• Nel Capitolo 4 verrà analizzata l’implementazione di un tool per la gestione delle

tolleranze di magazzino, studiandone i requisiti di business, i requisiti tecnici e, infine,
esponendone l’effettiva implementazione.
• Nel Capitolo 5 si seguirà, invece, il processo di porting tecnologico e di re-engineering

di un tool preesistente per la gestione dei listini. Verranno, inoltre, discusse l’analisi
dei requisiti e la successiva implementazione in collaborazione con un’azienda di
consulenza esterna.
• Nel Capitolo 6 verrà proposta una discussione in merito al lavoro svolto e verranno
evidenziate alcune lezioni apprese nell’ambito del progetto di migrazione.
• Nel Capitolo 7, infine, verranno tratte le conclusioni in merito al lavoro svolto e verranno
esposti alcuni sviluppi futuri.
CAPITOLO 1
I database NoSQL
In questo primo capitolo analizzeremo brevemente le motivazioni che hanno portato alla nascita del
movimento NoSQL, per poi proseguire con l’introduzione dei database di nuova generazione dei quali
verranno prima descritte le caratteristiche tecnologiche. Infine, i DBMS NoSQL verranno categorizzati per
tipologia.
1.1 Dal modello relazionale al movimento NoSQL

Comprendere la storia dei database “classici”, ovvero basati su modello relazionale, risulta
fondamentale per capire come si è arrivati negli anni al movimento NoSQL e alla nascita
dei database di nuova generazione. Il modello relazionale è un modello che ha dominato il
mercato dei DBMS a lungo. Tuttavia, con il passare del tempo si è assistito al nascere di nuove
esigenze per quanto riguarda la manipolazione, la conservazione e la condivisione dei dati.
Per rispondere al meglio a questi nuovi requisiti, hanno pian piano cominciato a prendere
piede nuove tecnologie per le basi di dati, ovvero i cosiddetti New Generation Database.
1.1.1 Breve storia del modello relazionale

Il modello relazionale è un modello logico di rappresentazione e strutturazione dei dati
usato da moltissimi DBMS (Database Management System). Venne proposto da Edgar F. Codd
nel 1970 al fine di standardizzare e semplificare l’interrogazione delle basi di dati e favorire
l’indipendenza dei dati.
L’assunto fondamentale del modello è che tutti i dati sono rappresentati come relazioni e
manipolati tramite gli operatori dell’algebra relazionale. Progettare un database secondo il
modello relazionale permette di creare una rappresentazione logica e consistente dell’informa-
zione. Questa consistenza viene garantita dall’inserimento di vincoli in fase di progettazione;
l’insieme di questi ultimi costituisce lo schema logico della base di dati.
L’indipendenza del dato fu la caratteristica più innovativa apportata dal modello re-
lazionale. Prima dell’avvento di quest’ultimo, intorno al 1981, i vari DBMS sul mercato
utilizzavano per lo più modelli di rappresentazione del dato proprietari. Tali modelli spesso
si basavano su architetture reticolari o gerarchiche, oppure, in percentuale minore, su architet-
ture object-oriented. Ciò rende difficoltoso, o del tutto impossibile, condividere dati tra diverse
sorgenti o riutilizzare l’architettura di un database per un caso d’uso diverso dall’originale.
Avere uno schema logico delle base di dati, che sia indipendente dalla sua rappresentazione
3
1.1 − Dal modello relazionale al movimento NoSQL 4
fisica sul disco fisso, permette di definire una metodologia di progettazione con un alto livello
di astrazione.
Come si può vedere in Figura 1.1, il modello logico relazionale è semplicemente una
rappresentazione a più basso livello del modello entità/relazione. In esso, le entità sono
rappresentate come dei rettangoli e le relazioni come collegamenti tra entità. Il modello
non fornisce alcuna indicazione su come tali informazioni debbano essere rappresentate in
memoria o su come un DBMS deve operare per manipolare i dati.
Figura 1.1: Esempio di schema logico relazionale
Lo schema definisce delle entità, ovvero oggetti del mondo fisico e, di questi oggetti,
definisce degli attributi che li caratterizzano. Le entità sono, poi, collegate tra loro da relazioni,
che evidenziano dei legami logici. In Figura 1.1, ad esempio, è possibile vedere come l’entità
Rack sia collegata all’entità Server con una relantionship uno a molti. Questo, nel linguaggio
naturale, vuol dire che per ogni oggetto Rack possono esserci uno o più oggetti di tipo Server
Il modello relazionale fu una vera e propria rivoluzione nell’ambito delle basi di dati e
diventò in breve tempo il modello logico predominante dei DBMS dell’epoca. A conferma
della sua robustezza e utilità, tutt’oggi questo modello risulta largamente utilizzato, oltre che
nei sistemi legacy, anche per nuove implementazioni di basi di dati.
1.1.2 La nascita del movimento NoSQL

La nascita del movimento NoSQL non è un qualcosa di istantaneo o le cui cause possono
essere facilmente definite. Piuttosto, è stata in parte spinta dall’evoluzione delle esigenze
di conservazione ed elaborazione dei dati e in parte dal normale progresso tecnologico del
settore informatico.
Difatti, se un tempo le risorse computazionali erano severamente limitate e si cercava
di conservare solo i dati essenziali, oggi le capacità elaborative sono esponenzialmente
maggiori con sistemi di calcolo parallelo che riescono ad operare su più porzioni di un
singolo database contemporaneamente. I classici database relazionali furono progettati per le
architetture mainframe dell’epoca e, seppur tutt’oggi validissimi, presentano delle complessità
aggiuntive quando si cerca di usarli per tipologie di dati non strutturati (es. immagini, video
e audio), oppure di farli lavorare all’interno delle moderne architetture di calcolo distribuito.
Dati strutturati e dati non strutturati

Nell’ultimo decennio si è assistito ad un aumento sempre crescente e ad una condivisione
sempre più diffusa dei dati sul web. Nei vari social network, nei siti di video sharing, così
come nei siti web “tradizionali”, l’utilizzo del dato è diventato di centrale importanza. Se
prima i dati strutturati erano i più comuni, recentemente è aumentata a dismisura la presenza
di due tipologie di dati, ovvero i cosiddetti dati non strutturati e i dati semi-strutturati.
Come suggerisce il nome, i dati strutturati sono tutti quei dati con una struttura ben
precisa, rigida. Ricadono in questa categoria numeri, date, stringhe di testo e, più in generale,
tutti quei dati facilmente rappresentabili in tabelle. Dalla rigida struttura di questi dati deriva
una loro caratteristica molto importante: sono semplici da elaborare e conservare. I dati non
strutturati, invece, comprendono immagini, audio, video, email, post sui social media, etc.
Questa tipologia di dati occupa solitamente molto spazio in memoria e la loro elaborazione
risulta più complessa di quella relativa ai dati strutturati. Queste due problematiche derivano,
appunto, dalla mancanza di una struttura ben definita, che ne consenta l’archiviazione in
formati “compressi” nonché l’elaborazione diretta.
In Figura 1.2 è riportata una breve comparazione tra le due tipologie di dati e, come si
può osservare dalle stime di Gartner, i dati non strutturati costituiscono la fetta maggiore dei
dati aziendali.
Figura 1.2: Una comparazione tra dati strutturati e dati non strutturati
Un punto di incontro tra le due categorie appena descritte sono i dati semi-strutturati.
Questi dati, sebbene presentino una struttura di base, possono essere “personalizzati” per
adattarsi alle esigenze. Ne sono un esempio concreto i documenti in formato XML o JSON.
Questi ultimi, ad esempio, hanno una struttura di base definita da un insieme di coppie
campo-valore, ma questa struttura è modulare e può essere adattata ai diversi casi d’uso. Nel
Listato 1.1 è presente un esempio di quanto appena detto, ovvero un documento JSON in cui
alcuni dei campi includono altri al loro interno, formando delle strutture innestate. Il campo
“profile_image” ne è un chiaro esempio. Esso, infatti, contiene al suo interno un’immagine
(specificata tramite la sua posizione sul disco fisso), il nome dell’immagine e il metodo di
allineamento per la visualizzazione. Risulta chiaro, dunque, come rappresentare dati di
questo tipo in uno schema relazionale non sia impossibile, ma comunque molto complesso.
1 {"user": {
2 "name": "Marco",
3 "surname": "Rossi",
4 "profile_image": {
5 "src": "./DB/images/Marco.png",
6 "name": "Marco",
7 "alignment": "center"
8 },
9 "biography": {
10 "data": "My name is Marco",
11 "size": 36,
12 "style": "bold",
13 "alignment": "center"
14 }
15 }}
Listato 1.1: Un esempio di file JSON
Il significato di NoSQL
L’ovvia conseguenza del costante aumento dei dati non strutturati e semi-strutturati è
la necessità di memorizzare ed elaborare queste enormi quantità di dati. Tuttavia, come già
spiegato nel precedente paragrafo, l’utilizzo dei rigidi schemi impiegati dai DBMS relazionali
non è la strada migliore. Si è venuta a creare, quindi, l’esigenza di soluzioni nuove, flessibili e
scalabili, progettate fin dal principio per lavorare con informazioni non strutturate o semi-
strutturate. Per rispondere, dunque, a questa esigenza sono cominciate a nascere le prime
basi di dati non-relazionali. Ad oggi, la crescente fama dei Big Data e del Cloud Computing è
il motore che più spinge le aziende nella loro transizione dai classici database relazionali a
soluzioni non-relazionali, anche dette soluzioni NoSQL. Tramite la piattaforma Google Trends è
possibile visualizzare l’interesse nel tempo per le soluzioni NoSQL rispetto ai classici RDBMS
negli ultimi 5 anni. Il risultato di tale ricerca è presentato in Figura 1.3.
Figura 1.3: Evoluzione dell’interesse nel tempo per le soluzioni NoSQL e RDBMS
1.2 − NoSQL database 7
Il termine NoSQL vuole, appunto, indicare il distacco dalle vecchie soluzioni relazionali,
le quali, solitamente, utilizzano il linguaggio SQL (Structured Query Language). Il termine,
dunque, non indica delle soluzioni che non fanno uso del linguaggio SQL in modo assoluto,
ma piuttosto soluzioni che non seguono il rigido schema relazionale.
Nonostante il termine NoSQL non è mai stato formalmente definito, recentemente, dalla
maggior parte dei professionisti del settore, viene accettata come traduzione la dicitura
“Not Only SQL”. Il significato di questa dicitura esprime chiaramente come il movimento
NoSQL non sia affatto un movimento che vada contro i classici sistemi relazionali. Difatti, è
sempre più comune trovare queste nuove soluzioni affiancate a sistemi relazionali preesistenti,
potenziandone le capacità e colmandone le lacune.
Le basi di dati che adottano la filosofia NoSQL prendono generalmente il nome di New
Generation Database oppure Next Generation Database.
1.2 NoSQL database

Come già accennato, non esiste una definizione precisa di cosa sia un database NoSQL.
Tuttavia, tutte le basi di dati categorizzate come NoSQL hanno delle caratteristiche comuni.
Le più importanti sono:
• Scalabilità orizzontale: è la caratteristica di un sistema di gestire un carico di lavoro

variabile (solitamente in aumento) in maniera automatica e trasparente all’utente.
Questa proprietà viene raggiunta tramite lo “sharding” dei dati, ovvero una divisione
orizzontale del database su più nodi. La funzionalità dello sharding permette l’accesso
a piccole porzioni dei dati in maniera veloce e senza che l’utente conosca i dettagli
implementativi (dove è conservato il dato). Essa permette, inoltre, di aggiungere o
togliere nodi dall’architettura su cui è distribuito il database senza intaccare la struttura
di quest’ultimo e senza incidere sulle performance di lettura e scrittura.
• Resistenza ai guasti: l’architettura distribuita su più nodi garantisce intrinsecamente una

maggiore resistenza ai guasti, sia su singolo nodo che su più nodi. Questo meccanismo
è possibile grazie al fatto che tutte le basi di dati NoSQL impiegano qualche forma di
replicazione del dato, conservando più copie dello stesso. Quando un nodo dell’archi-
tettura si guasta, è possibile continuare ad accedere ai dati che conteneva, poiché essi
sono replicati sui restanti nodi.
• Alta disponibilità: qualsiasi dato conservato su un database NoSQL deve essere dispo-
nibile, sia in lettura che scrittura, in tempi brevissimi. Per garantire questa proprietà,
così come per la tolleranza ai guasti, ci si avvale della replicazione del dato. Quando
un client richiede un dato, è il nodo con la maggior disponibilità in quell’istante a
rispondere con la sua copia del dato. Questo meccanismo riduce il tempo richiesto per
inviare una risposta ad un client permettendo, inoltre, di servire molte richieste dello
stesso dato contemporaneamente.
• Distribuiti e cloud-oriented: i sistemi NoSQL sono progettati fin dal principio per operare
in architetture distribuite, organizzando i dati sui vari nodi della rete in maniera molto
elastica. Ciò si sposa molto bene con le architetture cloud, poiché esse sono per natura
distribuite e scalabili, permettendo di bilanciare il carico di lavoro tra tutti i nodi
disponibili.
• Schema dei dati flessibile: in netto contrasto con le basi di dati relazionali, dove è presente
uno schema logico rigido, i sistemi NoSQL offrono uno schema flessibile, se non del
tutto assente.
1.2.1 Conseguenze della replicazione del dato

La replicazione del dato implica che tutte le informazioni memorizzate in una base di
dati distribuita non sono conservate in unico nodo fisico. Questa funzionalità garantisce
un incremento di performance, permettendo al load balancer (il componente che si occupa
di assegnare le operazioni ai nodi) di distribuire le operazioni di lettura su diversi nodi,
aumentando, di fatto, la disponibilità del sistema. La replicazione garantisce anche funziona-
lità di backup. Se alcuni nodi vanno offline per qualsivoglia ragione, gli altri nodi possono
continuare a servire le richieste poiché possiedono una copia dei dati del nodo offline.
In Figura 1.4 è presentato un esempio di sistema di replicazione implementato da Mon-
goDB, uno dei DBMS leader nel mondo NoSQL. In particolare, si nota come le richieste di
scritture e lettura siano indirizzate ad un nodo primario che, in seguito, deve occuparsi di
propagare le modifiche ai nodi secondari di backup. Inoltre, MongoDB impiega un sistema di
messaggi di stato chiamati ”heartbeat” (letteralmente battito del cuore), il cui scopo è rendere
consapevoli i nodi della rete sullo stato di tutti gli altri nodi.
Figura 1.4: Schema riassuntivo della replicazione in MongoDB
Il problema principale di conservare diverse copie di un dato nasce quando sono ne-
cessarie operazioni di scrittura. Solamente quando tutte le copie del dato sono conservate
in maniera consistente si possono raggiungere le prestazioni massime in lettura. I sistemi
NoSQL sono caratterizzati da due approcci principali a questo problema:
• scrittura sincrona: quando viene effettuata una scrittura, si attende che quest’ultima sia
correttamente propagata a tutti i nodi replica;
• scrittura asincrona: quando viene effettuata una scrittura, si garantisce che quest’ultima
venga propagata a tutti i nodi replica, ma non si conosce il momento esatto in cui questo
avverrà.
La prima soluzione garantisce, dunque, che le letture immediatamente successive all’o-

perazione di scrittura leggano sempre un dato corretto. Nel secondo scenario, invece, una
lettura immediatamente successiva ad una scrittura potrebbe leggere un dato sporco. La
prima soluzione, sebbene garantisca la consistenza del dato, impatta negativamente nella
disponibilità della base di dati distribuita. La differenza tra i due approcci viene evidenziata
meglio con il CAP Theorem di Brewer.
Il CAP Theorem
Per meglio definire alcune caratteristiche dei database NoSQL è necessario introdurre il
CAP Theorem.
Il teorema in questione fu introdotto per la prima volta da Brewer nel 2000 e consiste di un
semplice concetto: è impossibile per un sistema distribuito garantire consistenza, disponibilità
e partition-tolerance allo stesso tempo.
Il teorema si dimostra molto facilmente per assurdo; difatti, se abbiamo un sistema
perfettamente resistente al partizionamento, e in ciascuna partizione si può leggere senza
interruzione (completa disponibilità), non possiamo avere anche la perfetta consistenza del
dato; questo perchè gli aggiornamenti non possono propagarsi. Tutte e tre queste proprietà
sono, al giorno d’oggi, desiderate. Esse possono essere definite come segue:
• Consistenza: tutti i nodi forniscono la stessa risposta alla stessa richiesta fatta nello stesso
istante. Significa che tutte le copie del dato devono essere sempre aggiornate al valore
più recente;
• Disponibilità: ad ogni richiesta verrà sempre fornita una risposta, ovvero ogni interroga-
zione alla base di dati distribuita deve essere completata;
• Partition-tolerance: il sistema continua a funzionare nonostante la perdita di messaggi

tra nodi o il malfunzionamento di un nodo; il sistema deve sempre essere in grado di
fornire una soluzione quando questi problemi si presentano.
In Figura 1.5, il risultato del CAP Theorem è ben riassunto, ovvero non è possibile avere
un sistema distribuito che garantisca contemporaneamente tutte e tre le caratteristiche, ma
bisogna trovare dei compromessi in base alle esigenze. Le tre combinazioni possibili sono,
infatti, CA (Consistency e Availability), CP (Consistency e Partition-tolerance), oppure AP
(Availability e Partition-tolerance).
Figura 1.5: Diagramma riassuntivo del CAP Theorem

Poiché il principio fondamentale dei DBMS NoSQL è la tolleranza al partizionamento,

non è chiaro cosa significhi cedere la partition-tolerance. Di conseguenza, la scelta rimane
limitata solo tra consistency e availability, in aggiunta all’obbligatoria partition-tolerance.
Un’altra limitazione risiede nel fatto che la scelta tra consistenza e disponibilità avviene
forzatamente quando un sistema NoSQL sceglie il modo in cui effettuare le scritture. Infatti, se
sceglie di tenere sempre aggiornate tutte le copie di un dato si avrà un sistema CP. L’altra faccia
della medaglia è scegliere di aggiornare le copie del dato in maniera asincrona, acquisendo la
proprietà di availability a discapito della consistency. In quest’ultimo caso si avrà un sistema
AP.
Le proprietà BASE
Risulta chiaro ormai che le proprietà ACID (Availability, Consistency, Isolation e Durabi-
lity) delle soluzioni relazionali perdono di significato nel dominio NoSQL. Viene definito,
dunque, un nuovo insieme di proprietà, meno ”stringenti” rispetto alle precedenti. Queste
proprietà prendono il nome di proprietà BASE, ovvero:
• Basically Available: significa che il sistema risponde a ogni richiesta in qualunque

momento, ci potrà anche essere un guasto, ma la risposta arriverà.
• Soft state: significa che in un determinato istante il sistema può trovarsi in uno stato in
cui non tutte le copie di un dato sono consistenti.
• Eventually consistent: indica che anche se non tutti i dati sono consistenti in un preciso
instante, prima o poi lo diventeranno (solitamente si tratta di millisecondi).
Le proprietà appena descritte sono tipiche dei sistemi NoSQL che “scelgono” l’opzione
AP dal CAP Theorem, sacrificando, di fatto, la completa proprietà di consistenza. Sistemi
basati su queste proprietà sono alla base di Twitter, Google, Amazon, YouTube, etc. che le
persone in tutto il mondo usano quotidianamente. Questi servizi, infatti, devono garantire
per prima cosa la massima disponibilità, anche a discapito della consistenza del dato.
1.2.2 Classificazione dei database NoSQL

Come già detto più volte, non esiste una classificazione precisa delle basi di dati NoSQL.
Tuttavia, un criterio utilizzato per classificarle è quello di considerare il loro modello dei dati.
In letteratura sono presenti anche altri metodi di classificazione, alcuni basati sul modello
di esecuzione delle interrogazioni alla base di dati, altri basati sul metodo di sharding e
replicazione.
La classificazione basata sul modello rimane, comunque, la più utilizzata e permette di
classificare i sistemi NoSQL in quattro macro-categorie:
• Key-Value database;
• Column-oriented database;
• Document database;
• Graph database.
Nelle prossime sotto-sezioni viene dettagliata ognuna di queste quattro categorie, di cui,
in Figura 1.6, è possibile osservarne una schematizzazione grafica.
Figura 1.6: Rappresentazione grafica delle quattro macro-categorie del NoSQL
Key-Value database
Con questa tipologia di modello dei dati tutte le righe che compongono il database sono
memorizzate tramite una qualche forma di associazione tra chiavi e valori. Memorizzare le
informazioni con questo metodo permette di scrivere enormi quantità di dati, anche di vario
tipo, in maniera semplice ed efficiente. Un altro vantaggio chiave è la facilità con cui questo
tipo di database può essere partizionato orizzontalmente, permettendone la distribuzione su
più nodi.
Nella stragrande maggioranza dei casi, le basi di dati key-value sono completamente
prive di modello dei dati, e le operazioni che si possono compiere sui dati, sono generalmente
solo tre: put (inserimento del dato), get (selezione del dato) e delete (cancellazione del
dato). Nella Figura 1.7 viene riportata una schematizzazione del modello chiave-valore.
Figura 1.7: Una schematizzazione del modello chiave-valore
Column databases
I database column-oriented, o semplicemente column database, sono in parte simili ai
database key-value dato che anch’essi conservano i dati mediante una chiave. Possono gestire
e distribuire enormi quantità di record su differenti macchine fisiche.
Questa categoria di database è l’ideale per la scalabilità e la gestione di grandi volumi di
dati; difatti, permettono di partizionare la base di dati sia in orizzontale (rispetto alle righe)
sia in verticale (rispetto alle colonne.
Il modello di dati utilizzato è quasi sempre ispirato a Google Big Table, ovvero vengono
create delle collezioni di una o più coppie key-value che corrispondo ad un determinato
record.
Queste collezioni prendono il nome di column families e contengono colonne di dati
correlati. Ogni record è formato da una o più colonne contenenti le informazioni, come
schematizzato in Figura 1.8. Sostanzialmente, queste basi di dati sono molto simili a degli
array bidimensionali dove ogni riga ha una o più coppie chiave-valore associate.
Figura 1.8: Una schematizzazione del modello column-oriented
Document database
Questa categoria gestisce i dati sotto forma di documenti. Ogni documento può avere
un insieme di attributi che può differire totalmente da altri documenti della medesima
collezione. Come mostra la Figura 1.9, questi database possono essere visti come delle
collezioni chiave-documento.
Figura 1.9: Una schematizzazione del modello basato su documenti
Difatti, ogni record della base di dati è composto da un identificatore univoco e un

documento associato. Un singolo documento è composto da vari attributi e ci sono anche
casi in cui uno stesso documento può comparire come attributo all’interno di un altro
documento. Come si può immaginare, ciò garantisce una flessibilità estrema in termini di
modello dei dati. Un’altra caratteristica molto apprezzata di questa categoria è la condivisione
semplice ed immediata dei documenti sotto forma di file JSON, un formato fondamentale
nelle applicazioni web moderne.
Tuttavia, questa flessibilità molto spinta ha un “costo”. I database basati su documento,
infatti, hanno delle performance decisamente inferiori ai key-value database e ai column-
oriented database.
Graph database
L’ultima famiglia dei sistemi NoSQL è rappresentata dai database basati su grafo. Questa
tipologia rappresenta le entità tramite una struttura a grafo. Ogni nodo del grafo corrisponde
ad un’entità e ogni arco tra due entità rappresenta una relazione tra esse (Figura 1.10).
Figura 1.10: Una schematizzazione del modello basato su grafo
Questo modello è molto differente dagli altri appena descritti. Nei database basati su
grafo le relazioni vengono considerate parte fondamentale del modello, tale strategia rende
questi database molto potenti per la rappresentazione e l’elaborazione di reti sociali o, più in
generale, per qualsiasi problema facilmente rappresentabile tramite una rete di nodi.
Questa categoria risulta molto utile quando si vogliono rappresentare modelli di dati
complessi con molte connessioni tra entità e vari gradi di nodi indirettamente collegati ad
esse. Inoltre, facendo uso del concetto di relazione, spesso questi sistemi garantiscono le
proprietà ACID nonostante siano database NoSQL.
CAPITOLO 2
In-memory database e SAP HANA
In questo capitolo verrà introdotta la tecnologia in-memory, analizzandone alcune caratteristiche chiave.
A seguire, verranno introdotti alcuni esempi di database in-memory con accenni alla loro architettura. Infine,
sarà esposta un’analisi più attenta per il database in-memory SAP HANA
2.1 Overview dei database in-memory

Fin dalla nascita delle prime tecnologie relative alle basi di dati, i professionisti del settore
hanno cercato di evitare quanto più possibile le operazione di IO (Input/Output). Queste
operazioni, difatti, sono sempre risultate molto “costose” in termini di tempo, essendo l’ac-
cesso al disco fisso diversi ordini di grandezza più lento rispetto all’accesso alla memoria
RAM. Con il passare degli anni, considerando la legge di Moore e l’incredibile evoluzione di
performance delle CPU e delle memorie, la situazione è ancora più evidente. I moderni pro-
cessori, spesso, presentano degli intervalli di tempo in cui non fanno “nulla” semplicemente
perchè sono in attesa che le operazioni di IO su disco vengano completate.
Recentemente, sono arrivati sul mercato i Solid State Disk (SSD). Gli SSD non offrono
semplicemente prestazioni superiori ai dischi meccanici ma rappresentano un’evoluzione
tecnologica con un funzionamento sostanzialmente diverso. Per avere un’idea della massiccia
differenza di performance tra le due tecnologie si può fare riferimento alla Figura 2.1.
Figura 2.1: Differenza tra i tempi di accesso tipici dei vari componenti
14
2.1 − Overview dei database in-memory 15
In essa, si può notare come il tipico tempo di accesso ad un disco meccanico sia tra i 6 e
gli 8 millisecondi, mentre il tempo medio di accesso ad un SSD è di soli 200 microsecondi, un
intero ordine di grandezza più veloce.
Sebbene gli SSD forniscano un aumento prestazionale notevole rispetto ai dischi magnetici,
sempre in Figura 2.1 si può osservare la drammatica differenza tra i tempi di accesso ad un
SSD rispetto al tempo medio di accesso alla memoria RAM o alla memoria cache. Il tempo di
accesso a quest’ultima è ben due ordini di grandezza inferiore.
Tutto questo per dire come, in concomitanza al declino dei prezzi delle memorie, l’idea di
memorizzare un intero database nella RAM non è più un’utopia. Inoltre, se si considera che i
sistemi moderni sono distribuiti su dei cluster con molti nodi, combinando la RAM di tutti i
nodi il quantitativo totale di memoria disponibile è nell’ordine dei Terabyte.
2.1.1 Caratteristiche dei database in-memory

Come già accennato, un database in-memory (anche detto memory-resident), è una base
di dati che opera completamente nella memoria centrale della macchina che lo ospita. Dal
punto di vista di un utente che utilizza il database, questa particolarità è quasi invisibile;
infatti, un database in-memory fornisce le stesse funzionalità di un tradizionale database
relazionale. Le vere novità sono tutte racchiuse nell’architettura fisica.
I database relazionali, nonostante conservino tutti i dati sul disco fisso, usano anch’essi
la memoria centrale per effettuare il caching dei dati. Il caching è il meccanismo per il quale
un sistema che necessita di usare frequentemente un set di dati nel disco fisso può trasferirli
temporaneamente nella memoria RAM al fine di incrementare le performance di lettura e
scrittura. Essendo la memoria RAM un supporto volatile, un DBMS tradizionale deve scrivere
le modifiche effettuate sui dati in una cache sul disco fisso.
In un database in-memory, entrambe le operazioni appena descritte decadono. Infatti, il
meccanismo di caching perde di significato e l’aggiornamento sul disco fisso non è previsto
(essendo tutti i dati conservati già in memoria centrale). Tuttavia, poiché la RAM è un suppor-
to volatile, questa categoria di database deve comunque garantire un modello di persistenza
dei dati, altrimenti risulterebbe troppo rischioso conservare qualsiasi dato significativo.
I sistemi in-memory generalmente usano una combinazione di tecniche per assicurare la
persistenza del dato. Queste includono:
• replicazione dei dati su altri nodi del cluster;
• salvataggio di intere versioni “cristallizzate” della base di dati (chiamate snapshot oppure
checkpoint) sul disco fisso;
• mantenimento di un registro delle operazioni/transazioni effettuate in speciali file su

disco detti append-only.
Encoding dei dati

Eliminata la problematica del lento accesso al disco fisso, i database in-memory raggiun-
gono performance non possibili per le soluzioni “classiche”. Tuttavia, con le potentissime
CPU moderne, il collo di bottiglia continua ad essere l’accesso alla memoria. Lato software,
per diminuire il tempo di accesso al blocco fisico di memoria, non si può fare nulla. Una
soluzione intelligente a questo problema consiste nel diminuire l’accesso al dato di interesse,
all’interno del blocco fisico di memoria, tramite tecniche di encoding dei dati.
Di queste tecniche, la dictionary encoding è una delle più apprezzate per via della sua effi-
cacia. Essa consiste nel comprimere le tabelle utilizzando un dizionario (spesso il dizionario è
a sua volta una tabella) per memorizzare i campi ripetuti del database. Per ogni tabella, viene
generato un array di attributi con un determinato ValueID; questo valore viene, poi, associato
alle specifiche occorrenze tramite un riferimento, in maniera simile a quanto avviene nelle
tabelle hash. Nel caso sia necessario effettuare una ricerca, il processo si articola come segue:
1. si ricerca nel dizionario il valore richiesto, recuperando il rispettivo ValueID,
2. si scansiona l’array degli attributi con il ValueID,
3. nel risultato della ricerca, si sostituisce il ValueID con il rispettivo valore nel dizionario.
Se si considera che la maggior parte dei dati aziendali ha una bassa entropia, si può
comprendere come questa tecnica possa ridurre la dimensione di una tabella in modo si-
gnificativo. Si pensi ad una tabella contenente i dati dei clienti e in cui una delle colonne
rappresenti la città di residenza. Molti clienti vivranno in una stessa città quindi, invece che
conservare più volte la medesima stringa di caratteri (può occupare diversi byte), si può
memorizzare la stringa una sola volta nel dizionario e usare dei riferimenti (che occupano 4 o
8 byte) per tutte le altre occorrenze.
Parallelismo
Sempre con l’aumento della velocità di elaborazione come obiettivo, i database in-memory
si avvalgono di tecniche di parallelizzazione dei dati e dei processi. Il concetto di parallelismo
è parte integrante dell’architettura dei moderni computer e, nel futuro, questo aspetto diven-
terà sempre più importante. Come si può osservare in Figura 2.2, gli in-memory database
mettono in atto due tipologie di parallelismo: il pipelined parallelism e il data parallelism. Nel
pipelined parallelism, gli operatori successivi possono cominciare ad elaborare porzioni di dati
che l’operatore precedente ha già terminato di elaborare. Il data parallelism consiste nell’ese-
cuzione parallela degli operatori su porzioni di dati partizionate su più nodi, costruendo
il risultato finale come unione dei risultati intermedi. Questi due concetti, seppur semplici,
sono molto complessi da mettere in atto.
Figura 2.2: Schematizzazione del pipelined parallelism e del data parallelism
Data aging
Spesso non tutti i dati di un database sono rilevanti in dato lasso temporale. In questi casi
può essere superfluo mantenere in memoria centrale la base di dati nella sua interezza. Ad
esempio, i dati di fatturazione di oltre 10 anni saranno meno rilevanti rispetto a quelli attuali;
ciò nonostante non possono essere eliminati. Per incrementare, dunque, le performance si
può usare un sistema di “data aging”, che consiste nel gestire differentemente i dati rilevanti
(hot data) e i dati irrilevanti (cold data).
Questa differenziazione serve ad individuare velocemente gli hot data, evitando di
accedere alle partizioni dove risiedono i cold data, migliorando l’utilizzo della memoria e le
performance delle query. Questa tecnica non modifica lo schema dei dati e i dati irrilevanti
rimangono comunque accessibili.
2.1.2 Differenze tra i sistemi tradizionali e sistemi in-memory

Come visto, i database in-memory presentano alcune caratteristiche nuove rispetto ai
database relazionali; altre funzionalità, invece, sono comuni ad entrambe le tipologie ma
vengono gestite diversamente. Nelle successive sotto-sezioni vengono esposte alcune di
queste differenze.
Tipologia di query
Una sfida che si presenta con i classici DBMS è la separazione tra le query analitiche e
le query transazionali. Le prime vengono indicate con l’acronimo OLAP (Online Analytical
Processing), e le seconde con l’acronimo OLTP (Online Transactional Processing).
Le query OLAP sono utilizzate per analizzare i dati e sono caratterizzate da interrogazioni
complesse ed articolate alla base di dati. Esse lavorano principalmente sui dati storici al fine
di effettuare predizioni, realizzare report e supportare processi di Data Mining. Il loro scopo è
quello di fornire insight a medio e lungo termine sui dati in modo da supportare i dirigenti
nelle loro decisioni.
Le query OLTP, invece, lavorano con i dati transazionali, ovvero tutti quei dati che fanno
parte dei normali processi aziendali giornalieri. Sono query semplici e brevi il cui scopo
può essere, ad esempio, aggiornare un’anagrafica utente, registrare un nuovo utente nel
database, recuperare informazioni o emettere una fattura. Esse rappresentano il cuore dei
DBMS relazionali.
In Tabella 2.1 è presente una sintesi delle differenze tra le query OLTP e quelle OLAP.
Categoria OLTP OLAP

Preparazione di reportistica, supporto
Applicazioni Gestire i processi aziendali giornalieri
decisionale e previsioni future
Grande numero di brevi transazioni Basso volume di transazioni analitiche
Volume
online complesse
Sorgente dati Piccole porzioni di dati operazionali Grandi volumi di dati storici e aggregati
Obiettivo Inserimento e aggiornamento dei dati Recupero delle informazioni
Tabella 2.1: Differenze tra query OLTP e OLAP
Idealmente, le basi di dati devono essere in grado di processare entrambi i tipi di query.
Spesso, con i DBMS relazionali di un tempo, l’elaborazione delle query OLAP veniva delegata
a sistemi ausiliari in modo da non rallentare l’esecuzione delle numerose query OLTP. Nei
database in-memory, grazie alle superiori performance generali del sistema, è possibile
affrontare entrambe le tipologie di query. Nello specifico, memorizzare le informazioni con il
modello column-oriented permette la veloce esecuzione delle interrogazioni OLAP. Nel caso
in cui, invece, siano necessarie maggiori performance per le interrogazioni OLTP, i database
in-memory sono in grado di adottare anche schemi ibridi di rappresentazione del dato.
Operazioni sul database

Per via della struttura colonnare dei database in-memory, le comuni operazioni di inseri-
mento, cancellazione e aggiornamento si svolgono in maniera differente dai DBMS classici.
In dettaglio, tali operazioni avvengono nel seguente modo:
• Inserimento: nelle strutture colonnari le operazioni di inserimento funzionano diversa-

mente rispetto alla classica organizzazione per righe. In quest’ultima, il nuovo record
da memorizzare può essere semplicemente inserito in fondo alla tabella, mentre nei
database column-oriented è necessario inserire un nuovo record in ogni colonna. Nei
sistemi in-memory che fanno uso della dictionary encoding, se il nuovo record non
necessita la creazione di un nuovo valore nel dizionario, basta aggiungere il ValueID
all’array degli attributi (come spiegato nella Sotto-Sezione 2.1.1). Altrimenti, se è ne-
cessario aggiungere un nuovo valore al dizionario, seguiranno delle operazioni di
riordinamento dello stesso e di riorganizzazione del vettore degli attributi.
• Aggiornamento: il macro funzionamento delle operazioni di aggiornamento è identico

tra i due sistemi; tuttavia, nei database colonnari questa operazione risulta più costosa.
Infatti, la sequenza di aggiornamento è composta dall’aggiornamento del dizionario,
la riorganizzazione del dizionario, la riorganizzazione dell’array degli attributi e la
conseguente modifica dei vecchi valori con i nuovi. Per evitare tutta questa sequenza di
operazioni spesso viene usato un approccio insert-only, spiegato più avanti.
• Cancellazione: per le operazioni di cancellazione i sistemi in-memory offrono, solitamen-

te, due modi di procedere. Il primo consiste nella la vera e propria cancellazione fisica
del record di interesse (ciò può essere necessario per ragioni legali); il secondo, consiste
nella semplice invalidazione del record nel database. Quest’ultimo approccio è il più
comune per via della sua velocità; esso, infatti, consiste nella semplice impostazione di
un flag di invalidità.
• Selezione: per le operazioni di selezione, eseguire le query più selettive per prime permet-
te di restringere fin da subito il set di dati da recuperare, migliorando le performance.
Nei sistemi colonnari, ciò si traduce nel selezionare per prime le colonne con cardinalità
minore. La ricerca nel dizionario avviene una volta sola e le comparazioni vengono
fatte sulla base dei valori codificati nel dizionario. Per query semplici, un database or-
ganizzato per righe permette di ottenere risultati più velocemente; invece, se l’obiettivo
sono query complesse che selezionano molte righe rispetto ad uno stesso attributo,
l’organizzazione per colonne risulta vincente. In Tabella 2.2 viene riportato un esempio
della differenza di performance nei due casi.
Organizzazione per righe Organizzazione per colonne

Query semplice ∼46 ms ∼93 ms
Query complessa 1.257 s ∼127 ms
Tabella 2.2: Confronto dei tempi di esecuzione nel caso di organizzazione per righe e di
organizzazione per colonne
Rappresentazione dei dati

Se nei DBMS relazionali le informazioni erano conservate come tabelle bidimensionali,
nei sistemi in-memory tutte le informazioni sono memorizzate in formato monodimensio-
nale. È necessario, dunque, decidere come trasformare i dati bidimensionali in dati mono-
dimensionali usando un modello basato su righe, basato su colonne oppure uno schema
ibrido.
Nel modello basato su righe (Row Data Layout), come si osserva in Figura 2.3, i dati in
memoria sono memorizzati sotto forma di tuple consecutive. In questo modo, le scansione di
una singola tupla o di più tuple consecutive risulta molto veloce. Tuttavia, questo modello
permette di implementare tecniche di compressione meno performanti.
In Figura 2.4, invece, i dati vengono conservati rispetto agli attributi. La scansione di
un’intera colonna risulta molto veloce e si possono implementare tecniche di compressione
dati molto spinte, come la dictionary encoding. Un aspetto negativo risiede nella ripresa dati
a seguito di un guasto; infatti, la ricostruzione delle colonne a partire dal file di log risulta
complessa.
2.1.3 Esempi di database in-memory

Descritte e analizzate le caratteristiche dei sistemi in-memory, nelle prossime sotto-sezioni,
vengono presentati alcuni esempi di DBMS in-memory.
TimesTen
TimesTen è uno dei primi sistemi in-memory, nato con l’obiettivo di supportare carichi di
lavoro simili ai DBMS relazionali ma con performance migliori. Le prime versioni pubblicate
risalgono al 1995; nel 2005, la società fu acquisita da Oracle. Oracle cominciò ad offrire
TimesTen come soluzione in-memory indipendente, oppure come caching database a supporto
dei propri DBMS relazionali.
In TimesTen tutti i dati risiedono nella memoria centrale. Per garantire la persistenza
viene periodicamente scritta una snapshot dell’intero database sul disco fisso, oltre ad un file
di log contenente lo storico delle transazioni completate. Nell’evenienza in cui si verifichi

un blackout nel tempo che intercorre tra il commit di una transazione e l’aggiornamento del
log sul disco fisso si può avere una perdita dei dati. Ciò avviene perchè TimesTen gestisce le
scritture sul disco fisso in modo asincrono. Questo comportamento viola le proprietà ACID;
in particolare viene violata la proprietà di Durability.
In Figura 2.5 è presentata l’architettura di TimesTen. Quando il sistema viene avviato,
tutti i dati vengono caricati in memoria e le applicazioni interagiscono con il database tramite
query SQL.
Figura 2.5: Schema dell’architettura di TimesTen
Redis
Mentre TimesTen è un tentativo di costruire un database in-memory compatibile con il
modello relazionale, Redis rappresenta l’estremo opposto. Redis è, infatti, un key-value store
e, in quanto tale, non presenta alcun tipo di schema logico.
Redis (Remote Dictionary Server) si propone come una soluzione in grado di sostenere un
ritmo molto elevato di transazioni al secondo. Esso segue un modello chiave-valore in cui le
chiavi puntano a degli oggetti. Questi ultimi possono essere di vario tipo e, generalmente,
sono costituiti da stringhe di testo, oppure varie “collezioni” di stringhe, ad esempio liste,
liste ordinate, tabelle hash, etc.
Una caratteristica di Redis è che permette di operare con basi di dati più grandi dell’effet-
tiva memoria disponibile; questo è possibile grazie ad un meccanismo di virtual memory che
permette di spostare sul disco fisso le chiavi accedute meno frequentemente. Nell’eventualità
in cui sia richiesta una chiave che è stata spostata su disco fisso, le operazioni di I/O saranno
inevitabili. Questa soluzione rappresenta un approccio ottimistico; infatti, si confida nel fatto
che le chiavi spostate sul disco fisso vengano accedute di rado.
Come si può osservare in Figura 2.6, per quanto riguarda la persistenza dei dati, anche
Redis utilizza il disco fisso. In particolare, vengono generati i seguenti due file:
• RDB File: consiste nella versione cristallizzata ad un preciso istante dell’intero database
Redis. La generazione di questo file può essere configurata ad intervalli regolari di
tempo oppure quando viene raggiunta una certa soglia di scritture.
• Append Only File (AOF): consiste in un registro, aggiornato alla fine di qualsiasi opera-
zione, che permette di effettuare il ripristino del database partendo dal file RDB.
2.2 − SAP HANA 21
Figura 2.6: Schema dell’architettura di Redis
VoltDB
VoltDB rappresenta un punto di rottura rispetto a TimesTen e Redis. Questi ultimi fanno
uso di una qualche forma di file su disco per garantire la persistenza dei dati, come registri o
log transazionali. VoltDB, invece, si propone come soluzione puramente in-memory, abolendo
qualsiasi scrittura sul disco fisso.
Per garantire le proprietà ACID e, in particolare, la persistenza, VoltDB si avvale di un
sistema di replicazione su nodi. Un commit di una transazione viene considerato completo
solo quando questo viene propagato a più di un nodo fisico. Il numero di nodi coinvolti
dipende da un parametro denominato K-safety level. Per esempio, un K-safety level pari a 2
garantisce che se due qualsiasi nodi si guastano non ci sarà alcuna perdita dei dati. In questo
caso, per considerare un commit completo, sarà necessario che quest’ultimo venga propagato
correttamente ad almeno 3 nodi.
VoltDB supporta il modello relazionale, tuttavia, la sua architettura multi-nodo funziona
al meglio se questo modello può essere partizionato. Le tabelle del database devono obbliga-
toriamente essere partizionate oppure replicate. Le tabelle partizionate sono distribuite su
più nodi, mentre quelle replicate vengono duplicate in ogni partizione. Le tabelle replicate
sono più costose da gestire per le transazioni di tipo OLTP, dovendo ripetere le operazioni
per ognuna delle partizioni.
Inoltre, VoltDB, impiega un meccanismo per cui ogni partizione del database viene
associata ad una sola CPU che avrà accesso esclusivo ad essa. Questa soluzione permette di
tamponare il costo in performance causato dai meccanismi di locking; tuttavia, richiede che le
transazioni vengano eseguite in breve tempo al fine di evitare una serializzazione eccessiva
di richieste.
2.2 SAP HANA

HANA è la soluzione in-memory sviluppata dalla società SAP AG, leader mondiale
nel settore dei sistemi ERP (Enterprise Resource Planning). Essa rappresenta il cuore di SAP
S/4HANA, suite ERP che basa l’intera piattaforma su SAP HANA.
2.2 − SAP HANA 22
2.2.1 Breve panoramica delle soluzioni SAP

SAP AG è stata fondata nel 1972 a Mannheim, in Germania, da un gruppo di ex ingegneri
IBM. Il loro proposito era sviluppare un pacchetto software che coniugasse funzioni aziendali
diverse. L’idea era quella di aiutare le organizzazioni a sostituire la moltitudine di diverse
applicazioni aziendali tipica dell’epoca. Difatti, in quegli anni, non era raro per le aziende
avere un applicativo software differente per ogni processo aziendale, tra cui sistemi di gestio-
ne finanziaria, sistemi di gestione del magazzino, sistemi di gestione della manutenzione,
etc. Dalla metà degli anni Novanta, SAP inizia a supportare Microsoft Windows e Linux
consolidando definitivamente la sua posizione nel mercato.
Le suite ERP di SAP non sono mirate a specifiche aziende; il loro punto di forza, infatti,
risiede nell’essere una soluzione generica ma, allo stesso tempo, fortemente personalizzabile.
Ciò che permette a qualunque azienda di approcciarsi a SAP, dalla piccola impresa alle
grandi multinazionali, è la sua modularità. Difatti, non è necessario implementare obbligato-
riamente tutta la suite ERP offerta da SAP. Ad esempio, un’azienda che ha necessità di gestire
efficacemente il magazzino e di implementare un sistema di MRP (Material Requirements
Planning) può adottare soltanto il modulo Material Management (MM). Questa possibilità
è molto apprezzata dalle aziende poiché permette di ridurre significativamente i costi di
adozione in quei casi in cui non è necessario l’intero pacchetto software.
Una delle prime soluzioni offerte da SAP fu SAP R/1, un prodotto capace di integrare le
funzioni logistiche con quelle contabili, utilizzando un database comune. Questa soluzione,
come suggerisce il nome, possiede un’architettura ad un livello in cui Presentation (interfaccia
utente destinata all’inserimento dei dati), Application (sistema di elaborazione dei dati vero e
proprio) e Database risiedono tutti sullo stesso server.
In seguito, verso la fine degli anni ’70, SAP rivaluta la struttura ad un livello e lancia
la versione SAP R/2. In questa versione l’architettura è a due livelli, con Presentation su un
macchina e Application e Database su un’altra.
All’inizio degli anni ’90, SAP lancia R/3, una versione a tre livelli in cui Presentation,
Application e Database si trovano ciascuno sul proprio server. Si iniziano a diffondere, inoltre,
i concetti di client-server e l’implementazione di un’interfaccia grafica uniforme tra i vari
componenti dell’applicativo. SAP R/3 diventa il fondamento su cui verranno costruite
tutte le versioni future del software. Un importante aggiornamento fu la versione 5.0 in
cui il nome cambiò in SAP ERP Central Component (SAP ECC) e la società implementò
un suo linguaggio di programmazione denominato ABAP. ABAP sta per Advanced Business
Application Programming e permette, all’interno di SAP, di personalizzare molte delle funzioni
standard presenti e di automatizzare i processi tramite la logica desiderata.
2.2.2 Overview di SAP HANA

SAP introdusse HANA nel 2010, sponsorizzandolo come un rivoluzionario DBMS in-
memory progettato principalmente per la Business Intelligence (BI), ma comunque capace di
gestire carichi di lavoro transazionali (OLTP).
SAP HANA è un database relazionale che si propone di offrire performance eccezionali
combinando la tecnologia in-memory con una rappresentazione dei dati column-oriented. Per
evitare problematiche di compatibilità e per garantire le migliori performance, SAP HANA
richiede l’installazione su server con hardware specifico, detti HANA-certified Servers.
Le tabelle in HANA possono essere configurate come row-oriented o column-oriented.
Tipicamente, le tabelle a supporto della BI vengono configurate come colonnari, mentre
le tabelle relative alla parte transazionale vengono configurate come row-oriented. Per le
tabelle transazionali viene garantita la presenza in-memory, mentre le tabelle colonnari sono
solitamente caricate in memoria solo se richieste.
2.2 − SAP HANA 23
Come TimesTen e Redis, l’architettura per la persistenza dei dati di HANA si avvale
dell’uso di snapshots e file di registro salvati su disco fisso. Il rispetto delle proprietà ACID
da parte delle transazioni è garantito da un file di log, chiamato redo log. Per minimizzare
l’impatto delle scritture su questo file di log presente su disco, SAP HANA impone che il
esso sia posizionato su un SSD HANA-certified.
L’architettura colonnare di HANA include un’implementazione di un write-optimized
delta store (in breve delta store). Il delta store è un’area del database ottimizzata per scritture
frequenti. Infatti, come visto nella precedente sezione, le scritture sul modello colonnare
possono risultare più costose rispetto al modello row-oriented. Il delta store è un’area di
memoria generalmente row-oriented, non ordinata e che non utilizza tecniche di compressione
al fine di garantire alte performance in scrittura.
Come si osserva in Figura 2.7, la gestione della memoria da parte di SAP HANA risulta
abbastanza intricata.
Figura 2.7: Schema della gestione della memoria da parte di SAP HANA
In particolare, si possono distinguere i seguenti aspetti chiave:
1. All’avvio del sistema, le tabelle row-oriented e alcune delle tabelle column-oriented

vengono lette dal database file memorizzato sul disco fisso e caricate in memoria.
2. Ulteriori tabelle column-oriented possono essere caricate in memoria se vengono richieste

delle operazioni di lettura e scrittura su di esse.
3. Gli aggiornamenti da eseguire su tabelle colonnari vengono prima effettuati nel delta
store, inizialmente nel row-oriented L1 store.
2.2 − SAP HANA 24
4. Quando il sistema lo ritiene opportuno, i dati presenti nell’L1 store vengono “promossi”
nell’L2 store, che impiega tecniche di compressione moderate e non ordina i dati. Infine,
i dati migrano nelle effettive tabelle column-oriented che sono altamente compresse e
ordinate.
5. Quando si effettuano query verso tabelle colonnari è necessario leggere da entrambi i

delta store (L1 e L2) e dall’effettiva tabella di interesse. Ciò è necessario per essere sicuri
di aver letto anche gli eventuali ultimi aggiornamenti che non sono ancora stati spostati
nella tabella principale.
6. Riguardo alla persistenza, delle snapshot dell’intera memoria, chiamate SavePoint,

vengono salvate sul disco fisso.
7. Ad intervalli regolari, i vari SavePoint, vengono integrati con il database file presente
sul disco in modo da mantenerlo aggiornato.
8. Quando una transazione richiede il commit, un record transazionale viene scritto nel
redo log per garantire la proprietà di Durability.
Come visto, HANA, così come altri database in-memory (TimesTen o Redis), presenta
situazioni in cui la scrittura sul disco fisso risulta inevitabile. Le prestazioni delle soluzioni in-
memory sono comunque molto elevate rispetto ai classici database su disco e, per le aziende,
la persistenza del dato risulta più importante di qualche millisecondo in più per completare
le transazioni. Per questo motivo, il compromesso di avere una soluzione in-memory che,
ogni tanto, deve rallentare le sue performance per scrivere sul disco, è ben accettata.
CAPITOLO 3
Panoramica generale del processo di migrazione
Questo capitolo è dedicato al processo di migrazione in generale. Inizialmente vengono introdotti i

vantaggi e le sfide da affrontare nell’ambito della migrazione. Si prosegue, poi, introducendo la metodologia
di progetto consigliata da SAP per concludere introducendo l’effettiva strategia adottata.
3.1 Situazione aziendale attuale

L’azienda oggetto della presente tesi è una nota multinazionale italiana di beni di consumo
per l’igiene personale. Per ragioni di privacy, il nome dell’azienda non può comparire nel
presente documento, motivo per cui, per il resto della trattazione, ci si riferirà ad essa
semplicemente con il termine “azienda”. Analogamente, alcuni dei processi aziendali critici
ed alcuni dettagli del processo di migrazione non potranno essere descritti.
In azienda vengono utilizzate le soluzioni SAP per coprire i business need dei vari processi
interni. Nello specifico, viene utilizzata la suite ERP SAP ECC. SAP ECC si compone di
diversi moduli indipendenti ma che, allo stesso tempo, si integrano perfettamente tra loro
quando utilizzati insieme. I moduli adottati dall’azienda sono:
• Finance (FI): è il modulo dedicato alla gestione e all’elaborazione dei dati relativi alle
transazioni finanziarie nelle imprese di piccole, medie e grandi dimensioni. Esso pre-
senta diversi sotto-moduli che integrano funzioni per gestire la contabilità generale,
la contabilità dei fornitori e la contabilità dei clienti. Il modulo per la contabilità gene-
rale permette di tenere traccia dello stato patrimoniale, delle entrate e delle uscite. Il
modulo per la contabilità dei fornitori gestisce, invece, i pagamenti delle aziende o dei
liberi professionisti che offrono servizi e/o prodotti fondamentali per l’azienda. Infine,
l’ultimo modulo gestisce tutte le attività riguardanti le transazioni dei clienti, studiando
oltretutto il rischio di insolvenza.
• Controlling (CO): è il modulo che si occupa, principalmente, di generare report in tempo
reale a supporto della pianificazione aziendale sulla base di dati concreti e tangibili. Esso
si occupa, dunque, di fornire informazioni a manager e direttori su come, e dove, viene
allocato il budget aziendale. Esso garantisce, inoltre, le funzionalità per la contabilità per
centro di costo, la contabilità per centro di profitto, l’Activity Based Costing e l’analisi
della profittabilità.
• Material Management (MM): è il modulo che copre tutta la parte di gestione dei materiali
e del magazzino in ottica di maggiore efficienza e produttività. La gestione dei materiali
25
3.1 − Situazione aziendale attuale 26
è un aspetto cruciale per tutte le aziende che producono beni e può determinare, nel
lungo periodo, la sopravvivenza o meno di un’azienda sul mercato. Saper gestire in
maniera efficiente i materiali significa coordinare al meglio le scorte in magazzino,
evitando inutili giacenze nei depositi e offrendo all’azienda la possibilità di investire
il proprio capitale in modo più fruttuoso. In aggiunta a ciò, anche la qualità della
produzione dipende, in buona parte, da come vengono gestite materie prime e risorse
lungo tutta la linea produttiva.
• Sales & Distribution (SD): grazie a questo modulo è possibile gestire e monitorare l’intero
processo che che va dalla richiesta di un eventuale preventivo all’effettiva consegna
del prodotto al cliente. È uno strumento utile per l’elaborazione dei dati e la creazione
di report specifici per le seguenti aree: prezzo e tassazione, verifica della disponibilità
del materiale, ordini di vendita, organizzazione del processo produttivo, spedizione e
consegna del prodotto e fatturazione.
• Production Planning (PP): è un modulo con molti punti di contatto con il Production
Planning e Material Management (MM). Esso permette di pianificare la produzione in
base alla domanda di mercato e alla propria capacità produttiva effettiva. Oltre alla
pianificazione dei processi di produzione, esso consente anche di pianificare l’approv-
vigionamento dei materiali necessari alla produzione tramite il sotto-modulo MRP
(Material Requirements Planning) nonché di pianificare gli acquisti dei materiali necessari
tenendo conto dei tempi di consegna stimati. Risulta essere un modulo fondamentale
per un’azienda manifatturiera.
• Plant Maintenance (PM): è il modulo utilizzato per la gestione di tutte le attività di
manutenzione dell’azienda. Esso è composto da molte funzionalità come, ad esem-
pio, gestione delle ispezioni, sistema di notificazione, strumenti per la manutenzione
correttiva e preventiva e pianificazione degli interventi di manutenzione.
Oltre ai moduli funzionali appena descritti, l’azienda utilizza molti moduli tecnici. Tra i
più importanti troviamo:
• SAP Basis: modulo per la gestione e amministrazione dei sistemi SAP.
• SAP SRM: modulo che contiene molti strumenti per l’area Sourcing and Procurement,
ovvero quell’area aziendale che si occupa di identificare i fornitori da cui approvvigio-
narsi.
• SAP ABAP: modulo contenente tutto il necessario per sviluppare applicazioni e report
“custom” tramite il linguaggio ABAP al fine di estendere le funzionalità standard di
SAP.
Nonostante la suite SAP sia il sistema principale tramite il quale l’azienda conduce i
propri affari, vengono utilizzati molti altri software ausiliari denominati “sistemi satellite”.
Ne sono un esempio i tool di Business Intelligence; infatti, tool quali Qlik e Salesforce vengono
usati attivamente in azienda.
Nonostante questi sistemi satellite non sono impattati dal progetto di migrazione in
modo diretto, spesso si sono rese necessarie attività di manutenzione al fine di garantirne la
compatibilità con il nuovo sistema SAP S/4HANA.
3.1.1 Vantaggi della migrazione

La migrazione a SAP S/4HANA presenta molti vantaggi dal punto di vista tecnologico;
tuttavia, anche sul piano funzionale sono presenti delle novità.
Tra i vantaggi principali troviamo:
• Elaborazione dei dati più veloce ed efficiente: SAP S/4HANA offre una scalabilità maggiore
rispetto alle precedenti versioni garantendo un maggiore supporto alle attività di
memorizzazione e analisi dei dati. Grazie all’architettura in-memory del database
HANA lo scaling verticale del sistema non impatta eccessivamente le performance di
elaborazione. Difatti, SAP S/4HANA permette la pianificazione, l’esecuzione, l’analisi
e la generazione di report sui dati in tempo reale. Questo aumento di performance
consente alle aziende di prendere delle decisioni data-driven in maniera veloce ed
efficace.
• Semplificazione dei processi di business: con S/4HANA, SAP, ha spinto molto sulla standar-
dizzazione delle funzionalità e sulla consistenza dell’interfaccia grafica nelle varie aree
della piattaforma (punto dolente delle precedenti implementazioni). Ciò può sembrare
un aspetto banale ma, nel concreto, permette alle aziende di implementare e integrare
nuove soluzioni in maniera più semplice.
• Design user-friendly: uno degli aspetti più significativi e visibili di S/4HANA è il design
user-friendly che SAP si è impegnata a garantire ai suoi clienti. Negli anni, infatti, sono
state molteplici le critiche mosse a SAP per via dell’interfaccia utente molto arretrata e
complicata da usare, specialmente per quella fetta di utenti che non possiede conoscenze
informatiche. Ci sono stati miglioramenti anche sull’utilizzo dell’interfaccia tramite
tablet e smartphone, garantendo un’interfaccia consistente tra i vari dispositivi.
• Architettura cloud-ready: con S/4HANA, SAP ha aperto, finalmente, le porte al cloud.

Difatti, la nuova piattaforma può essere implementata nella sua versione classica
detta on-premise, oppure nella versione denominata SAP HANA Cloud. Tale versione
supporta nativamente il cloud, garantisce elasticità in termini di scalabilità e riduce gli
interventi di manutenzione. La versione cloud viene fornita come DaaS (Database as a
Service) permettendo di pagare solo le risorse effettivamente consumate. Inoltre, sarà
cura di SAP stessa gestire l’hardware, il sistema operativo, i backup e le manutenzioni
sul sistema.
• Ottimizzazione del Total Cost of Ownership: SAP dichiara che le aziende che adottano
S/4HANA ottengono dei benefici grazie all’infrastruttura tecnologica semplificata. Il
nuovo sistema permette di gestire, tramite un’unica soluzione, sia i carichi di lavoro
transazionali che i carichi di lavoro tipici della Business Intelligence. Ciò vuol dire che
le aziende possono ottenere di più investendo di meno, riducendo, di fatto, i costi
operazionali. Specialmente nella sua versione basata sul cloud, S/4HANA permette di
evitare costosi investimenti in hardware e infrastruttura di rete.
• Tecnologie innovative: uno dei punti chiave nella strategia di marketing adottata da SAP
per S/4HANA è l’adozione delle più recenti tecnologie in ambito IT. In particolare, la
nuova versione integra sistemi di intelligenza artificiale, machine learning e analisi
predittiva in tempo reale nonché strumenti integrati per i Big Data, per la Data Science
e per l’Internet of Things.
• Backward e forward compatibility: il team di sviluppo di SAP ha lavorato duramente per

rendere S/4HANA facilmente integrabile con le altre applicazioni SAP. Tale integrabilità
riguarda sia le applicazioni disponibili oggi che quelle future. Questa caratteristica è
molto apprezzata dalle aziende che utilizzano già altri prodotti SAP come, ad esempio,
Ariba, SAP Analytics Cloud e FieldGlass.
In conclusione, i benefici della migrazione sono molti ma, d’altro canto, sono molte anche
tutte le potenziali implicazioni riguardo i processi di business aziendali. Queste implicazioni
rendono la transizione ad S/4HANA una decisione importante e significativa che non deve
essere presa con leggerezza. Per le aziende che vogliono, invece, effettuare un’implementa-
zione ex-novo, la sfida da affrontare risulta decisamente minore e la moltitudine di vantaggi
apportati ai processi aziendali può effettivamente essere un aspetto allettante.
Oltre ai vantaggi appena descritti, in Figura 3.1 è possibile osservare un panoramica
riassuntiva di tutte le caratteristiche e gli aspetti aziendali impattati da SAP S/4HANA.
Figura 3.1: Panoramica delle aree impattate da SAP S/4HANA
3.1.2 Sfide delle migrazione

SAP AG, fin dal lancio di SAP HANA nel 2015, ha avviato un’aggressiva campagna di
marketing che ne promuove i vantaggi rispetto alle vecchie versioni del noto gestionale. A
riguardo, non sono tardate ad arrivare delle critiche da parte di molte aziende che si occupano
di analisi di mercato. Se, da un lato, SAP S/4HANA garantisce performance eccezionali grazie
al database in-memory HANA sottostante, dall’altro, la pura performance di elaborazione
non è di fondamentale importanza per molti dei clienti della società. Con il nuovo S/4HANA,
SAP non ha semplicemente rilasciato un nuovo aggiornamento per le soluzioni precedenti,
bensì ha realizzato un nuovo modello di memorizzazione, gestione ed analisi del dato.
Così come qualsiasi altra tipologia di innovazione tecnologica all’interno delle grandi
aziende, la migrazione ad HANA presenta delle difficoltà e delle sfide veramente notevoli.
Qualsiasi azienda che vuole effettuare la transizione al nuovo sistema deve imbarcarsi in un
percorso tortuoso dove i rischi sono dietro l’angolo.
Alcune delle sfide con maggiore impatto sono:
• Disorganizzazione e confusione: nonostante la disorganizzazione non rappresenti un

sfida tecnica, la radice di molti dei problemi riscontrati in fase di conversione risiede
nella confusione e impreparazione generale attorno al piano di migrazione. Non è
raro valutare in modo errato i tempi richiesti dalle varie attività di conversione. Per la
corretta valutazione delle tempistiche e degli effort aziendali è necessario avere una
visione chiara del sistema di partenza e del sistema di arrivo; tuttavia, avere questa
consapevolezza dei propri sistemi è molto complicato.
• Preparazione insufficiente o inadeguata: spesso, risulta evidente fin da subito un’inade-

guata analisi dei passi da seguire per la preparazione del sistema attuale in vista della
migrazione. La causa, solitamente, risiede nel non allocare abbastanza tempo alle fa-
si iniziali di preparazione. Trattare con superficialità le fasi di preparazione risulta

assolutamente deleterio per la buona riuscita del progetto.
• Complessità dei dati da migrare: spostare i dati da SAP ECC a S/4HANA non è un
semplice “copia e incolla” ma, piuttosto, un lavoro delicato e complesso. Non è raro che
un’implementazione SAP contenga quantità veramente massicce di record, motivo per
cui, se non effettuata con le dovute attenzioni, la migrazione può causare perdite di dati.
Inoltre, un’eventuale perdita di dati potrebbe non generare alcun sintomo, rimanendo
nascosta fino a quando un’applicazione o un processo di audit richiede quei dati.
• Conversione dei programmi custom: tramite il linguaggio ABAP è possibile personalizzare
e implementare molteplici funzionalità SAP specificamente progettate per il proprio
caso d’uso. Molte aziende basano molti dei loro processi di business chiave proprio su
dei programmi custom e, negli anni, può accumularsi una grande quantità di codice
custom non ben documentato, ma fondamentale per il corretto funzionamento dei
processi. Data la sostanziale differenza architetturale di S/4HANA rispetto a SAP ECC,
molti di questi programmi custom smetteranno di funzionare correttamente causando
errori di ogni tipo. Se per alcuni di questi programmi basterà attuare qualche operazione
di manutenzione, per molti di essi sarà necessario riscrivere l’intera logica sottostante
per via dei sostanziali cambi alla struttura del database. Questa operazione, che prende
il nome di Custom Code Remediation, rappresenta uno degli step più impegnativi in
assoluto del progetto di migrazione.
Alla luce di queste sfide, è interessante una ricerca svolta dalla società Nucleus Research
al fine di analizzare l’esperienza utente dei clienti SAP. Dalla ricerca emerge che 6 clienti su
10, potendo tornare indietro, non riacquisterebbero una soluzione SAP e, dato ancora più
preoccupante, 9 clienti su 10 non vogliono effettuare la migrazione. Come si può osservare in
Figura 3.2, il deterrente principale è rappresentato dall’alto costo di implementazione.
Figura 3.2: Panoramica delle motivazioni per cui le aziende evitano la transizione a SAP S/4HANA
Per meglio comprendere l’impatto dei possibili rischi associati alla migrazione a SAP
S/4HANA, nelle seguenti sotto-sezioni, sono presentati alcuni esempi reali di progetti di
migrazione falliti.
Caso LeasePlan
Nel 2019, LeasePlan, un compagnia tedesca che si occupa di soluzioni per il leasing ed
il noleggio a lungo termine di automobili, fu costretta a terminare la propria implementa-
zione di S/4HANA. La compagnia opera tramite molteplici sedi in tutto il mondo, con una
infrastruttura digitale composta da oltre 35 sistemi differenti.
L’idea di consolidare e allineare tutti questi sistemi sotto un unico, grande e monolitico si-
stema SAP S/4HANA sembrava inizialmente un’ottima strategia di innovazione che avrebbe
permesso di standardizzare e di ridurre la complessità dei sistemi utilizzati. Inoltre, si volle
approfittare dell’occasione per riprogettare alcuni dei processi e delle strategie aziendali. La
visione di SAP S/4HANA, tuttavia, difficilmente si allinea a repentini cambi del modello di
business e, in aggiunta, l’azienda, invece che scaglionare il processo di migrazione, decise di
effettuare la migrazione in tutte le sedi contemporaneamente.
Una scarsa valutazione dei rischi e una scarsa strategia di risposta ai rischi si scontrò
con la complicata e massiccia operazione di migrazione intrapresa dall’azienda. Inoltre, ci
furono problemi nella pianificazione delle sessioni di training agli utenti finali. Questi ultimi,
utilizzando il solito sistema per anni, rigettarono il nuovo sistema per via della sua massiccia
differenza rispetto alle precedenti soluzioni aziendali.
In conclusione, il progetto fu un fallimento totale e fece perdere all’azienda oltre 100
milioni di dollari.
Caso Lidl
Lidl, nota catena di supermercati, fece ritorno ai propri sistemi legacy di gestione dell’in-
ventario dopo il fallimento del progetto di migrazione a S/4HANA. La compagnia investì
circa 500 milioni di euro e 7 interi anni cercando di implementare il nuovo ERP.
I problemi implementativi furono largamente causati dall’incompatibilità tra le gestione
dei processi di business e la gestione del magazzino adottata da Lidl e S/4HANA. Nonostante
gli incessanti sforzi nel cercare di personalizzare e adattare il sistema alle proprie necessità,
S/4 HANA risultava semplicemente incompatibile con la visione di Lidl.
Un’altra problematica fu la fede cieca che il reparto Executive della compagnia ripose
nei consulenti, affidando loro completamente l’intero processo di migrazione. In aggiunta,
durante il processo di implementazione, ci fu una notevole riorganizzazione del personale
Executive creando ulteriore confusione riguardo le ownership dei task di progetto.
Caso National Grid

L’implementazione fallimentare di SAP S/4HANA da parte di National Grid, grande
multinazionale di servizi elettrici, rimane uno dei casi peggiori. National Grid per l’im-
plementazione si affidò a Wipro, grande società di consulenza. Il progetto, tuttavia, fu un
disastro tale da comportare diverse cause legali. National Grid accusò Wipro di aver fornito
dei consulenti altamente impreparati per il progetto, generando problemi nella migrazione
dei dati e nella progettazione in generale. L’azienda incorse in gravi problemi di auditing a
causa del progetto e Wipro fu costretta a risarcire oltre 75 milioni di dollari.
La situazione era talmente drammatica che, a poche settimane dal rilascio effettivo, il
sistema SAP non era in grado di processare correttamente i pagamenti verso i fornitori
e il sistema di gestione degli stipendi presentava gravissimi problemi. Alcuni dipendenti
ricevettero paghe doppie mentre altri non ricevettero alcuno stipendio, causando una perdita
di circa 8 milioni di dollari. In aggiunta, erano presenti gravi problematiche nel sistema di
gestione della supply chain e dell’approvvigionamento dei materiali, causando un’ulteriore
perdita di 3 milioni di dollari.
3.2 − Processo di migrazione a SAP S/4HANA 31
3.1.3 Motivazioni della migrazione

La migrazione al nuovo sistema S/4HANA è un’attività molto complessa che coinvolge
tutte le aeree dell’azienda. La quasi totalità delle aziende eviterebbe tranquillamente la
migrazione al nuovo sistema a meno di serie motivazioni che giustifichino l’avvio di un
progetto di tale portata.
Le grandi aziende sono note per essere restie al cambiamento in generale; nel caso di
un software come SAP, la situazione è ancora più delicata. SAP, ma anche qualsiasi altro
gestionale di altre società, rappresenta il cuore di un’azienda, e una qualsiasi modifica, anche
se di piccola entità, mette tutti in allarme.
Un altro aspetto da considerare è che una grande fetta dei clienti SAP è costituita da
aziende di dimensioni contenute. Tali aziende, spesso, si limitano ad utilizzare il sistema SAP
per svolgere i propri affari e non dispongono, quindi, di reparti IT con profonde conoscenze
tecniche del software. In questi casi, i vantaggi in termini di performance, intelligenza
artificiale e architetture cloud presentati da S/4HANA non suscitano alcun interesse. Difatti,
queste aziende preferiscono semplicemente continuare ad utilizzare il sistema attuale in
modo da non stravolgere i processi aziendali ed incappare in costi esorbitanti.
L’azienda oggetto della presente tesi cade proprio in questa categoria. Essa, infatti, basa il
proprio business sulla vendita di prodotti per l’igiene personale e, ad eccezione delle attività
di Data Science e Business Intelligence, la priorità è che il sistema SAP funzioni correttamente.
Il motivo principale che sta spingendo le aziende ad effettuare la transizione a SAP
S/4HANA è un annuncio fatto dalla stessa SAP. La società, infatti, ha annunciato la fine del
supporto per SAP ECC entro il 2025, destando moltissime critiche e lamentele.
Quando SAP interrompe il supporto ad una data versione del software, esso rimane
ancora utilizzabile; tuttavia, in caso di problemi di qualsiasi tipo, non si avrà nessuna ga-
ranzia di supporto dalla società. In ottica aziendale, questo aspetto risulta di fondamentale
importanza. Difatti, un’azienda non può assolutamente permettersi di perdere dei dati o di
comprometterne la consistenza.
Le critiche mosse a SAP riguardo il termine del supporto a SAP ECC sono in buona parte
dovute al pesante vendor lock-in. Difatti, dal momento in cui un’azienda adotta una soluzione
SAP, le risulterà molto difficile e costoso re-implementare i propri sistemi in una soluzione
ERP di altri fornitori. Questa motivazione rende il passaggio a S/4HANA implicitamente
obbligato ed è, ad oggi, il motivo principale che spinge le aziende alla migrazione. Infatti,
anche se avviare il progetto di migrazione risulta molto costoso in termini di denaro e tempo,
lo è molto di più passare ad una soluzione di un altro fornitore.
3.2 Processo di migrazione a SAP S/4HANA

Come esposto nella precedente sezione, la migrazione a SAP S/4HANA non è un semplice
aggiornamento di un’applicazione sul proprio computer o smartphone, bensì rappresenta un
complesso upgrade tecnologico e infrastrutturale. SAP stessa, per il processo di migrazione,
consiglia fortemente di affidarsi alle aziende di consulenza certificate partner SAP.
Nelle seguenti sotto-sezioni verranno dettagliati alcuni dei passaggi fondamentali ai fini
di una corretta migrazione.
3.2.1 Best Practices SAP

Con SAP Best Practices si fa riferimento alla piattaforma di contenuti SAP (Figura 3.3)
che definisce le best practice per la gestione delle attività aziendali, come gli acquisti, la
produzione, la gestione degli ordini, etc. e permette di implementarle rapidamente con una
cosiddetta “Rapid Deployment Solution” (soluzione di implementazione rapida). Le best

practices sono pacchetti modulari testati e preconfigurati, che includono la documentazione
necessaria e consentono l’implementazione immediata di funzionalità aziendali in SAP.
Figura 3.3: Interfaccia della libreria delle SAP Best Practices
Il contenuto della raccolta di best practices viene generato a partire dall’esperienza di

SAP e dei consulenti del settore; esse sono continuamente aggiornate per far fronte alle
più recenti tendenze e per includere le innovazioni tecnologiche. Le best practice derivano
dall’esperienza accumulata da SAP e da decine di partner in quasi 50.000 implementazioni
del sistema in oltre 50 paesi. Esse si compongono di due elementi principali: la descrizione di
quello che viene considerato il processo standard e una descrizione di come il software deve
essere configurato per gestire il processo. Più in dettaglio, il loro contenuto è composto da:
• Software: i prodotti software SAP e le relative licenze necessarie per il funzionamento

del pacchetto.
• Contenuto dell’implementazione: una descrizione in dettaglio di come il processo deve

essere configurato nel sistema.
• Descrizione del processo aziendale: un documento che descrive il processo in forma grafica
(diagrammi di flusso) e testuale.
• Master Data: dei dati di esempio di una cosiddetta “società modello”, con una struttura
organizzativa tipica da cui partire per configurare la best practice nel contesto della
propria struttura.
• Casi di test: dei test pronti all’uso utili per verificare il corretto funzionamento dell’in-
stallazione.
L’utilizzo delle SAP Best Practices aiuta le aziende a disegnare dei processi aziendali che:
• rispettano i requisiti legali del paese in cui si opera;
• registrano i movimenti finanziari rilevanti;
• permettono di generare dei report significativi
• si integrano con altri prodotti e con altri processi aziendali.

Riguardo il processo di migrazione a S/4HANA, SAP ha creato una libreria di best

practice apposite denominata “SAP Best Practices for SAP S/4HANA”, essa è suddivisa, come
mostrato in Figura 3.4, per aree aziendali.
Figura 3.4: Aree toccate dalla raccolta di best practice per SAP S/4HANA
Una volta selezionata una particolare best practice, come si può osservare in Figura
3.5, è possibile leggere una sua breve descrizione ed accedere alla pagina dove sarà pos-
sibile effettuare il download. Nella pagina di download, inoltre, saranno presenti una de-
scrizione estesa della soluzione, i requisiti necessari ed una guida dettagliata a supporto
dell’implementazione.
Figura 3.5: Dettaglio della libreria delle best practice per SAP S/4HANA
SAP, per tutti i progetti di migrazione a S/4HANA, consiglia fortemente di seguire le

best practice maturate da altre aziende che hanno già effettuato la transizione. Nel caso
in cui la soluzione proposta da una Best Practice SAP per un particolare modello di bu-
siness non rispecchia appieno la visione aziendale, è possibile utilizzarla solo come base
di partenza ed effettuare delle personalizzazioni. Questo approccio permette di evitare di
partire completamente da zero e migliora il time to value accelerando l’implementazione della

soluzione.
3.2.2 Metodologia SAP Activate

SAP Activate è la metodologia proposta da SAP per la migrazione a SAP S/4HANA ed è
adottata da quasi tutti i consulenti partner SAP. La metodologia, come si osserva in Figura
3.6, si compone di sei fasi, ovvero:
1. Discover;
2. Prepare;
3. Explore;
4. Realize;
5. Deploy;
6. Run.
Figura 3.6: Diagramma di flusso della metodologia SAP Activate
Nelle prossime sottosezioni esamineremo in dettaglio queste sei fasi.
Discover
La fase “Discover” ha inizio quando il cliente si rende conto che c’è bisogno di una
soluzione per soddisfare un requisito di business aziendale e inizia a cercare la soluzione
SAP che risulta essere più conforme ai propri requisiti. Durante questa fase, i clienti possono
richiedere una soluzione di prova gratuita, se applicabile, e provarla personalmente per
verificare le sue caratteristiche e le funzionalità. I clienti possono, inoltre, rivolgersi ai partner
per ottenere consigli di consulenza basati su anni di esperienza nel settore e sui prodotti SAP.
Entro la fine di questa fase, i clienti decidono se procedere o meno con la soluzione SAP
richiesta e passare alla fase successiva del ciclo di vita dell’implementazione.
Prepare
Come suggerisce il nome, la fase “Prepare” è cruciale sia per i clienti che per i partner
in quanto ci si prepara ad affrontare le attività fondamentali per il successo del progetto.
Il sistema da implementare viene fornito al cliente dopo la firma del contratto con SAP
e il partner. Allo stesso tempo, le risorse chiave vengono identificate dal lato del partner
in termini di on-boarding e abilitazione dei consulenti SAP. Dal lato del cliente, vengono
identificati i proprietari dei processi aziendali per fornire i giusti requisiti ai consulenti che
implementano il progetto. Insieme al team di progetto viene finalizzato un piano di progetto
ad alto livello che definisce ruoli e responsabilità, le procedure di governance e la matrice di

escalation.
Durante questa fase, vengono raccolti i requisiti iniziali tramite la compilazione di un que-
stionario di valutazione fornito dai partner agli owner del progetto. Sulla base delle risposte
ottenute dalla valutazione, i consulenti devono pianificare la fase successiva e, probabilmente,
più importante della metodologia SAP Activate, ovvero la fase di esplorazione.
Explore
La fase “Explore” pone le fondamenta per il successo del progetto. Durante questa
fase, clienti e partner collaborano tra loro per il raggiungimento di un unico, fondamentale,
risultato: consolidare il processo di business da seguire nel nuovo sistema SAP. Questo
viene fatto attraverso diverse sessioni denominate Fit-to-Standard Analysis, in cui le soluzioni
presenti nelle SAP Best Practice che, secondo i partner, meglio combaciano con la visione
dell’azienda cliente, vengono presentate agli owner di progetto. Vengono effettuate, a questo
punto, una serie di incontri tra il team di progetto e i consulenti partner finché entrambe le
parti si accordano sul disegno di implementazione da seguire.
Verso la fine di questa fase vengono formalizzati tutti i requisiti richiesti dal cliente in
termini di worflow, report, integrazioni, conversioni ed enhancements, nonché tutti parametri
di configurazione in un documento di backlog. Il documento di backlog conterrà, dunque,
tutte le funzionalità che dovranno essere presenti sul nuovo sistema SAP per permettere
agli utenti aziendali di svolgere le loro attività quotidiane. Sempre da tale documento, i
consulenti partner pianificano le attività da svolgere nella fase di Realize in base alle priorità
e alla fattibilità. Viene, inoltre, svolta un’analisi degli impatti sul sistema al fine di pianificare
sessioni di trainining per gli utenti finali.
Realize
Una volta terminata la fase di Explore, il team di progetto può iniziare a lavorare sul
server contenente il sistema di qualità fornito da SAP. In questa fase, i consulenti iniziano
a configurare il sistema sulla base del documento di backlog. Ciò avviene con un approccio
iterativo in cui il team di progetto pianifica diversi sprint in ottica Agile. Lo scopo di ogni
sprint è quello di scomporre il documento di backlog in deliverable. Questi ultimi andranno
presentati al team che, valutandone la correttezza, deciderà se approvarli o meno.
Durante questa fase, inoltre, verranno condotte diverse tipologie di test, tra cui: gli unit
test, gli integration test e gli UAT (User Acceptance Test). Lo scopo di questi test è garantire
che il comportamento atteso dal sistema e quello effettivo combacino.
Deploy
Una volta che tutti i deliverables sono stati consegnati, si passa alla fase di Deploy. L’a-
zienda, in questa fase, va incontro ad una temporanea interruzione della propria soluzione
SAP per permettere la migrazione dei dati nel database dalla vecchia versione alla nuova.
Questo processo viene chiamato cutover e, tipicamente, viene svolto durante il week-end per
minimizzare l’impatto sui processi aziendali.
Run
Terminato il processo di cutover, ci si ritrova nella fase di Run. Durante questa fase
l’azienda inizia ad utilizzare il nuovo sistema, e l’attività principale da svolgere è l’Hyper-Care
agli utenti finali. Queste attività di supporto agli utenti risultano di fondamentale importanza
per assicurarsi che i dipendenti dell’azienda non incontrino problemi durante l’utilizzo del
nuovo sistema.
3.2.3 Custom Code Remediation

Un’ulteriore attività da svolgere nel processo di migrazione a SAP S/4HANA è la cosid-
detta Custom Code Remediation. Tale attività, brevemente, riguarda la manutenzione dei
programmi ABAP custom. In questa manutenzione, gli input e gli output dei programmi
rimangono gli stessi e l’utente finale non percepisce alcuna differenza nelle funzionalità e
nelle modalità di utilizzo tra la vecchia e la nuova versione del programma.
Molte aziende utilizzano la programmazione ABAP per sviluppare programmi perso-
nalizzati all’interno di SAP. Questi programmi, spesso, si interfacciano con i programmi
standard SAP già presenti nel sistema, modificando o estendendo il loro funzionamento.
Non è raro, quindi, ritrovarsi con quantità significative di programmi custom sviluppati per
implementare vari automatismi o per rispondere ad esigenze di business non coperte dalle
soluzioni standard.
Come schematizzato in Figura 3.7, il codice ABAP custom interagisce con determinati
programmi standard e tabelle standard del database SAP ma, nel nuovo sistema S/4HANA,
alcuni tra questi programmi standard sono stati semplificati, rimossi o modificati; lo stesso
vale per alcune tabelle del database. Per evitare problemi ed errori durante l’esecuzione dei
programmi custom sul nuovo sistema essi vanno riadattati o re-implementati.
Figura 3.7: Schematizzazione grafica della Custom Code Remediation
Come si può osservare in Figura 3.8, la Custom Code Remediation inizia con il Custom
Code Scoping, ovvero con un’analisi dell’utilizzo dei programmi custom al fine di ricavarne il
numero di esecuzioni in un determinato periodo. Difatti, se vengono individuati programmi
che non sono più utilizzati o con un numero di esecuzioni molto basso, si può pensare di
renderli obsoleti ed evitare di adattarli. Fatto ciò, si passa alla Custom Code Analysis con
lo scopo di identificare gli interventi da effettuare nel codice. Questi ultimi possono essere
semplici modifiche alle query SQL così come profonde riprogettazioni dell’intera logica del
programma.
Sempre in riferimento alla Figura 3.8, arrivati alla fase di Realization, tutte le modifiche
precedentemente identificate vengono implementate e testate. Durante questa fase, inoltre,
è possibile sostituire alcune vecchie funzionalità del codice ABAP con altre più moderne
presenti in S/4HANA. Tali sostituzioni, oltre che a rendere il codice più moderno, permettono
alle applicazioni di sfruttare appieno la velocità del database HANA.
3.3 − Strategia di migrazione adottata 37
Figura 3.8: Diagramma di flusso della Custom Code Remediation
3.3 Strategia di migrazione adottata

Nell’azienda oggetto del presente documento, la strategia di migrazione adottata è in linea
con quanto descritto nelle precedenti sezioni. Per supportare il reparto ICT aziendale nella
migrazione, l’azienda si appoggia a due diverse aziende di consulenza. Di queste aziende,
una è incaricata di seguire il processo di migrazione; l’altra, invece, si occupa principalmente
di fornire supporto nelle attività di Custom Code Remediation.
L’azienda, internamente, è strutturata in diversi “pillar” (aree aziendali), come mostrato
in Figura 3.9.
Figura 3.9: Rappresentazione dei pillar aziendali
In particolare, sono presenti i seguenti pillar:

• Finance: area che si occupa della gestione finanziaria e della contabilità aziendale.
• Procure to Pay: area che gestisce il processo che va dalla creazione di una richiesta
d’acquisto fino al pagamento del fornitore.
• Order to Cash: area che gestisce il processo che va dalla ricevuta di un ordine fino al suo
pagamento da parte del cliente.
• Warehouse Management: area che si occupa della gestione e della logistica del magazzino.
• Transportation Management: area che si occupa della gestione della logistica dei trasporti.
• Plan to Product: area che si occupa della gestione del processo manifatturiero.
La roadmap di progetto è molto articolata; tuttavia, in Figura 3.10, è possibile osservare

un estratto della pianificazione della prima fase di migrazione, in particolare della fase di
Explore. Il progetto nella sua interezza è composto da numerose roadmap, simili a quella
appena presentata, che dettagliano i vari step da eseguire all’interno della metodologia SAP
Activate.
Figura 3.10: Roadmap della prima fase di migrazione
Al nostro arrivo in azienda, il progetto si trovava a cavallo tra la fase di Explore e la fase
di Realize e siamo stati inseriti a supporto del pillar Procure to Pay.
3.3.1 Struttura del team di progetto

Oltre ai consulenti esterni, della gestione del progetto se ne occupa anche il reparto ICT
interno all’azienda. Tale reparto si compone di diversi piccoli gruppi (dalle 4 alle 5 persone),
ciascuno dei quali si occupa di un proprio pillar aziendale.
In Figura 3.11 è presente l’organigramma ad alto livello del progetto; come si può notare,
questo è gestito tramite la classica metodologia PMI (Project Management Institute). Nel-
l’organigramma, i vari sottogruppi di progetto riferiscono al team di Project Management,
mentre quest’ultimo si interfaccia con lo Steering Commitee (il quadro dei dirigenti) e con il
PMO (Project Management Office).
I team di progetto sono guidati da un ICT Team Leader a cui fanno riferimento uno o più
ICT Specialist. Il compito dei team leader è quello di interfacciarsi con il Project Manager e
assegnare i vari task da eseguire agli ICT Specialist.
Per quanto riguarda, invece, il modello di Governance adottato si può fare riferimento alla
Figura 3.12. In particolare, si può osservare come, per ogni area, viene effettuata, due volte al
mese, una riunione in cui si riassume l’andamento generale del progetto e si condividono
i problemi emersi. Una volta al mese, invece, avviene un incontro generale di tutte le aree
al fine di allineare tutti i team sull’evoluzione complessiva del progetto. Infine, ogni sei
settimane avviene l’incontro con il consultivo aziendale, in cui il Project Manager riferisce lo
sviluppo del progetto mentre, ogni due mesi, oppure su richiesta, si esegue una riunione con
i dirigenti aziendali.
Figura 3.11: Modello di Governance del progetto
Figura 3.12: Modello di Governance del progetto
3.3.2 Tipologie di approccio alla migrazione

Per la migrazione a S/4HANA, SAP propone tre diversi approcci: approccio Greenfield,
approccio Brownfield e un approccio ibrido.
L’approccio Greenfield indica una nuova implementazione, permettendo di riprogettare
i sistemi e i flussi aziendali da zero. Questo approccio si applica automaticamente se l’a-
zienda attualmente non utilizza alcuna soluzione ERP SAP; tuttavia, anche se si è già in
possesso di un ERP SAP si può scegliere questo approccio. Esso permette di abbandonare i
processi di business obsoleti o inconsistenti e progettarne dei nuovi. Nonostante il sistema
sia completamente nuovo, è comunque possibile migrare i vecchi dati all’interno della nuova
soluzione.
Tra i vantaggi dell’approccio troviamo:
• sistema completamente nuovo ed uniforme;

• implementazione delle SAP Best Practice;
• vantaggi nell’utilizzo di soluzioni standardizzate.
Gli aspetti negativi, invece, sono:
• maggior quantità di test da eseguire;
• implementazione più lenta;
• costi di implementazione maggiori.
L’approccio Brownfield, invece, consiste nella conversione del vecchio sistema SAP ECC a
SAP S/4HANA. I processi esistenti, i dati e tutti i programmi custom implementati vengono
trasferiti nel nuovo sistema così come sono. Tale approccio è quello più utilizzato dalle
aziende dato che mantiene i costi di implementazione contenuti e non stravolge la struttura
dei processi aziendali.
I vantaggi dell’approccio Brownfield sono:
• possibilità di scegliere cosa migrare e cosa no;
• minor impatto sui processi di business;
• minor tempo di implementazione;
Invece, tra gli svantaggi troviamo:
• minor compatibilità con i futuri aggiornamenti di SAP;
• complessità del progetto maggiore rispetto all’approccio Greenfield;
• impossibilità di trarre vantaggio dalle nuove soluzioni standard SAP.
Oltre ai due approcci appena descritti è possibile anche adottare uno schema ibrido.
L’azienda oggetto della presente tesi, infatti, adotta un approccio Greenfield per alcuni pillar
aziendali e l’approccio Brownfield per altri.
3.3.3 Tools Renovation

In azienda, approfittando del progetto di migrazione, è stato avviato anche un processo
denominato “Tool Renovation”. Lo scopo di tale processo è quello di modernizzare alcuni
programmi custom utilizzati in SAP o di implementarne dei nuovi.
Tra i vari tool da modernizzare, uno in particolare è stato assegnato alla nostra area di
competenza, ovvero il tool per la gestione dei listini dei fornitori. Esso si occupa della gestione
dei listini contenenti i prezzi per i materiali venduti da uno specifico fornitore da parte dei
“buyer” aziendali.
Inoltre, sempre nell’ambito di questo processo, è stata commissionata l’implementazione
di un tool per la gestione delle tolleranze in eccesso e in difetto dei materiali in magazzino.
Nei Capitoli 4 e 5 verranno esposte in dettaglio la riprogettazione e l’implementazione
dei due tool.
CAPITOLO 4
Implementazione del tool per la gestione delle tolleranze
In questo capitolo verrà brevemente introdotto l’obiettivo del tool per la gestione delle tolleranze. Inizial-
mente verrà introdotto il processo aziendale nel quale il tool si colloca e, successivamente, verranno esposti i
principali dettagli implementativi.
4.1 Analisi dei requisiti di business

Come accennato nel capitolo precedente, nell’ambito della Tools Renovation, dal pillar
Warehouse Management è emersa la necessità di un tool che semplificasse la gestione delle
tolleranze di magazzino.
In azienda, i “planner”, ovvero le figure che si occupano della pianificazione dell’approv-
vigionamento dei materiali, hanno la possibilità di definire dei limiti di tolleranza per un
determinato materiale. La funzione di tali limiti è quella di permettere all’addetto all’entrata
merci di accettare una consegna, da parte del fornitore, di una quantità superiore o inferiore
a quella effettivamente ordinata.
Ad esempio, ordinando 100 cartoni di un materiale, con una tolleranza in eccesso del 20%,
se il fornitore trasporta un surplus di tale materiale potrà scaricare al magazzino dell’azienda
dai 100 ai 120 cartoni. Il funzionamento è analogo per il parametro di tolleranza in difetto,
ovvero il fornitore potrà scaricare alcuni cartoni di materiale in meno rispetto alla quantità
ordinata dal planner.
4.1.1 Introduzione al processo aziendale

In SAP, un contratto (chiamato anche “contratto quadro”) è un accordo a lungo termine
tra un’azienda e un fornitore per la fornitura di articoli o per la distribuzione di servizi. Come
si può osservare in Figura 4.1, ogni contratto presenta un codice identificativo (evidenziato in
rosso) e il codice del fornitore associato (evidenziato in verde). Un contratto può interessare
più materiali (evidenziati in viola) e, per ogni materiale, viene indicata la divisione e il
magazzino predefinito (evidenziati in giallo).
Nel contratto, ogni materiale rappresenta una “posizione”, indicata tramite un numero
progressivo (ad esempio, 10, 20, etc.). In Figura 4.2 è presentato il dettaglio di una posizione
del contratto. In questa videata, entrando in modifica, è possibile modificare manualmente i
campi relativi alla tolleranza in eccesso e in difetto (evidenziati in rosso) e i campi relativi al
magazzino e alla divisione (evidenziati in giallo).
41
4.1 − Analisi dei requisiti di business 42
Figura 4.1: Videata di un contratto SAP
Figura 4.2: Videata di un contratto SAP: dettaglio di una posizione
Per ragioni di privacy, il reale processo aziendale non può essere mostrato. Tuttavia, in
Figura 4.3, viene presentata una versione semplificata del processo di riferimento. Come si
osserva, il processo parte dal planner che effettua una pianificazione dei materiali necessari
per la produzione, indicandone il magazzino di consegna ed eventuali tolleranze. Successi-
vamente, le pianificazioni effettuate dai planner vengono elaborate dal modulo MRP. Tale
modulo si occupa, tramite l’omonimo algoritmo, di calcolare come e quando effettuare gli
acquisti, tenendo conto di molti fattori tra cui i tempi di consegna e la capacità produttiva
dell’azienda. Dal modulo MRP verranno, dunque, generate delle “Richieste d’Acquisto”
(spesso denominate “RdA”) che, dopo un processo di approvazione, vengono trasformate in
“Ordini d’Acquisto” (spesso denominati “OdA”). Un’OdA è l’effettivo acquisto di una lista di
articoli e contiene al suo interno molti parametri, tra cui i valori delle tolleranze, il magazzino
di consegna e la divisione. Il processo termina quando il fornitore effettua la consegna della
merce al magazzino designato e un addetto registra il documento di entrata merci.
Figura 4.3: Diagramma del processo aziendale di riferimento
4.1.2 Traduzione dei requisiti di business in requisiti tecnici

Come appena visto, i parametri delle tolleranze e del magazzino sono campi contenuti
nelle posizioni di contratto. I planner aziendali non si occupano di gestire i contratti, essendo
compito dei “buyer”. Ciò innesca uno scomodo meccanismo in cui ai buyer arrivano, da
parte dei planner, richieste di modifica delle tolleranze per determinati materiali.
Da questa problematica nasce la richiesta di un tool che permetta ai planner di definire le
tolleranze e il magazzino per determinate categorie di materiali in modo agevole. Successiva-
mente, questi parametri dovranno essere aggiornati nei contratti da un sistema automatico,
evitando la lenta modifica manuale.
In azienda era già presente un tool che permetteva ai planner di definire, sulla base
del codice materiale, alcuni parametri utilizzati dal modulo MRP. Quindi, per evitare di
realizzare il nuovo tool partendo completamente da zero, si è scelto di implementare le nuove
funzionalità come estensione del tool preesistente.
In particolare, compresi i “business need” dei planner, sono stati sintetizzati i seguenti
requisiti tecnici:
• il nuovo tool dovrà integrarsi con il tool preesistente, con il quale i planner hanno già
familiarità;
• il tool dovrà permettere di “valorizzare” le tolleranze e il magazzino per gruppi di
materiali affini, evitando di dover aggiornare i singoli materiali;
• è necessario prevedere la possibilità di definire dei materiali in eccezione;
• è necessario garantire l’aggiornamento automatico dei rispettivi campi delle tolleranze
e del magazzino nei contratti, evitando l’azione manuale da parte dei buyer.
Per operare con più materiali contemporaneamente è stato possibile sfruttare una fun-
zionalità standard SAP, ovvero i Product Group (gruppi prodotto). I gruppi prodotto sono,
semplicemente, dei contenitori per diversi codici di materiale. Una volta identificati dei
materiali “affini”, ad esempio materiali diversi necessari alla realizzazione di uno stesso
prodotto finito, è possibile inserire i rispettivi codici materiale all’interno di un gruppo pro-
dotto. Questa funzionalità permette ai planner di ragionare per gruppo prodotto ed evitare
di elaborare singolarmente i materiali.
In Figura 4.4 si può osservare un esempio di un gruppo prodotto, con i relativi codi-
ci materiale associati. La definizione dei vari gruppi prodotto e la successiva associazio-
ne dei materiali di interesse sono operazioni da effettuare a priori e, quindi, out-of-scope
dall’implementazione del nuovo tool.
4.2 − Implementazione dei requisiti 44
Figura 4.4: Videata di un gruppo prodotto
In conclusione, definiti tutti i requisiti tecnici del tool, è stato realizzato il diagramma
presentato in Figura 4.5 che ne riassume il funzionamento. In maniera completamente tra-
sparente all’utente, per l’effettivo aggiornamento dei contratti, si è scelto di sviluppare un
tool secondario al fine di semplificare la logica del programma. Al tool per la gestione delle
tolleranze e a quello per l’aggiornamento dei contratti, sono stati assegnati, rispettivamente, i
nomi tecnici ZMRPE_GP e ZUPD_CONTR.
Figura 4.5: Diagramma di flusso per il tool ZMRPE_GP
4.2 Implementazione dei requisiti

Con i requisiti tecnici in mano è possibile procedere, tramite l’utilizzo della programma-
zione ABAP, all’implementazione delle funzionalità richieste. Nelle successive sotto-sezioni
verranno esposti, dunque, alcuni dettagli implementativi per ZMRPE_GP e ZUPD_CONTR.
4.2.1 ZMRPE_GP
Il codice dell’intero tool risulta molto articolato e prolisso, motivo per cui verranno
evidenziati soltanto i passaggi chiave, in accordo con quanto visto nel diagramma in Figura
4.5.
Il primo step consiste nel permettere al planner di selezionare il gruppo prodotto di
interesse. Per fare ciò, in ABAP, è possibile generare delle schermate di selezione in cui
l’utente può inserire tutti i dati necessari. Nella maggior parte dei casi, i parametri inseriti
nella schermata di selezione vengono utilizzati per effettuare le query sul database SAP;
tuttavia, nulla impedisce di usare questi parametri come normali variabili all’interno del
programma.
Tramite il codice presente nel Listato 4.1 è possibile definire la schermata di selezione
mostrata in Figura 4.6. Tale schermata permette al planner di inserire il gruppo prodotto di
interesse e la rispettiva divisione; difatti, uno stesso gruppo prodotto può essere definito per
più divisioni.
1 SELECTION-SCREEN BEGIN OF BLOCK b01 WITH FRAME TITLE text-b01.

2 PARAMETERS: p_werks TYPE werks_d DEFAULT '1100' OBLIGATORY.
3 PARAMETERS: p_attiv AS CHECKBOX DEFAULT 'X'."solo gruppi attivi
4
5 SELECT-OPTIONS: so_prgrp FOR pgmi-prgrp,
6 so_nrmit FOR pgmi-nrmit,"materiale
7 so_lifnr FOR zmcoduss-lifnr,
8 so_plann FOR zmcoduss-zplanner,
9 s_liftp FOR zmcoduss-zforsmoi."tipo fornitore
10 SELECTION-SCREEN END OF BLOCK b01.
11
12 SELECTION-SCREEN BEGIN OF BLOCK b02 WITH FRAME TITLE text-b13.
13 PARAMETERS: rb_going TYPE c RADIOBUTTON GROUP par DEFAULT 'X',
14 rb_obsol TYPE c RADIOBUTTON GROUP par,
15 rb_all TYPE c RADIOBUTTON GROUP par.
16 SELECTION-SCREEN END OF BLOCK b02.
Listato 4.1: Definizione della schermata di selezione
Figura 4.6: Schermata di selezione per ZMRPE_GP
Utilizzando i parametri inseriti dall’utente nella schermata di selezione, tramite il codice

presente nel Listato 4.2, vengono effettuate due query sul database. La prima query viene
effettuata sulla tabella standard pgmi, contenente i gruppi prodotto definiti a sistema. La
seconda query, invece, seleziona i dati dalla tabella custom zmcoduss, generata a supporto
del tool e contenente i dati relativi all’MRP e alle tolleranze dei gruppi prodotto. Una volta
recuperati i dati dal database è possibile mostrarli all’utente tramite delle liste ALV. Una ALV
è un “contenitore” dell’interfaccia grafica SAP in grado di visualizzare agevolmente diverse
tipologie di dati. Nella maggior parte dei casi le liste ALV vengono utilizzate per mostrare
dati tabellari in modo interattivo come, ad esempio, il risultato delle query.
1 SELECT prgrp werks nrmit FROM pgmi

2 INTO CORRESPONDING FIELDS OF TABLE lt_out
3 WHERE prgrp IN so_prgrp
4 AND werks = p_werks
5 AND nrmit IN so_nrmit.
6
7 SORT lt_out BY prgrp ASCENDING.
8 DELETE ADJACENT DUPLICATES FROM lt_out.
9
10 SELECT * FROM zmcoduss
11 INTO CORRESPONDING FIELDS OF TABLE lt_zmcoduss
12 FOR ALL ENTRIES IN lt_out
13 WHERE matnr = lt_out-prgrp
14 AND lifnr IN so_lifnr
15 AND zplanner IN so_plann
16 AND zforsmoi IN s_liftp.
17
18 SORT lt_zmcoduss BY lifnr ASCENDING.
Listato 4.2: Query di selezione sul database SAP
Come si osserva in Figura 4.7, la schermata principale di ZMRPE_GP si compone princi-

palmente di due ALV. La prima, evidenziata in rosso, era già presente nel tool preesistente e
permette al planner di gestire i singoli codici materiale di un gruppo prodotto. La seconda
ALV, evidenziata in verde, mostra i dati selezionati tramite le query del Listato 4.2. In partico-
lare, si possono osservare i campi relativi al magazzino e alle tolleranze in difetto e in eccesso.
La ALV in questione mostra tre righe dal momento che il gruppo prodotto selezionato è
associato a tre codici fornitore differenti.
Figura 4.7: Schermata principale di ZMRPE_GP
In Figura 4.8 è possibile osservare un dettaglio della ALV per l’inserimento dei dati da
parte del planner. Nello specifico, evidenziati in viola, sono presenti i campi per inserire le
tolleranze in eccesso e in difetto ed, evidenziato in verde, il campo per l’inserimento del
magazzino. Evidenziati in giallo, invece, sono visualizzati due campi di controllo per l’utente
che indicano, rispettivamente partendo da sinistra, la data dell’ultima modifica e una sigla
che notifica lo stato di aggiornamento dei contratti (S: tutti i contratti sono aggiornati, W:
aggiornamento pianificato).
Sempre in riferimento alla Figura 4.8, evidenziati in rosso sono presenti tre pulsanti che
permettono di gestire i materiali in eccezione. Partendo da sinistra, il pulsante “Aggiun-
gi eccezione” permette al planner di definire un materiale in eccezione per quel gruppo
Figura 4.8: Dettaglio della ALV per l’inserimento dati
prodotto, come mostrato in Figura 4.9. Per i codici materiale in eccezione, quando avverrà
l’aggiornamento dei contratti tramite ZUPD_CONTR, verranno considerati gli specifici valori
inseriti dal planner invece che i valori globali del gruppo prodotto di riferimento.
I pulsanti “Mostra mat. eccezione” e “Rimuovi eccezione”, invece, permettono, rispetti-
vamente, di mostrare i materiali in eccezione già inseriti per il gruppo prodotto selezionato
e di rimuovere un’eccezione. In Figura 4.10 sono presentate le schermate generate dai due
pulsanti appena descritti.
Figura 4.9: Schermata generata dal pulsante “Aggiungi eccezione”
Figura 4.10: Schermate generate dai pulsanti “Mostra mat. eccezione” e “Rimuovi eccezione”
Il planner, una volta inseriti i valori desiderati, tramite il tasto “Salva”, procede all’effettiva
memorizzazione dei nuovi valori sul database. Tramite il codice presente nel Listato 4.3,
dunque, viene generato un timestamp in formato UTC (righe 1-3), dopodiché, dalla riga 5
alla riga 7, vengono “valorizzati” i campi della tabella interna lt_zmcoduss con i valori del
timestamp appena generato; inoltre, viene impostato a “W” il campo relativo all’aggiornamento
dei contratti (dato che tale attività avviene in modo asincrono). Nelle restanti righe del listato,
invece, si effettua la modifica alle tabelle del database zmcoduss e zmcoduss_eccez e, se
non sono state sollevate eccezioni, si procede al commit delle modifiche.
1 GET TIME STAMP FIELD lv_ts.

2 CONVERT TIME STAMP lv_ts TIME ZONE sy-zonlo
3 INTO DATE lv_dat TIME lv_tim.
4
5 ls_zmcoduss-last_mod_date = lv_dat.
6 ls_zmcoduss-last_mod_tmsp = lv_ts.
7 ls_zmcoduss-all_contr_upd = 'W'.
8
9 IF lt_zmcoduss[] IS NOT INITIAL .
10 MODIFY zmcoduss FROM TABLE lt_zmcoduss.
11 MODIFY zmcoduss_eccez FROM TABLE lt_zmcoduss_eccez.
12 IF sy-subrc <> 0.
13 ROLLBACK WORK.
14 EXIT.
15 ELSE.
16 COMMIT WORK AND WAIT.
17 ENDIF.
18 ENDIF.
Listato 4.3: Salvataggio delle modifiche sul database SAP
4.2.2 ZUPD_CONTR
Una volta che le modifiche effettuate dal planner, tramite il tool ZMRPE_GP, sono state
salvate sul database, è necessario propagare i nuovi valori delle tolleranze e del magazzino
nei contratti. L’aggiornamento avviene tramite il tool ZUPD_CONTR che, come accennato in
precedenza, opera in modo asincrono rispetto all’inserimento dei valori in ZMRPE_GP. Si
è scelto di gestire l’aggiornamento dei contratti in modo asincrono per evitare di bloccare
i contratti. Difatti, in SAP, quando si vogliono effettuare delle modifiche ad un oggetto, è
necessario acquisire un lock in scrittura. L’aggiornamento di un solo gruppo prodotto può
scatenare delle modifiche su diversi contratti e, spesso, i planner aggiornano molti gruppi
prodotto in una sola sessione. Aggiornando in maniera sincrona, dunque, un’eccessiva
quantità di contratti verrebbe bloccata proprio nell’orario lavorativo aziendale, ostacolando
chi lavora su di essi. Difatti, per evitare di causare disagi, l’aggiornamento è schedulato per
avviarsi autonomamente durante le ore notturne.
L’aggiornamento asincrono automatico genera, tuttavia, un’altra problematica, ovvero la
selezione dei gruppi prodotto per cui propagare le modifiche. Per aggiornare le tolleranze
ed il magazzino è necessario selezionare dal database tutte le posizioni di contratto il cui
codice materiale è contenuto nel gruppo prodotto modificato. Le posizioni di contratto sono
conservate in una nota tabella standard SAP chiamata EKPO. In azienda, tale tabella contiene
svariati milioni di record e, se i gruppi prodotto modificati sono tanti, la query di selezione
potrebbe andare in timeout ed essere interrotta dal gestore SQL di SAP. Per far fronte al
problema viene effettuato un controllo basato su timestamp.
Nello specifico, quando un planner effettua il salvataggio dei dati in ZMRPE_GP, nella ta-
bella zmcoduss viene registrato il timestamp del salvataggio, chiamato “last mod. timestamp”.
Analogamente, quando il tool ZUPD_CONTR propaga le modifiche ai contratti di interesse,

viene registrato un ulteriore timestamp, chiamato “last processing timestamp”. All’avvio di
ZUPD_CONTR, per ogni gruppo prodotto presente nella tabella zmcoduss, viene confrontato
il last processing timestamp con il last mod. timestamp. Un gruppo prodotto verrà considerato per
l’aggiornamento soltanto se il timestamp di ultima modifica è più recente di quello relativo
all’ultima elaborazione da parte di ZUPD_CONTR.
Il tool di aggiornamento è pensato per essere eseguito come job in background e non
ha, quindi, una schermata di selezione o un’interfaccia utente. Il tool, una volta messo in
esecuzione dal job scheduler di SAP, come mostrato nel Listato 4.4, effettua una query sul
database per selezionare i gruppi prodotto secondo i criteri appena esposti.
1 SELECT matnr lifnr werks mrpe_tollmrp_d mrpe_tollmrp_e lgort

2 FROM zmcoduss
3 INTO CORRESPONDING FIELDS OF TABLE gt_zmcoduss_data
4 WHERE zmcoduss~last_mod_tmsp > zmcoduss~last_proces_tmsp
5 AND zmcoduss~all_contr_upd NE 'S'.
6 ENDIF.
7
8 SORT gt_zmcoduss_data BY matnr ASCENDING lifnr ASCENDING.
Listato 4.4: Query per la selezione dei gruppi prodotto recentemente modificati
A questo punto, tramite la query presente nel Listato 4.5, verranno selezionate le posizioni
di contratto che, in ordine:
• non risultano cancellate;
• appartengono a contratti in corso di validità, ovvero la cui data di validità del contratto
sia maggiore della data di esecuzione del tool di aggiornamento;
• hanno un codice materiale appartenente ad uno dei gruppi prodotto selezionati tramite
la query precedente (Listato 4.4);
• hanno una source list in corso di validità, ovvero un fornitore da cui poter effettuare
l’approvvigionamento.
1 SELECT ekpo~ebeln ekpo~ebelp ekko~lifnr ekpo~txz01 ekpo~matnr ekpo~werks

2 ekpo~lgort ekpo~untto ekpo~uebto pgmi~prgrp
3 INTO CORRESPONDING FIELDS OF TABLE gt_ekpo_data
4 FROM ( ekko INNER JOIN ekpo ON ekko~ebeln = ekpo~ebeln
5 INNER JOIN pgmi ON ekpo~matnr = pgmi~nrmit AND ekpo~werks = pgmi~werks
6 INNER JOIN eord ON ekko~ebeln = eord~ebeln AND ekpo~ebelp = eord~ebelp )
7 FOR ALL entries IN gt_zmcoduss_data
8 WHERE ekko~bstyp = 'K'
9 AND ekko~kdate > sy-datum
10 AND ekko~lifnr = gt_zmcoduss_data-lifnr
11 AND ekpo~loekz NE 'L'
12 AND ekpo~werks = gt_zmcoduss_data-werks
13 AND eord~bdatu > sy-datum
14 AND pgmi~prgrp = gt_zmcoduss_data-matnr.
15 ENDIF.
Listato 4.5: Query per la selezione delle posizioni di contratto da aggiornare

Sempre nel Listato 4.5, alla riga 8, si può notare un particolare comando SQL disponibile
solo in SAP, ovvero: FOR ALL ENTRIES IN <tab. interna> WHERE. In SAP, specifican-
do FOR ALL ENTRIES davanti alla clausola WHERE di una SELECT, è possibile confrontare
i campi di una tabella del database con quelli di una tabella interna utilizzando gli operatori
relazionali. Una tabella interna viene definita tramite codice ABAP ed è, quindi, una normale
variabile del programma che la definisce. Tramite i tradizionali comandi SQL, infatti, non
sarebbe possibile confrontare un oggetto esterno con gli elementi di una tabella del database.
In questo modo, inoltre, le condizioni logiche espresse nella clausola WHERE vengono con-
frontate individualmente con ogni riga della tabella interna. Il risultato finale della SELECT
sarà, quindi, l’unione di tutte le righe selezionate dai singoli confronti. Nel Listato 4.5, nello
specifico, il comando viene utilizzato per effettuare la medesima selezione per ogni gruppo
prodotto presente nella tabella interna gt_zmcoduss_data. Tale tabella viene “valorizzata”
tramite la query di selezione dei gruppi prodotto presente nel Listato 4.4.
Conclusa la fase di recupero dei dati dal database, il programma procede all’effettivo
aggiornamento delle posizioni di contratto. Infine, viene aggiornato il timestamp relativo
all’ultima elaborazione del programma di aggiornamento e l’esecuzione del programma può
proseguire in due modi differenti. Nel caso in cui tutte le posizioni di contratto selezionate
vengono aggiornate correttamente il programma genera un registro delle modifiche effettuate
e termina. Altrimenti, se si sono verificati degli errori in fase di aggiornamento per almeno
una posizione di contratto, il programma genera il registro delle modifiche effettuate ed un
registro di errore, invia una mail automatica con il registro degli errori in allegato ad un
buyer dell’azienda e termina. Il buyer, ricevuta la mail di avviso, potrà consultare il registro
degli errori in allegato ed, eventualmente, procedere ad una correzione manuale delle sole
posizioni in errore.
CAPITOLO 5
Migrazione del tool Price List Management
Nel presente capitolo verrà introdotto il processo aziendali in cui si colloca il tool PLM, descrivendone
brevemente la versione attuale. Successivamente verrà descritto il processo di porting tecnologico, analizzando
i requisiti e discutendo l’implementazione.
5.1 Analisi dei requisiti di business

In azienda, durante le riunioni della fase Explore del progetto di migrazione a S/4HANA,
è stata avanzata a gran voce la richiesta, da parte dei buyer, di modernizzare il tool Price List
Management. Così come per il tool presentato nel precedente capitolo, anche in questo caso
la richiesta è stata accolta ed inserita nelle attività della fase di Tools Renovation.
5.1.1 Introduzione al processo aziendale

Price List Management (PLM) è un tool che permette ai buyer aziendali di caricare nel
sistema SAP i listini ricevuti dai fornitori in modo agevole. Il listino di un fornitore si traduce
essenzialmente in un contratto SAP, come mostrato nel contratto di esempio in Figura 5.1. Un
contratto, come già accennato nel capitolo precedente, è identificato da un codice contratto e
da un codice fornitore (evidenziati in blu). Ogni contratto si compone di diverse posizioni
(anche chiamate “items”); per ognuna di queste posizioni, viene definito un codice materiale
(evidenziato in giallo), un prezzo (evidenziato in verde), un’unità di misura (evidenziata in
rosso) e un plant (evidenziato in viola).
Figura 5.1: Esempio di un contratto in SAP
51
Nell’ambito del processo di migrazione a S/4HANA, in azienda è stata colta l’occasione

per semplificare alcuni dei processi aziendali. In SAP, la semplificazione di un processo può
avvenire in più modi:
• riprogettare il processo da zero, seguendo le Best Practices SAP;
• riprogettare il processo eliminando le parti custom, facendo ritorno allo standard SAP;
• riprogettare il processo tramite modifiche mirate o aggiornamenti tecnologici, renden-

dolo più efficiente.
La modernizzazione del tool PLM ricade proprio in quest’ultima casistica. Difatti, essendo
il processo ben consolidato da anni, un suo sostanziale re-engineering creerebbe soltanto
confusione. A monte di una Richiesta di Acquisto (RdA) c’è il modulo MRP. Tale modulo,
individua i materiali necessari, effettua una stima delle quantità, stabilisce il momento
in cui i materiali saranno necessari per rispettare la programmazione della produzione e
gestisce la tempistica di consegna, con l’obiettivo di soddisfare la domanda e migliorare la
produttività nel suo complesso. Il flusso elaborativo dell’MRP è presentato in Figura 5.2.
Come si può notare, il tutto parte da un Master Production Schedule (MPS), generato a partire
dalle previsioni della domanda di mercato, dalle risorse già disponibili in magazzino e dalle
risorse da acquistare. L’MPS contiene il piano di produzione per un determinato periodo e
rappresenta l’input principale dell’algoritmo dell’MRP che, a questo punto, genera delle Bill
of Materials, ovvero delle “liste della spesa” di componenti necessari alla produzione. Infine,
viene generato il Material Requirements Plan a cui seguono varie Richieste di Acquisto e Ordini
di Acquisto.
Figura 5.2: Diagramma del flusso elaborativo dell’MRP
In Figura 5.3 viene presentato, con alcune semplificazioni, un diagramma di flusso che
descrive il processo per l’acquisto dei materiali in azienda. Nello specifico, in presenza di
una richiesta di materiale, frutto dell’elaborazione del modulo MRP, si procede alla creazione
automatica delle Richieste di Acquisto da parte di un tool custom aziendale. A questa fase
segue la trasformazione delle Richieste di Acquisto in Ordini di Acquisto. Una Richiesta di
Acquisto, infatti, è soltanto un documento interno il cui scopo principale è gestire il workflow
approvativo aziendale. Una volta approvata, la Richiesta di Acquisto si traduce in un Ordine

di Acquisto, ovvero nell’acquisto effettivo di beni o servizi da parte di un fornitore.
Come si nota nel diagramma del processo, prima di poter convertire la Richiesta di
Acquisto in Ordine di Acquisto è necessario stabilire una fonte da cui effettuare l’acquisto. È
proprio in questa fase che entra in gioco il tool custom PLM, oggetto di porting tecnologico. In
azienda, per le Richieste di Acquisto generate dal modulo MRP non è previsto un workflow
approvativo; tuttavia, resta la necessità di approvare i listini (ovvero le fonti di acquisto)
generati tramite PLM. Il processo prosegue, poi, con l’invio dell’Ordine di Acquisto al
fornitore che provvederà a consegnare la merce. Tutti gli step presentati nel diagramma,
fino all’invio dell’Ordine di Acquisto al fornitore, sono di competenza del pillar Sourcing
and Procurement. Gli step successivi, invece, non sono direttamente impattati dal porting
tecnologico di PLM, facendo capo:
• al pillar Warehousing, per la parte di entrata merci ed analisi dello stock;
• al pillar Core Finance, per la fatturazione.
Figura 5.3: Diagramma del processo acquisti
5.1.2 Caratteristiche attuali del tool

Prima delle attività di re-engineering del tool PLM, la gestione dei rapporti con i fornitori
avveniva tramite SAP Supplier Relationship Management (SAP SRM). SAP SRM è un insieme
di strumenti sviluppati da SAP per facilitare la gestione dei subcontrattisti. Gli strumenti
offerti appartengono a varie aree funzionali le più importanti delle quali sono Sourcing,
Procurement e Contract Management.
• Sourcing: si tratta della fase nel quale viene investigato il mercato e si cercano i potenziali
subcontrattisti. Durante questa fase è necessario definire quali sono gli obbiettivi che si
vogliono raggiungere nonché i vincoli ed il tipo di subcontrattisti con i quali si vuole
lavorare (spesso il costo non è l’unica variabile, e magari neanche la più importante).
• Procurement: una volta che sono stati identificati e contattati i fornitori, il passaggio
successivo è quello del Procurement, ovvero il momento nel quale viene effettivamente
acquistato il bene o servizio necessario all’azienda a seguito delle approvazioni interne.
In generale, il tipo di autorizzazioni necessarie varia da impresa a impresa e, normal-
mente, anche in funzione dell’importo del contratto. SAP SRM, inoltre, aiuta a definire
correttamente la definizione dei requisiti, la gestione della fatturazione e dei pagamenti,
e, più in generale, lo scambio con i fornitori dei documenti e le informazioni necessarie.
• Contract Management: è la fase di gestione del contratto, spesso la più critica, essendo
necessaria per confermare che i termini contrattuali (tempistiche, qualità, termini di
pagamento, etc.) vengano rispettati dal fornitore.
Tramite SAP SRM, dunque, i buyer aziendali avevano la possibilità di inserire i listini dei
fornitori, specificando il codice del contratto SAP di riferimento e compilando uno Shopping
Cart. Quest’ultimo prende sostanzialmente la forma di una tabella in cui sono definiti i vari
codici materiali e le varie componenti del prezzo. I dati dello Shopping Cart vanno compilati
dal buyer manualmente, oppure tramite un caricamento massivo dei codici tramite file in
formato CSV. Per questa motivazione il tool risulta molto scomodo e macchinoso da usare
e, anche se il caricamento tramite file CSV permette di caricare molti codici alla volta, basta
qualche errore di formattazione per mandare in errore il programma. Alla frustrazione dei
buyer, dovuta alla lentezza e alla difficoltà di utilizzo del tool, si aggiunge l’interfaccia utente
decisamente obsoleta, di cui ne viene riportato un esempio in Figura 5.4.
Figura 5.4: Esempio dell’interfaccia di SAP SRM
Nel tool, un buyer, dopo aver creato un listino e averlo associato ad un contratto SAP,
deve creare una famiglia di materiali oppure utilizzarne una preesistente. La famiglia di
materiali è un concetto simile ai gruppi prodotto visti nel capitolo precedente. Infatti, essa
contiene dei codici materiale al suo interno e definisce alcune proprietà e parametri generali
che si applicano a tutti i materiali contenuti. In Figura 5.5 viene presentata una videata di
esempio della gestione famiglie. In tale schermata si possono osservare, nell’area evidenziata
in verde, due famiglie di materiali e, di fianco, nell’area evidenziata di giallo, le rispettive
unità di misura e unità di prezzo.
In Figura 5.6, invece, è possibile osservare una videata di esempio che mostra la gestione
dei singoli materiali nel listino. Difatti, una volta creata (o scelta) la famiglia di materiali
appropriata, il buyer deve riempire il listino con i codici materiale di interesse (evidenziati in
verde), definire le componenti di prezzo (evidenziate in giallo), tra cui importo commodity,
importo converting, etc. e, infine, inserire il plant di riferimento, le date di validità del
contratto e le date di validità della source list (evidenziate in viola).
A questo punto il listino è completo e deve essere mandato in approvazione ad un approver
(solitamente un direttore del reparto acquisti). Una volta approvato il listino, i suoi valori
verranno propagati nel rispettivo contratto SAP aggiornando i prezzi e la source list per le
singole posizioni del contratto.
Figura 5.5: Gestione delle famiglie di materiali in SRM
Figura 5.6: Gestione degli item del listino in SRM
5.2 Implementazione dei requisiti

Il diagramma di processo del tool PLM, prima delle attività di migrazione, si presentava
come mostrato in Figura 5.7. In particolare, come si può osservare nel diagramma, i buyer
caricavano il listino tramite file CSV oppure lo inserivano manualmente. Subito dopo scattava
l’iter di autorizzazione, al termine del quale, veniva aggiornato il contratto SAP interessato
dal listino.
Figura 5.7: Processo AS IS del tool PLM
Per il porting tecnologico di PLM, essendo un tool molto complesso e di vitale importanza,
l’azienda si è fatta affiancare da una società di consulenza. Il team di progetto interno ha,
quindi, collaborato con i consulenti per completare il porting. Per questo motivo, il codice del
tool, così come i dettagli tecnici di implementazione, sono privati. La metodologia adottata
per l’implementazione è di tipo agile, ovvero sono state fatte periodicamente delle riunioni
con i key user della direzione acquisti durante le quali emergevano i vari requisiti e le migliorie
desiderate e, successivamente, venivano pianificati degli sprint. In ogni sprint si è cercato
di implementare tutti i requisiti raccolti durante le riunioni, scartando alcuni desiderata in

accordo con le tempistiche e le priorità di progetto. L’approccio adottato è stato scelto per via
del poco tempo a disposizione per il porting del tool. Difatti, lavorando a stretto contatto con
i key user ed effettuando delle revisioni settimanali, è stato possibile ridurre i tempi necessari
per la successiva fase di testing.
A seguito delle riunioni di analisi dei requisiti, oltre alle varie migliorie sul piano tec-
nologico oppure rigurado la user experience, si è colta l’occasione per effettuare un piccolo
re-engineering del processo. Nello specifico, si è prevista la possibilità di inserire i fornitori
all’interno del processo in modo da poter operare in stretta collaborazione con essi, agevo-
lando i buyer aziendali. In Figura 5.8 viene presentato il diagramma di processo dopo il
re-engineering.
Figura 5.8: Processo TO BE del tool PLM
Dopo alcune riunioni preliminari con la direzione acquisti, insieme ai consulenti sono
state individuate due aree di intervento per il tool, ovvero:
• Simplification: comprende tutti gli sviluppi riguardanti la semplificazione della user

experience e delle funzionalità obsolete;
• New Functionality: comprende tutti gli sviluppi delle nuove funzionalità richieste.
Nell’area di sviluppo Simplification sono stati identificati i seguenti punti:
• utilizzo del formato Excel al posto dei file CSV per il caricamento dei listini;
• rimozione delle famiglie;
• migliorie al log di errori, rendendolo più informativo;
• migliorie ai check preventivi in fase di upload del listino;
• rimozione dei campi relativi alle tolleranze, ora in carico al nuovo tool ZMRPE_GP;
• incremento generico delle performance.
Invece, per l’area di sviluppo New Functionality, i punti rilevati sono i seguenti:
• possibilità di integrazione del fornitore nel processo;
• gestione dei codici materiale per più plant contemporaneamente;
• implementazione di una web app per gestire le approvazioni da parte dei direttori.
5.2.1 ZPLM: Simplification

Al termine della fase preliminare di analisi dei requisiti, al nuovo tool è stato assegnato il
nome tecnico ZPLM e si è cominciato a pianificare il lavoro da svolgere nei vari sprint. Come
prima area di sviluppo si è partiti dalla Simplification, in particolare, nel primissimo sprint, ci
si è concentrati nel definire un template da utilizzare per il caricemento di un listino tramite
file Excel. Il motivo di tale scelta è relativo alle ripercussioni che essa ha sull’interfaccia utente.
Difatti, all’interno nel nuovo tool, la visualizzazione sarà coerente a quella del file Excel al
fine di evitare inutili confusioni da parte degli utenti. In Figura 5.9 è possibile osservare il
template concordato con gli utenti. In particolare, non è più necessario specificare la famiglia
per il materiale, ma potranno essere inseriti tutti i codici materiali necessari uno dopo l’altro
(area evidenziata in verde). Per ogni codice, si dovranno inserire i restanti dati relativi alle
componenti del prezzo, alle date di validità del contratto e alle date di validità delle source
list.
Figura 5.9: Esempio del template adottato per l’upload tramite file Excel
Nei successivi sprint è stata progettata ed implementata l’interfaccia generale del tool
della quale, in Figura 5.10, è possibile osservarne la schermata principale.
Figura 5.10: Schermata principale di ZPLM
In tale schermata, nello specifico, si distinguono due aree. La prima, evidenziata in verde,
è una schermata di selezione che permette di filtrare i vari listini presenti secondo molti
parametri differenti. Un buyer, solitamente, filtrerà utilizzando il campo “Buyer di riferimento”
in modo da vedere soltanto i listini di sua competenza. Inoltre, si rende disponibile anche
la selezione dei listini obsoleti o scaduti tramite i due checkbox appositi. Nell’area in basso,
evidenziata in giallo, è possibile visualizzare i listini selezionati con un riepilogo di varie
informazioni. In particolare, si hanno informazioni riguardo la tipologia di listino, la società
di interesse, il buyer che ha creato il listino, il codice fornitore associato, lo stato del listino, la
scadenza e il log delle operazioni.
Come si può osservare in Figura 5.11, anche l’interfaccia per la creazione di un nuovo
listino è stata aggiornata e resa consistente con il resto del tool. In questa schermata il buyer
che vuole creare un listino deve inserire alcuni dati di testata, tra cui il contratto associato
al listino (evidenziato in rosso) e l’approvatore (evidenziato in giallo). Per facilitare i buyer
nella compilazione dei dati di testata, non appena viene “valorizzato” il campo “Contratto”,
molti dei campi presenti vengono “valorizzati” automaticamente; ciò accade, ad esempio,
per il campo “Fornitore” (essendo fissato per un dato contratto e non modificabile).
Figura 5.11: Schermata di creazione di un nuovo listino
Dalla schermata principale del tool, una volta entrati in uno specifico listino, si possono
inserire i codici dei materiali di interesse e modificare quelli esistenti, come si può osservare
in Figura 5.12. Per farlo, tramite i pulsanti presenti nell’area evidenziata in verde, è possibile
caricare un file Excel contenente tutte le informazioni necessarie (come visto in Figura 5.9)
oppure, tramite l’area evidenziata in viola, è possibile eseguire l’inserimento e la modifica
manuale del listino. Tramite i tasti presenti nell’area evidenziata in rosso, invece, è possibile
marcare un materiale obsoleto, oppure ripristinarne che prima era stato marcato come
obsoleto. Marcare un materiale come obsoleto imposta automaticamente la sua data di fine
validità della source list alla data odierna, di fatto impedendo la creazione di nuove Richieste
di Acquisto per esso.
Infine, tramite i pulsanti presenti nell’area evidenziata in giallo, è possibile modificare in
modo massivo le date di validità delle source list. Terminata la modifica del listino, cliccando
sul tasto “Salva”, il buyer viene riportato nella schermata principale.
In ZPLM, un listino può trovarsi in tre stati diversi, ovvero in bozza, in approvazione e
approvato. Una bozza è un listino appena creato, oppure modificato di recente; in questo
stato, esso non può propagare alcuna modifica al contratto SAP di riferimento. Quando
un buyer termina le sue modifiche e i suoi controlli di routine richiederà l’approvazione

per il suo listino. Per l’invio in approvazione apparirà al buyer la schermata presentata in
Figura 5.13, nella quale verrà visualizzato un riepilogo delle righe del listino modificate
ed è possibile scrivere una nota all’approvatore. A questo punto il listino cambierà il suo
stato da “Bozza” a “In approvazione”. Successivamente, al via libera dell’approver, cambierà
nuovamente stato in “Approvato”. Quando un listino diventa approvato, ZPLM propagherà
automaticamente i valori del listino nel contratto SAP.
Figura 5.12: Schermata di modifica di un listino
Figura 5.13: Schermata per l’invio del listino in approvazione
Completato il porting delle funzionalità principali dell’applicazione, nei successivi sprint

ci si è concentrati sul miglioramento dei messaggi di errore che, nella vecchia versione del
tool, presentavano messaggi generici e non indicavano al buyer quale era l’effettivo materiale
in errore. Per fare ciò è stata ristrutturata la parte di codice relativa alla gestione degli errori
per permettere di individuare la singola causa del problema. Difatti, inizialmente, il tool
presentava soltanto un errore generico in fase di caricamento di un listino errato. Il buyer,
a questo punto, doveva analizzare riga per riga tutto il file Excel alla ricerca dell’errore. In
Figura 5.14 è presente il risultato di questa ristrutturazione; In particolare, si può notare come
i messaggi di errore facciano riferimento agli specifici codici materiale in errore.
Figura 5.14: Schermata pop-up per la visualizzazione dei messaggi di errore
5.2.2 ZPLM: New Functionality

Gli ultimi due sprint nell’ambito del porting tecnologico di PLM hanno riguardato
l’implementazione della nuova app di approvazione e l’integrazione del fornitore.
Il processo di approvazione, come già accennato, è responsabilità dei direttori del reparto
acquisti. Queste figure aziendali, spesso, non hanno molta esperienza con il sistema SAP e
risultano sempre molto impegnate. L’obiettivo della nuova app di approvazione è quello di
rendere veloce e semplice lo svolgimento dell’attività da parte degli approver. Per raggiungere
tale obiettivo si è scelto di implementare la soluzione come web app. Ciò permette l’accesso
all’app tramite smartphone, tablet e pc e, al contempo, garantisce un’interfaccia semplice ed
intuitiva. Come si nota in Figura 5.15, partendo da sinistra, è presente la schermata principale
dell’app che permette di vedere tutti i listini in approvazione.
Figura 5.15: Diverse schermate della web app di approvazione
Selezionando un listino viene aperta una schermata di dettaglio (al centro in Figura 5.15)
dove sono indicati i materiali del listino con il loro prezzo totale. Infine, in Figura 5.15, sulla
destra, è presente un’ulteriore schermata che mostra il delta dell’importo totale nel caso di
listini che hanno subito modifiche. In questo modo quando un direttore deve approvare il
listino, invece che controllare ogni singolo prezzo dei materiali, può semplicemente guardare
i delta per rendersi conto della situazione.
Per quanto riguarda il fornitore, l’utilità del suo coinvolgimento nel processo risiede nella
possibilità di applicare piccole modifiche ad un listino senza necessità di rimandare quest’ul-
timo in approvazione ad un approver. Nello specifico, se un buyer nota delle inconsistenze
o degli errori nei prezzi del listino può decidere di inviare il listino al fornitore che, a quel
punto, agirà come un buyer e potrà entrare in modifica nel listino. Non appena il fornitore
conferma le modifiche, il listino, invece che andare in approvazione all’approver, andrà in
approvazione al buyer. Il buyer può verificare le modifiche effettuate dal fornitore e, se con-
fermate, viene immediatamente aggiornato il contratto di riferimento, evitando di riempire
inutilmente la casella di posta del direttore incaricato dell’approvazione. Ovviamente, per
evitare che il fornitore possa impostare dei prezzi a suo piacimento, questa operazione viene
resa disponibile solo per i fornitori di fiducia con cui l’azienda ha instaurato accordi a lungo
termine. Inoltre, se il prezzo iniziale e il prezzo inserito dal fornitore presentano un delta
troppo alto, il listino dovrà essere comunque sottoposto al normale processo di approvazione.
CAPITOLO 6
Discussione in merito al lavoro svolto
In questo capitolo proporremo una discussione in merito al lavoro svolto. In particolare, dapprima
elencheremo un insieme di lezioni da noi apprese nel portare avanti il presente lavoro. Successivamente,
daremo uno sguardo alle possibili estensioni dell’approccio proposto ad altri casi.
6.1 Lezioni apprese

Durante il progetto di migrazione è stato possibile apprendere molte lezioni in merito al
lavoro svolto. Le più importanti tra queste sono le seguenti:
• la difficoltà nella migrazione da un modello dati ad un altro;
• la comprensione della problematica del vendor lock-in;
• l’attenzione ai dettagli in ogni fase della migrazione;
• la complessità generale di una migrazione che coinvolge tutte le aree aziendali;
• l’importanza della comprensione dei business need degli utenti.
Qualsiasi attività di migrazione risulta, nella maggior parte dei casi, un processo lungo,
articolato e insidioso. Nel caso esposto nella presente tesi, tuttavia, la transizione dal vecchio
al nuovo sistema presenta delle notevoli difficoltà aggiuntive per via della modifica al model-
lo dei dati. Il modo in cui i dati sono rappresentati e manipolati, spesso, getta le fondamenta
per qualsiasi software si voglia implementare. Nel caso della migrazione da SAP ECC a SAP
S/4HANA si assiste ad un passaggio dal classico modello relazionale al modello colonnare
e, inoltre, la transizione da un DBMS tradizionale ad una soluzione in-memory rappresenta
un’evoluzione tecnologica non indifferente. Per questi motivi, il processo di migrazione non
consiste semplicemente nello spostamento dei dati dal vecchio sistema al nuovo sistema,
ma in una serie di attività di re-engineering in cui bisogna tradurre la precedente rappresen-
tazione dei dati nella nuova. Inoltre, la notevole differenza tecnologica dell’architettura di
SAP S/4HANA rispetto a SAP ECC costringe ad una modifica dell’infrastruttura hardware
aziendale, con il conseguente significativo aumento dei costi di progetto.
SAP, annunciando la fine del supporto a SAP ECC, ha forzato indirettamente molte azien-
de ad intraprendere il processo di migrazione. Ciò ha messo in risalto l’impatto che il vendor
lock-in può avere nelle decisioni aziendali. Questa problematica si presenta ogniqualvolta
62
6.1 − Lezioni apprese 63
un’azienda si affida completamente ad un fornitore per i propri sistemi informativi. Se, da

un lato, avere un ecosistema di software perfettamente integrati e consistenti tra loro può
garantire una maggiore efficienza, dall’altro limita tremendamente la flessibilità dell’azienda
nell’adottare nuovi software e soluzioni innovative di altri fornitori. Nelle aziende, l’adozione
di un nuovo sistema è un processo lungo e porta inevitabilmente alla ristrutturazione di
alcuni processi aziendali o delle metodologie di gestione dei dati. Spesso, quindi, i fornitori
possono abusare della loro posizione forzando determinate scelte sui propri clienti, consci del
maggior costo che l’azienda dovrebbe sostenere nel caso decida di affidarsi a soluzioni di altre
società. SAP ne è un esempio lampante; difatti, domina il mercato degli ERP da moltissimi
anni ed è fortemente consolidato nelle aziende; annunciando la fine del supporto a SAP ECC
entro il 2025 l’azienda sta costringendo molte organizzazione a sostenere costi esorbitanti
per effettuare la migrazione a SAP S/4HANA. Il vendor lock-in è, dunque, un aspetto che
un’azienda non deve assolutamente sottovalutare nell’ambito della Digital Transformation.
In merito al processo di migrazione in sé, durante il progetto è emersa l’importanza di
prestare la massima attenzione a tutti i dettagli implementativi. Non è raro che i consulenti
esterni cerchino di tagliare i tempi e i costi sorvolando su alcune aree di minore importanza;
tuttavia, a lungo termine, questa pratica comporta soltanto problemi. In particolare, accorgersi
di problematiche critiche quando una determinata fase di progetto è stata chiusa comporta
tornare indietro nella timeline di progetto per sistemare la criticità, con conseguente dispendio
di tempo e soldi. Ciò acquista ancora più valore nei processi di migrazione in cui sono
coinvolti i dati aziendali; difatti, una semplice negligenza potrebbe portare alla perdita o alla
corruzione dei dati. Lo stesso si applica per le fasi di analisi dei rischi e per la stesura del
piano di risposta ad essi, infatti, sorvolare su questi aspetti getta nella confusione l’intero
team di progetto quando un eventuale rischio si presenta e non si hanno gli strumenti di
risposta.
In azienda il processo di migrazione interessava praticamente ogni reparto, dal più ovvio
reparto ICT fino ad impattare anche la direzione Marketing e HR. Un progetto di tale portata
è molto complesso da gestire, soprattutto per quanto riguarda l’organizzazione delle comuni-
cazioni. Quando sono coinvolte così tante persone in unico progetto risulta molto difficile
far pervenire le corrette informazioni alle persone interessate e, soprattutto, consegnarle nel
minor tempo possibile. Nei grandi progetti, come quello di migrazione ad S/4HANA, si
susseguono numerosi interventi sui sistemi aziendali, e fallire nell’identificare e nell’avvisare
celermente gli utenti impattati da tali interventi causa molti problemi di tipo organizzati-
vo. Nel reparto ICT, ad esempio, una mancata comunicazione di un aggiornamento ad un
programma può creare dei conflitti nel codice e nel sistema, allungando le tempistiche di
progetto.
Infine, in azienda, si è dimostrata essere di fondamentale importanza la capacità di ascol-
tare i bisogni degli utenti, scremando i desiderata dai requisiti critici in accordo con la timeline
di progetto. Fallire nel comprendere i reali business need degli utenti ci espone al rischio di
dover riprendere in mano gli sviluppi di un software per implementare nuove funzionalità o
per correggere quelle esistenti. In azienda si è dimostrato più volte fondamentale integrare i
key user aziendali nelle riunioni di analisi dei requisiti, mostrando, di volta in volta, il lavoro
svolto. Nell’utilizzo quotidiano dei sistemi informativi aziendali, sono gli utenti ad operare e
non il personale tecnico della direzione ICT e, per questo motivo, se le soluzioni implementate
non si adattano ai loro bisogni risultano inutili. La capacità di trasformare i business need
degli utenti in requisiti tecnici ben definiti permette di implementare, quindi, delle soluzioni
migliori e più efficaci.
6.2 − Generalizzazione dell’approccio proposto 64
6.2 Generalizzazione dell’approccio proposto

La metodologia di progetto esposta nel presente documento può essere, in parte, estesa ad
altre aziende dello stesso settore industriale. In particolare, SAP stessa consiglia fortemente
la metodologia SAP Activate per la gestione del processo di migrazione ad S/4HANA. Tale
metodologia è generalmente accettata dalla maggior parte delle aziende e permette di seguire
una linea comune nella migrazione al nuovo sistema. Settori industriali diversi o settori
molto di nicchia, tuttavia, potrebbero non rispecchiarsi nella metodologia proposta da SAP
(e nel corrispettivo documento) o preferire un’implementazione con personalizzazioni più
spinte. SAP Activate fornisce delle linee guida per una migrazione di successo ma, come
spesso avviene, nulla vieta di effettuare piccole deviazioni in corso d’opera. In azienda, ad
esempio, all’interno della fase di Realize sono state aggiunte le attività supplementari di
Tools Renovation descritte nel Capitolo 3. Sostanzialmente, seguendo la metodologia di SAP,
sarà la fase di Explore a dare maggiormente forma al piano di progetto; difatti, durante
questa fase vengono esposte tutte le soluzioni per l’eventuale re-engineering dei processi,
l’implementazione delle Best Practice SAP e lo studio degli interventi necessari per il porting
tecnologico dei programmi custom aziendali.
Un aspetto che i vari casi di implementazione fallimentari di SAP S/4HANA hanno
evidenziato è la necessità di farsi affiancare da partner preparati e competenti nel progetto
di migrazione. Infatti, essendo SAP un software molto complesso, difficilmente un’azienda
possiederà internamente tutte le conoscenze tecniche necessarie alla migrazione, e forzare
delle implementazioni “fai da te” può causare perdite di denaro maggiori nel lungo termine.
CAPITOLO 7
Conclusioni
Il progetto discusso nella presente tesi ha trattato il processo di migrazione dall’ERP

aziendale SAP ECC alla nuova versione SAP S/4HANA per una multinazionale italiana di
beni di consumo.
Inizialmente, sono stati esposti i concetti fondamentali dei database NoSQL, partendo
dall’introduzione del modello relazionale e delle caratteristiche dei DBMS NoSQL, per poi
concludere con una classificazione dei database.
Si è passati, poi, alla discussione della tecnologia in-memory e dei suoi impatti nel mondo
delle basi di dati e dei software ERP. In particolare, sono state analizzate alcune soluzioni
in-memory e, in maniera più dettagliata, è stata esposta la tecnologia dietro SAP HANA, il
database su cui poggia la suite SAP S/4HANA.
La trattazione si è poi spostata sull’effettivo processo di migrazione aziendale, evidenzian-
do la situazione attuale. Un particolare accenno è stato fatto alle sfide che un progetto così
ampio porta con sé e ai rischi che nasconde. Successivamente, è stata introdotta la strategia
di migrazione consigliata dal provider SAP, dettagliandone le fasi. Continuando, sono stati
esposti la struttura del team di progetto e l’approccio adottato per la migrazione.
Infine, sono state analizzate più in dettaglio due delle attività di progetto relative alla
fase di Tools Renovation. In particolare, è stata esposta la realizzazione di un nuovo tool
aziendale a supporto degli utenti, dalla sua fase di analisi dei requisiti fino all’effettiva
implementazione. Successivamente, è stato esposto il processo di porting tecnologico di un
complesso tool aziendale preesistente, analizzando il re-engineering del relativo processo
aziendale e la successiva implementazione in collaborazione con una società di consulenza.
Il progetto di migrazione, al nostro arrivo in azienda, si trovava nella sua fase centrale e
più corposa. Nonostante il piano di progetto sia ben definito e strutturato, in azienda non si è
mai esclusa la possibilità di sviluppi futuri alla data di fine progetto.
In particolare, a migrazione conclusa, è possibile sfruttare le potenzialità del nuovo SAP
S/4HANA nell’ambito dell’intelligenza artificiale e della Business Intelligence al fine di
potenziare i processi aziendali e ottenere vantaggi competitivi sul mercato. Un’altra area di
sviluppi post-migrazione è l’adeguamento e la modernizzazione di tutti quei tool aziendali
non considerati critici in fase di progetto.
Infine, una volta completata la migrazione ad S/4HANA, risulta di fondamentale im-
portanza garantire un lungo periodo di Hyper Care agli utenti finali, al fine di garantire il
corretto funzionamento dell’ERP aziendale per tutte le direzioni interessate identificando
65
66
inoltre, i problemi in modo rapido e proponendo soluzioni efficaci fino al raggiungimento di

una situazione di stabilità per gli utilizzatori del sistema.
Bibliografia
AYRES , F., AYRES , F. e B ARÃO , A. (2019), «Methodologies for Large SAP ERP Projects Imple-
mentation», in «International Conference Europe Middle East & North Africa Information
Systems and Technologies to Support Learning», p. 243–247, Springer.
C HANDRA , D. G. (2015), «BASE analysis of NoSQL database», Future Generation Computer

Systems, vol. 52, p. 13–21.
C HAWDA , N. (2020), «SAP S/4HANA Cloud Migration», Available at SSRN 3687397.
D IOGO , M., C ABRAL , B. e B ERNARDINO , J. (2019), «Consistency models of NoSQL databases»,

Future Internet, vol. 11 (2), p. 43.
F ÄRBER , F., M AY, N., L EHNER , W., G ROSSE , P., M ÜLLER , I., R AUHE , H. e D EES , J. (2012),
«The SAP HANA Database–An Architecture Overview.», IEEE Data Eng. Bull., vol. 35 (1),
p. 28–33.
F LEIG , C., A UGENSTEIN , D. e M AEDCHE , A. (2018), «Process Mining for Business Process
Standardization in ERP Implementation Projects-An SAP S/4 HANA Case Study from
Manufacturing.», in «BPM (Dissertation/Demos/Industry)», p. 149–155.
H ARRISON , G. (2015), Next Generation Databases: NoSQLand Big Data, Apress.
J AVADI I SFAHANI , B. e OTHERS (2017), «Evaluating a modern in-memory columnar data

management system with a contemporary OLTP workload», .
K HAN , W., K UMAR , T., C HENG , Z., R AJ , K., R OY, A. M. e L UO , B. (2022), «SQL and NoSQL
Databases Software architectures performance analysis and assessments–A Systematic
Literature review», arXiv preprint arXiv:2209.06977.
L EE , J., M UEHLE , M., M AY, N., FAERBER , F., S IKKA , V., P LATTNER , H., K RUEGER , J. e
G RUND , M. (2013), «High-Performance Transaction Processing in SAP HANA.», IEEE Data
Eng. Bull., vol. 36 (2), p. 28–33.
M AGAL , S. R. e W ORD , J. (2011), Integrated business processes with ERP systems, Wiley
Publishing.
M ANKALA , C. e OTHERS (2013), SAP HANA Cookbook, Packt Publishing Ltd.
M ISSBACH , M., S TAERK , T., G ARDINER , C., M C C LOUD , J., M ADL , R., T EMPES , M.,
A NDERSON , G. e OTHERS (2016), SAP on the Cloud, Springer.
67
BIBLIOGRAFIA 68
P LATTNER , H. e Z EIER , A. (2012), In-memory data management: technology and applications,

Springer Science & Business Media.
P LATTNER , H. e OTHERS (2013), A course in in-memory data management, Springer.
P RASETYO , Y. T. e S OLIMAN , K. O. S. (2021), «Usability Evaluation of ERP Systems: A

Comparison between SAP S/4 Hana & Oracle Cloud», in «2021 IEEE 8th International
Conference on Industrial Engineering and Applications (ICIEA)», p. 120–125, IEEE.
S CHNEIDER , T., G AHM , H. e W ESTENBERGER , E. (2014), ABAP Development for SAP HANA,
SAP PRESS.
S INGH , V. (2017), Manage Your SAP Projects with SAP Activate: Implementing SAP S/4HANA,
Packt Publishing Ltd.
S TRAUCH , C., S ITES , U.-L. S. e K RIHA , W. (2011), «NoSQL databases», Lecture Notes, Stuttgart
Media University, vol. 20 (24), p. 79.
VANSTECHELMAN , B. (2018), SAP HANA-Implementation Guide, Espresso Tutorials GmbH.
V ENKATRAMAN , S., FAHD , K., K ASPI , S. e V ENKATRAMAN , R. (2016), «SQL versus NoSQL
movement with big data analytics», International Journal of Information Technology and
Computer Science, vol. 8 (12), p. 59–66.
Siti consultati
• NoSQL – https://en.wikipedia.org/wiki/NoSQL
• The NoSQL Movement – https://www.dataversity.net/the-nosql-

movement-what-is-it
• Cosa è SAP HANA? – https://www.ibm.com/it-it/topics/sap-hana
• SAP HANA – https://it.wikipedia.org/wiki/SAP_HANA
• What is SAP HANA? – https://www.sap.com/products/technology-

platform/hana/what-is-sap-hana.html
• Guide to SAP Activate – https://blogs.sap.com/2020/12/08/the-

beginners-guide-to-sap-activate-best-practices-guided-
configuration-and-sap-activate-methodology
• Custom Code Migration Guide for SAP S/4HANA – https://help.

sap.com/doc/9dcbc5e47ba54a5cbb509afaa49dd5a1/202110.002/en-
US/CustomCodeMigration_EndToEnd.pdf
• SAP S/4HANA Migration Guide – https://www.panaya.com/blog/sap/sap-

s4hana-migration-guide/
• SAP S/4HANA migration: A definitive guide – https://www.techtarget.com/

searchsap/SAP-S4HANA-migration-A-definitive-guide
BIBLIOGRAFIA 69
• SAP Best Practices for SAP S/4HANA – https://rapid.sap.com/bp/#/BP_OP_

ENTPR
• What You Need to Know About SAP S/4 HANA Migration – https://www.
outsystems.com/blog/posts/sap-s4hana-migration
• Five Biggest Challenges of SAP S/4HANA Conversion – https://www.

thehackettgroup.com/blog/five-biggest-challenges-of-sap-s-
4hana-conversion
• Top 5 SAP S/4 HANA Failures and Lessons Learned – https://www.

viennaadvantage.com/blog/technologies/top-5-sap-s-4-hana-
failures-and-lessons-learned/
• SAP Best Practices: ispirarsi ai migliori – https://www.corsosap.com/sap-best-

practices-ispirarsi-ai-migliori
• What’s SAP Best Practices? – https://blogs.sap.com/2022/03/20/whats-

sap-best-practices/
• SAP Activate Elements and Phases – https://blogs.sap.com/2021/11/25/sap-

activate-elements-and-phases
Ringraziamenti
Alla mia famiglia, per avermi permesso di intraprendere questo percorso.
A Sarah, per avermi supportato (e sopportato) durante questi anni.
Ai vari compagni di corso, per aver alleggerito la sfida.
Al Professore Domenico Ursino, per la pazienza e

la disponibilità dimostrate ogni giorno.
70

Tesi Sgrignuoli

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi Sgrignuoli

Caricato da

Copyright:

Formati disponibili

U NIVERSITÀ P OLITECNICA DELLE M ARCHE

Attività di migrazione e conversione dall’attuale sistema ERP SAP

Prof. Domenico Ursino Piero Sgrignuoli

A NNO A CCADEMICO 2021-2022

2 In-memory database e SAP HANA 14

3 Panoramica generale del processo di migrazione 25

4 Implementazione del tool per la gestione delle tolleranze 41

5 Migrazione del tool Price List Management 51

6 Discussione in merito al lavoro svolto 62

1.1 Esempio di schema logico relazionale . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Differenza tra i tempi di accesso tipici dei vari componenti . . . . . . . . . . . 14

3.1 Panoramica delle aree impattate da SAP S/4HANA . . . . . . . . . . . . . . . 28

4.1 Videata di un contratto SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Diagramma del processo aziendale di riferimento . . . . . . . . . . . . . . . . 43

5.1 Esempio di un contratto in SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.1 Differenze tra query OLTP e OLAP . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1 Un esempio di file JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Definizione della schermata di selezione . . . . . . . . . . . . . . . . . . . . . . 45

Lo scopo della presente tesi è quello di descrivere la partecipazione fattiva ad un reale

• Nel Capitolo 1 verrà brevemente introdotto il modello relazionale, a seguire, si parlerà

• Nel Capitolo 2 verrà introdotta la tecnologia in-memory, l’in-memory computing e alcuni

• Nel Capitolo 3 saranno inizialmente introdotti i vantaggi, le sfide, i rischi e le motiva-

• Nel Capitolo 4 verrà analizzata l’implementazione di un tool per la gestione delle

• Nel Capitolo 5 si seguirà, invece, il processo di porting tecnologico e di re-engineering

1.1 Dal modello relazionale al movimento NoSQL

1.1.1 Breve storia del modello relazionale

Figura 1.1: Esempio di schema logico relazionale

1.1.2 La nascita del movimento NoSQL

Dati strutturati e dati non strutturati

Listato 1.1: Un esempio di file JSON

1.2 NoSQL database

• Scalabilità orizzontale: è la caratteristica di un sistema di gestire un carico di lavoro

• Resistenza ai guasti: l’architettura distribuita su più nodi garantisce intrinsecamente una

1.2.1 Conseguenze della replicazione del dato

Figura 1.4: Schema riassuntivo della replicazione in MongoDB

La prima soluzione garantisce, dunque, che le letture immediatamente successive all’o-

• Partition-tolerance: il sistema continua a funzionare nonostante la perdita di messaggi

Figura 1.5: Diagramma riassuntivo del CAP Theorem

Poiché il principio fondamentale dei DBMS NoSQL è la tolleranza al partizionamento,

• Basically Available: significa che il sistema risponde a ogni richiesta in qualunque

1.2.2 Classificazione dei database NoSQL

Figura 1.6: Rappresentazione grafica delle quattro macro-categorie del NoSQL

Figura 1.7: Una schematizzazione del modello chiave-valore

Figura 1.8: Una schematizzazione del modello column-oriented

Figura 1.9: Una schematizzazione del modello basato su documenti

Difatti, ogni record della base di dati è composto da un identificatore univoco e un

Figura 1.10: Una schematizzazione del modello basato su grafo

In-memory database e SAP HANA

2.1 Overview dei database in-memory

2.1.1 Caratteristiche dei database in-memory

• replicazione dei dati su altri nodi del cluster;

• mantenimento di un registro delle operazioni/transazioni effettuate in speciali file su

Encoding dei dati

1. si ricerca nel dizionario il valore richiesto, recuperando il rispettivo ValueID,

2. si scansiona l’array degli attributi con il ValueID,

Figura 2.2: Schematizzazione del pipelined parallelism e del data parallelism

2.1.2 Differenze tra i sistemi tradizionali e sistemi in-memory

Categoria OLTP OLAP

Operazioni sul database

• Inserimento: nelle strutture colonnari le operazioni di inserimento funzionano diversa-

• Aggiornamento: il macro funzionamento delle operazioni di aggiornamento è identico

• Cancellazione: per le operazioni di cancellazione i sistemi in-memory offrono, solitamen-

Organizzazione per righe Organizzazione per colonne