Oggi proviamo ad affrontare uno degli aspetti più complessi (e utili da conoscere) di SAP BO: i contesti di calcolo.
Quando si parla di contesti di calcolo su SAP BO ci sono due possibili reazioni:
- “Va beh si tratta di formuline semplici ed intuitive, si usano i “per ogni” e “per tutti”, non capisco perché spaventino così tanto”
- “Nooo sono sempre un bagno di sangue”
La prima solitamente è la reazione di chi non li ha mai usati o non ne ha capito realmente a fondo l’utilizzo, la seconda quella più comune 😉
Nel mezzo ci possono essere le altre sfumature.
Proviamo a fare chiarezza su questo tema per non cadere né nella prima reazione né nella seconda.
SAP BO
Partiamo dalle basi per inquadrare di cosa parliamo. Sap BO è uno strumento di front end (non il più bello graficamente) che permette di creare dashboard con grafici e tabelle dati.
Trattandosi di uno strumento di front end non dispone di un proprio database ma estrae i dati al momento della chiamata da qualche database.
Ci sono due modi principali:
- Mediante query BEx, in questo caso estrae dati da SAP BW (o BW4Hana ). Diciamo che in questo caso i dati vengono estratti passando attraverso una query su cui solitamente vengono già gestite tutte le aggregazioni e le relative eccezioni e quindi tendenzialmente non c’è bisogno di effettuare altre operazioni su BO (se non piccole logiche di trascodifiche )
- Mediante Webi. In questo caso si estraggono dati da altri DB (SAP e non SAP). Non potendo basarsi su query già strutturate si estrae direttamente da una o più tabelle del DWH e lo si fa creando degli universi. Tali universi sono union o join di tabelle del DWH che formano il set di dati che sarà utilizzato da BO. In questo caso però potrebbero essere necessarie maggiori logiche su BO per poter mostrare correttamente il dato.
Come avrete intuito il caso solitamente più spinoso è quello rappresentato dagli universi in quanto non vi è un lavoro preliminare di data- presentation e pertanto tale lavoro deve essere effettuato su BO. Ovviamente non sempre è necessario ricorrere ai contesti di calcolo perché molto dipende da come sono strutturate le tabelle (quale livello di granularità hanno, le chiavi delle tabelle e le relazioni tra le varie tabelle) e da quello che si vuole mostrare.
Ma prima di addentrarci nei contesti di calcolo, che rappresentano una eccezione rispetto al classico modo in cui le informazioni vengono aggregate, facciamo un altro piccolo passettino e cerchiamo di capire come vengono gestite normalmente le aggregazioni da SAP BO.
Aggregazioni su SAP BO
BO, come moltissimi strumenti di data visualization, è uno strumento in grado di aggregare i dati o espandere il set informativo aggiungendo delle dimensioni di analisi.
Il funzionamento è molto simile a quello di una tabella pivot su excel in cui si decide quali dimensioni esplodere e quali KPI mostrare. Sulla base di queste informazioni il KPI verrà mostrato semplicemente sommando tutti i valori che corrispondono alla dimensione di interesse (o contando, facendone la media ecc).
Per chiarire meglio le idee proviamo a ragionare su BO e su Excel facendo un parallelo:
Tabella Pivot
Partiamo da excel che uno strumento molto più conosciuto. Immaginiamo di avere la situazione seguente:
Due tipologie di clienti che possono acquistare diversi prodotti e nella tabella precedente sono riportati i valori di incasso nel mese.
Se effettuiamo una tabella pivot su questo set di dati potremmo ottenere ad esempio:
In questo caso la tabella pivot ha sommato il KPI sulla base della dimensione che abbiamo esposto aggregando correttamente gli importi.
SAP BO
Se volessimo ottenere un risultato simile su SAP BO sarebbe estremamente semplice in quanto basterebbe trascinare con il meccanismo di drag e drop la dimensione di interesse e il KPI (proprio come nella tabella pivot) e BO si occuperebbe di aggregare i dati e mostrare il risultato.
Immaginando di avere nel nostro universo la stessa tabella che avevamo visto su excel, volendo estrarre tutto l’universo vedremmo :
A questo punto basterebbe semplicemente non esporre la colonna “Tipologia clienti” per avere la pivot1 oppure non esporre Tipo prodotto per avere la pivot 2.
Ora che il concetto di aggregazione è chiarito tramite questo stupidissimo esempio, proviamo a ragionare sulle eccezioni di aggregazione.
Eccezioni di aggregazione
Per eccezioni di aggregazione si intendono tutte quelle circostante per cui non si possono aggregare i dati semplicemente mostrando la somma del KPI. Se ad esempio avessimo il seguente set di dati:
E volessimo conoscere la penetrazione media di mercato dei vari prodotti? Poiché la penetrazione sarebbe data dal numero di vendite di quel prodotto specifico diviso il numero di prodotti venduti in tutto, non possiamo semplicemente aggregare i dati ma siamo costretti a fare qualche passaggio in più.
Prima di vedere come questo sarebbe implementabile su BO proviamo a ragionare per step su questo semplice esempio.
Step 1
Aggreghiamo la tabella per prodotto eliminando il dettaglio del tipo cliente in quanto non richiesto :
A questo punto per poter sapere la penetrazione del singolo prodotto dovremmo dividere il valore così ottenuto per la somma di tutti i pezzi (i 190 pezzi mostrati nel totale complessivo).
Su excel, trattandosi di uno strumento che lavora sulla base delle celle che vengono considerate basterebbe effettuare la divisione bloccando la cella che contiene il 190.
Ma poiché su SAP BO (né su altri strumenti di front end evoluti) è possibile ragionare per celle, proviamo a capire come potremmo ottenere il medesimo risultato.
Step 2
Avremmo bisogno di un ulteriore KPI legato al singolo prodotto che riporta il totale di pezzi venduti a prescindere da quello che c’è in riga.
Ecco tutto il mondo delle eccezioni di aggregazione ruota intorno alle parole “a prescindere da quello che c’è in riga”. In pratica stiamo forzando il sistema ad effettuare un’aggregazione che non è quella che farebbe in quanto non deve tener conto della chiave della tabella che sta mostrando (nel nostro esempio il tipo di prodotto).
Come si vede chiaramente dall’esempio riportato sopra, per ognuna delle righe della nostra tabella pivot (ossia dell’aggregazione del nostro DB) abbiamo bisogno di una colonna che effettua il totale di tutto il DB.
Il fatto che abbiamo dovuto bloccare l’intervallo di calcolo della formula su excel racconta proprio il fatto che il risultato che vogliamo ottenere è indipendente da quello che abbiamo nelle righe della tabella pivot (altrimenti avremmo dovuto in qualche modo legare la formula alla riga della tabella pivot).
Step 3
A questo punto possiamo effettuare la divisione tra le due colonne in modo da ottenere il KPI di interesse.
Ovviamente la parte più interessante del discorso è racchiusa nello step 2. Questo è solo un esempio delle casistiche di eccezione di aggregazione in cui abbiamo necessità di aggregare “di più” rispetto a quello che ci si attenderebbe, ma ci sono moltissimi casi in cui è necessario non aggregare o considerare solamente alcune delle righe che verrebbero aggregate ecc.
Un esempio semplice da capire è quando la misura non è cumulabile come ad esempio medie o percentuali.
Contesti di calcolo su SAP BO
I contesti di calcolo sono esattamente eccezioni di aggregazione. Dobbiamo cioè creare delle variabili formula che aggreghino in maniera differente rispetto a quello che farebbe in automatico SAP BO.
E sta a noi “insegnare” al sistema come aggregare le informazioni, attraverso delle istruzioni che possono essere:
- For Each
- For All
- In
Ed è qui che di solito si scivola nella semplificazione in quanto si tratta di formule apparentemente semplici.
Dico apparentemente in quanto, in questo caso, la complessità non sta nello scrivere la formula quanto nel capire come quella formula sta lavorando e se funziona correttamente sulla base dell’aggregazione che vogliamo ottenere nel report.
Per la mia esperienza personale, le due espressioni che vengono utilizzate più di frequente sono ForEach e ForAll, che funzionano esattamente all’opposto ma molto spesso vengono confusi e fraintesi.
Volendo semplificare:
ForEach serve per aggiungere una dimensione al calcolo, ForAll per togliere una dimensione dal calcolo
Riconosco che la frase che ho appena scritto potrebbe essere poco chiara (tra poco vedremo qualche esempio) ma mostra la differenza concettuale dei due operatori.
ForEach e For All
Come abbiamo visto precedentemente, le casistiche per cui diventa necessario applicare delle eccezioni di aggregazioni possono essere tante ma di fatto ricadono in due macro-aree:
- Devo effettuare calcoli tenendo conto di una dimensione non esplicitata nel report => ho necessità di aggiungere una dimensione al calcolo
ESEMPIO:
Calcolare il ricavo massimo per quadrimestre in un report che mostra solamente l’andamento annuale. In questo caso la granularità del dato da mostrare è quella dell’anno (quindi più aggregato) e per ogni anno voglio mostrare qual è stato il massimo ricavo in un quadrimestre. Per farlo devo calcolare il ricavo aggregando per quadrimestre, individuare il quadrimestre che riporta il massimo ed esporre quel dato per l’anno di interesse.
Nel momento in cui dico che devo calcolare il ricavo per quadrimestre (dimensione non esposta nel report) sto dicendo che ho bisogno di aggiungere una dimensione al mio contesto di calcolo.
Ipotizziamo quindi di avere un dataset di questo tipo:
Per ogni anno devo individuare quale quadrimestre ha il ricavo massimo, ragionando quindi anno per anno e si vede che per per l’anno 1 il quadrimestre “migliore” è il primo, per il secondo anno sceglierei il quarto quadrimestre ecc:
E a questo punto possiamo aggregare il dato per ottenere il report con vista annuale:
Qui dovrò usare l’operatore forEach per aggiungere una dimensione ottenendo una formula del tipo:
Max ([ricavo] ForEach ([Quadrimestre]))
- In un report abbiamo un livello di dettaglio molto spinto e vogliamo ottenere un’informazione più aggregata. In questo caso abbiamo necessità di togliere una dimensione dal calcolo e “aggregare di più”.
ESEMPIO:
Proviamo a ribaltare l’esempio. Nel report devo mostrare anno, quadrimestre e ricavo totale dell’anno. In questo caso il mio livello di dettaglio di esposizione è quello del quadrimestre ma ho bisogno di una colonna che aggrega ulteriormente il dato e mi restituisca la somma di tutto l’anno. Qui i passaggi logici sono invertiti rispetto all’esempio precedente in quanto bisogna inserire un passaggio ulteriore rispetto all’aggregazione di default. Riprendendo la casistica dell’esempio precedente, avremmo gli stessi importi per quadrimestre:
In questo caso dovremmo aggregare per anno ottenendo:
E a questo punto “incollare” tale informazione al nostro report che diventerebbe:
In questo caso quindi abbiamo necessità d utilizzare il forAll per togliere una dimensione in quanto dobbiamo calcolare la somma dell’anno non considerando il quadrimestre che è esposto in riga ottenendo una formula del tipo
Sum ([ricavo] ForAll ([Quadrimestre]))
Come si vede benissimo dagli esempi appena riportati, a determinare quale operatore utilizzare non è il set di dati che abbiamo a disposizione ma la differenza di granularità tra quello che viene esposto e la misura che dobbiamo calcolare.
Ho volutamente riportato il medesimo esempio per mostrare la complessità insita nel contesto di calcolo che, come dicevo all’inizio dell’articolo, non sta nella scrittura della formula quanto nel capire quale operatore utilizzare sulla base del risultato che si vuole ottenre
Operatore “In”
Ho lasciato per ultimo l’operato IN in quanto a mio avviso è di più semplice comprensione ed utilizzato meno frequentemente.
L’operatore in viene utilizzato per specificare quali sono le dimensioni da utilizzare nel contesto di calcolo tra quelle esposte nel report.
Sono un consulente di Business Intelligence,lavoro con uno dei software di Business Intelligence più importanti e completi sul mercato che è SAP BW (da poco diventato BW4HANA), e ho avuto modo di lavorare con grandissime realtà nazionali ed internazionali.
In tutte queste realtà ho avuto modo di entrare nella vita aziendale conoscendone i processi, i problemi, e le necessità e di relazionarmi con key user, decision maker, manager e personale operativo per riuscire a costruire report e dashboard che facilitassero il loro lavoro e permettessero in pochissimi click di ottenere tutte le principali informazioni sull’andamento della società.
Ho iniziato a fare divulgazione sul tema Business Intelligence per spiegare anche ai non addetti ai lavori quanto sia importante ragionare sempre in funzione di dati e come sfruttare la tecnologia per prendere decisioni migliori.
Le informazioni hanno un valore inestimabile e sono la cartina al tornasole di qualsiasi business mentre i dati da soli sono solo numeri!
