Capitolo 5 Reportistica e output del sistema

Capitolo 5

Reportistica e output del sistema

A questo punto della tesi abbiamo in mano tutti gli strumenti per poter svolgere i controlli e le analisi desiderate. In questo capitolo focalizzeremo l’attenzione sulle potenzialità del sistema analizzato fino ad ora. Faremo alcuni esempi di reportistica studiando le tipologie di domande cui è in grado di rispondere e le differenze tra la prima parte del sistema, quella di rilevazione, e la seconda, quella preposta per l’effettiva analisi dei dati.

5.1 Avvicinare manager e informatici

È da notare come sia stata volutamente posticipata la valutazione delle prestazioni del sistema nelle sue due fasi, descritte rispettivamente nei capitoli tre e quattro. Questa scelta è dovuta principalmente a due motivi, il primo dei quali è la possibilità di poter, in questo modo, confrontare i due sistemi fino in fondo, andando a vedere cosa siano in grado di fare nel concreto. Il secondo,

probabilmente il più importante, riguarda ancora una volta l’interazione tra la tecnologia ed il management. Questa impostazione offre infatti al manager la possibilità di andare a vedere direttamente cosa nel concreto gli venga offerto e valutarne le potenzialità.

5.2 Reportistica e comunicazione verticale.

Sat è caratterizzata, nel suo assetto societario, da un numero di livelli gerarchici piuttosto limitato, per fare in modo che ci sia un contatto sempre diretto tra persone che svolgono diverse mansioni ma accomunate da un unico obiettivo finale. È questa una vera e propria scelta strategica dell’azienda, al contrario di tante realtà nelle quali ci si imbatte in processi burocratici che rischiano tra l’altro di danneggiare l’intera struttura e quindi anche il flusso informativo. Lo scambio di informazioni è importantissimo all’interno delle aziende, sia nel momento in cui i supervisori assegnano i compiti e trasmettono le direttive ai livelli inferiori, ma soprattutto nel momento in cui, a consuntivo, dagli stessi livelli più bassi le informazioni tornano ai decisori presentando i risultati del proprio operato. Ci sono poi altri tipi di informazioni, che verosimilmente un soggetto ricava da sé per espletare le proprie funzioni, senza attingere a fonti umane ma solo da documenti o da fonti informatiche.

Entrambi i sistemi visti finora sono indispensabili nell’uno e nell’altro caso, in quanto consentono a coloro i quali gestiscono, per ora manualmente, i dati di vendita di automatizzare le proprie attività ottenendo in questo modo un’accelerazione delle operazioni, tramutandole spesso in semplici controlli routinari di correttezza. Ma non solo, perché consentono di trasferire la conoscenza acquisita nel modo migliore ai propri supervisori, grazie alla compilazione della reportistica.

Ciò che caratterizza i sistemi informativi e informatici in particolare è senz’ombra di dubbio la possibilità di tenere traccia di quanto accaduto, con una perfetta catalogazione e senza alcun dispendio in termini economici e spazio-temporali.

5.3 Rilevare per controllare…

Questa parentesi ci permette di mostrare cosa sarebbe in grado di fare il sistema se venisse implementata solo la parte di mera rilevazione delle transazioni, quella, per intenderci, descritta nel capitolo tre.

I computer dei singoli negozi, collegati, come già detto in precedenza, ai registratori di cassa, sarebbero in grado di trasmettere, tramite una semplice rete locale, tutti i dati della transazione, compresi quelli del cliente nel caso in cui si trattasse di un passeggero in partenza e disponesse della carta d’imbarco rilasciata al check-in. Questi dati giungono poi al server, il quale memorizza tutto quanto ricevuto in una apposita struttura dati , interrogabile anche in un secondo momento. I passi appena descritti avvengono in completa automazione, a parte chiaramente quelli relativi alla registrazione dell’acquisto tramite registratore di cassa da parte del commerciante.

Ciò risolve in parte i quesiti e le necessità avanzate da Sat, in quanto è possibile tramite questo modello controllare anche lo svolgimento regolare delle attività commerciali all’interno dell’aerostazione. Il secondo punto è relativo alla gestione dei negozi in termini economico-finanziari. Noi sappiamo che Sat percepisce per contratto di subconcessione una percentuale sul fatturato di ogni attività, variabile a seconda del singolo accordo. Solitamente però accade che mensilmente i responsabili di ogni negozio portino manualmente una copia del libro dei corrispettivi con indicati i volumi di vendita e di

conseguenza i ricavi di Sat. È evidente che in questo modo tutto ciò non si renderà più necessario, perché saranno dei calcoli che il sistema sarà in grado di effettuare in automatico, oltre al vantaggio molto importante di poter osservare gli andamenti in qualsiasi momento e non soltanto al termine di ogni mese.

La reportistica che il prodotto fornirebbe sarebbe relativa principalmente ai due aspetti appena visti, uno per mostrare eventuali anomalie in merito al controllo e l’altro per presentare i resoconti periodici della gestione ordinaria, consentendo quindi di registrare e trasmettere i ricavi per quanto riguarda il settore non-aviation, da integrare sempre con la gestione dell’advertising e dei parcheggi, altri due grandi rami del settore non-aviation. In realtà tutto quanto appena detto è facilmente deducibile dalla lettura del capitolo tre, in cui vengono presentati tutti i singoli elementi del sistema. Questa semiridondanza è dovuta principalmente al fatto che l’offerta del sistema, in termini di possibilità d’uso è abbastanza evidente e statica, limitata ai due grandi rami descritti sopra. Ciò non significa certo che sia di scarso valore o utilità, ma semplicemente che si tratta di attività basilari ed evidenti, anche in virtù del fatto che risponde esattamente a quanto richiesto da Sat.

5.4 …e registrare per analizzare

Così come la descrizione del modello è stata suddivisa in due parti sufficientemente autonome, almeno per quanto concerne la descrizione dei prodotti, anche per mostrarne i risultati è bene distinguere cosa possa essere fornito da una parziale implementazione da quello che sarebbe in grado di fornire l’intero sistema proposto. Nel capitolo quattro abbiamo visto qualche esempio di modellazione multidimensionale per il Datawarehouse pensato per

l’aeroporto di Pisa e lo abbiamo fatto proprio con l’obiettivo, oltre che di mostrarne il funzionamento, di preparare le basi per analizzare la tipologia e la qualità della reportistica ottenibile. Di seguito riportiamo uno dei due cubi già visti in precedenza e ne proporremo un ulteriore, per affinare la dimostrazione di funzionalità ed utilità.

Negozi Vendite

Voli

Tempo

Fig. 5.1 Esempio di cubo multidimensionale numero 1

Prima di procedere con gli esempi è bene notare che le operazioni sui cubi sono fondamentalmente degli insiemi di query (interrogazioni). L’utente esperto ha quindi la possibilità, se il sistema lo prevede, di accedere direttamente al Datawarehouse per effettuare delle interrogazioni senza dover passare attraverso le strutture multidimensionali, che trovano la loro massima utilità soprattutto nell’utilizzo da parte dei soggetti decisori meno esperti

nell’utilizzo di questi sistemi e caratterizzati nel loro lavoro da una scarsa disponibilità di tempo.

La scelta delle dimensioni coincide quindi, per il sistema, con le prime operazioni di interrogazione, selezionando le giuste tabelle e i relativi attributi, nonché andando a verificare l’effettiva compatibilità delle scelte effettuate.

L’utente si trova poi di fronte alla struttura multidimensionale che gli permetterà, grazie agli operatori già presentati, di plasmare la struttura a suo piacimento ed estrapolarne le informazioni richieste, che si trasformeranno poi in conoscenza di importanza strategica.

Vediamo ora, nel concreto, alcune delle domande cui il cubo riportato in figura 5.1 è in grado di rispondere. Data la scelta delle dimensioni la domanda più ovvia sarà sicuramente: qual è stato il volume di vendite per il negozio X

nel periodo di tempo T effettuate a clienti che siano anche passeggeri della compagnia aerea C? Sappiamo che la dimensione tempo si presenta con una

gerarchia piuttosto ampia, potendo aggregare fino all’anno di competenza oppure andare nel dettaglio fino addirittura all’ora dell’acquisto, perché uno dei dati importanti per Sat è per esempio la distribuzione delle vendite nelle diverse fasce orarie. Per quanto riguarda le altre due dimensioni il discorso è semplice, in quanto sono delle tabelle contenenti i dati dei negozi l’una e quelli dei voli l’altra. Per rispondere a queste domande basterà quindi selezionare il quadratino nel punto di incontro tra le dimensioni tempo, negozio e voli nel quale tutti e tre rispondono ai requisiti richiesti.

Chiaramente per far ciò non si avrà a disposizione un cubo fisico da modellare con le mani. Si parla sempre di prodotti e strumenti informatici e quindi anche quando si parla di navigazione di cubi è semplicemente l’esplorazione multimediale da parte del soggetto decisore che ha in questo modo un impatto visivo decisamente più immediato e soprattutto non ha l’obbligo di imparare linguaggi di interrogazione come l’Sql (linguaggio di

interrogazione per database) che per interrogazioni di una certa natura non è certo di semplice utilizzo. Tra l’altro nella presentazione degli operatori sui cubi abbiamo visto come sia possibile effettuare restringimenti di campo d’azione con il drill-down o l’utilizzo del roll-up, tutte operazioni che il sistema effettua con una serie di combinazioni composite di istruzioni sql.

In fondo alle righe o alle colonne (in base al verso di considerazione), solitamente vengono inserite delle celle riepilogative, che vanno a formare nel complesso un’ulteriore riga o colonna ma che in realtà all’interno della singola cella contengono appunto dei dati che vengono ottenuti considerando tutti gli altri dati. Per esempio può essere riportato il totale di riga (o colonna) oppure la media, etc. Insomma delle funzioni di aggregazione che consentono in questo modo di ignorare una dimensione, inteso nel senso che, se torniamo alla domanda precedente possiamo pensare per esempio di chiederci quali siano i dati di vendita del negozio X nel periodo T in totale cioè considerando tutti i voli senza fare distinzione e prendendone il totale. Lo stesso discorso è valido per i negozi, considerando quindi tutte le vendite dell’aeroporto oppure con la dimensione tempo, cioè analizzando le vendite del singolo negozio relativa al preciso volo ma senza limiti di tempo.

Queste aggregazioni possono essere fatte anche su due dimensioni contemporaneamente, nel senso che si può prendere in considerazione la cella che si trova esattamente nell’incrocio tra due assi, il che ci porterà per esempio a sapere il volume di vendite di un negozio (se aggreghiamo sia sul tempo che sui voli).

Tutte queste supposizioni sono fatte a partire da un unico cubo preso come esempio. Nella realtà invece di cubi se ne possono fare numerosi, e soprattutto non è obbligatorio prendere sempre in considerazione direttamente le tabelle delle dimensioni, ma si può anche fare riferimento a quelle che sono chiamate

anticipo che certe operazioni verranno fatte sicuramente. Quindi anche nelle dimensioni, così come nelle misure possiamo incontrare delle formule precomposte, che mostrano all’utente direttamente il risultato.

Per terminare il capitolo mostriamo degli altri risultati ottenibili, anche se questa volta in forma più schematica, dato che il metodo è già stato ampiamente spiegato. Vengono presentati dei cubi che virtualmente interrogheremo andando a vedere in questo modo quali domande siano formulabili e quale sia di volta in volta la disposizione più adatta per le dimensioni.

Naziònalità Vendite

Aeròpòrti

Tempo

Fig. 5.2 Esempio di cubo multidimensionale numero 2

Il cubo di figura 5.2, presenta dei dati molto particolari. La domanda più ovvia alla quale può rispondere è: qual è stato il volume di vendita nel tempo T

In questo modo si può per esempio capire se si tratti di traffico passeggeri

incoming o outcoming, cioè, fermo restando il fatto che siano passeggeri in

partenza potrebbe trattarsi di passeggeri che tornano a casa o che partono da casa. Ma come al solito, se si considerano le celle di fine riga o fine colonna si possono aggregare generalizzando su una o due dimensioni, chiedendosi per esempio quali siano state le vendite al tempo T per i passeggeri di nazionalità N, prescindendo quindi dall’aeroporto di destinazione/partenza.

Negòzi Vendite

Compagnie aeree

Tempo

Fig. 5.3 Esempio di cubo multidimensionale numero 3

In fig. 5.3 vediamo riportato un altro esempio di rappresentazione multidimensionale.

Questo cubo in particolare può essere utile al decisore dell’azienda perché aiuta a far capire quale sia la redditività dei negozi in rapporto alla compagnia aerea, mostrando quali siano i volumi di vendita del singolo negozio rapportato alla singola compagnia, o come al solito aggregando sui negozi o sulle compagnie stesse. Stesso identico discorso potrebbe essere fatto mantenendo la dimensione negozio e mettendoci quella degli aeroporti per capire per esempio quali siano i mercati da potenziare perché probabilmente i passeggeri di una certa nazionalità o che partono da un particolare aeroporto hanno un valore medio di acquisti piuttosto elevato.

Tutto quanto appena detto è importante soprattutto in virtù di quanto presentato nel contesto dei ricavi aviation e non-aviation e dell’influenza che gli uni hanno sugli altri. Sappiamo infatti che al giorno d’oggi la fonte primaria di guadagno per le società di gestione aeroportuale è senz’ombra di dubbio quella legata al commercio e non al traffico passeggeri, ma sappiamo anche che c’è un indubbio legame tra questi due mondi. Ecco allora perché si rende fondamentale un’opportuna osservazione dei volumi di vendita in rapporto al traffico passeggeri, ancor più se si può disporre di un impatto visivo che permetta di rilevare immediatamente le anomalie.

A questo punto è importante fare una precisazione. Abbiamo detto che quanto proposto in questa tesi più che un Datawarehouse vero e proprio è un Datamart, che prende in considerazione solo ed esclusivamente i dati commerciali di vendita e che offre le sue potenzialità agli stessi responsabili commerciali. In realtà, soprattutto alla luce di quanto appena visto sui cubi, sarebbe importante e di indubbia utilità mettere in rapporto i dati di vendita con quelli di traffico. Il motivo è semplice. In base alle analisi di cui abbiamo parlato fino ad ora potrebbe per esempio risultare che i clienti russi hanno un importo medio d’acquisto superiore alla media, però non possiamo sapere in alcun modo quanti siano effettivamente i passeggeri che acquistano sul totale

dei passeggeri provenienti da tale paese. Se tra tutti i clienti dei negozi in un certo periodo c’è solo un russo che ha acquistato, e lo ha fatto spendendo parecchi soldi, è chiaro che il nostro sistema rileverà questo dato anche come media di periodo, essendo appunto l’unico, ma in realtà la significatività del dato è molto limitata. Se noi invece potessimo mettere in comunicazione le due fonti di dati le informazioni ricavate avrebbero una significatività superiore perché scoprire che i passeggeri provenienti da Londra spendono in media una certa cifra e acquistano con una certa percentuale di probabilità sul totale del traffico per quella destinazione è molto più importante che non sapere semplicemente quanto spendono. È chiaro che Sat, disponendo internamente dei dati inerenti il riempimento di tutti i voli presi uno per volta può ricavare i risultati anche manualmente, ma è ovvio che vengono meno i vantaggi dell’automazione e di tutto quanto presentato fino ad ora, comportando inoltre dei tempi di elaborazione piuttosto lunghi, senza tra l’altro avere garanzia sull’affidabilità dei risultati stessi.

5.5 Migliorare le capacità del sistema

Un punto su cui è importante porre un accento è la competenza del soggetto decisore, che nell’interazione con il sistema diventa assolutamente fondamentale. Quanto presentato fino ad ora, nonostante l’estrema dinamicità e l’indiscutibile valore innovativo, perderebbe gran parte del suo significato se non si offrisse al manager la possibilità di interrogare il sistema nel modo ritenuto più idoneo, sfruttando dunque, parallelamente, anche la propria esperienza. Il nostro obiettivo non è dunque quello di fornire all’utente uno strumento fine a se stesso, da utilizzare o meno con delle potenzialità delimitate. È piuttosto quello di cercare di mostrare, aiutati da qualche

intuizione appresa grazie agli stessi manager, in quale modo riuscire a conciliare le esigenze informative proprie dei soggetti decisori con le potenzialità del sistema.

La prima premessa importante da fare riguarda il fatto che dopo aver implementato la base del sistema, a partire dalla base di dati fino ad arrivare al Datawarehouse, l’utente ha la possibilità, tramite strumenti dotati di una semplice interfaccia, di plasmare al meglio l’ambiente di lavoro in cui operare, creando delle applicazioni di supporto all’attività di costruzione dei cubi. Questo è dovuto proprio alla forte soggettività con la quale si rende possibile l’utilizzo di questi strumenti.

A tal proposito il primo elemento in grado di determinare da solo l’efficacia o meno di alcuni metodi di lavoro è senz’ombra di dubbio la scelta delle dimensioni, a partire dalle quali ricavare i parametri da misurare. Nel capitolo quattro abbiamo presentato alcune gerarchie, poi riprese nella prima parte di questo capitoli, e che possono diventare importanti soprattutto nel momento in cui la dimensione con gerarchia venisse presa in considerazione per la costruzione di una rappresentazione multidimensionale. Le gerarchie in questione sono comunque state ricavate semplicemente dal modo in cui alcuni attributi erano strutturati. È questo il caso della dimensione tempo, in cui risulta piuttosto intuitiva la suddivisione in giorni-mesi-anni. In realtà, grazie alle applicazioni di supporto menzionate in precedenza, si rende possibile, senza alcuna difficoltà di utilizzo, la creazione di ulteriori gerarchie, ricavabili dai dati esistenti, e che non richiedono dunque una registrazione permanente nella struttura dati.

Per fare un esempio concreto è pensabile che il responsabile commerciale di Sat, grazie all’esperienza accumulata, nonché alle competenze in materia di marketing aeroportuale, trovi significativa la possibilità di strutturare i dati relativi al tempo secondo un criterio differente, in base al valore stagionale dei

dati rilevati oppure al momento dell’acquisto, che può essere effettuato in un giorno feriale o in uno festivo. Ogni analisi può avere un obiettivo differente, improntato dunque su differenti organizzazioni dei dati.

anno mese Stagione dell’anno giorno Giorno della settimana ora Fascia oraria b) a)

fig. 5.4 differenti gerarchie per la dimensione tempo

In fig. 5.4 sono riportati due esempi di altrettante gerarchie, identificate tra le tante possibili da applicare. La b) è la stessa proposta nel capitolo precedente, ottenuta dalla semplice ed intuitiva analisi gerarchica tra gli attributi anno, mese, giorno ed ora. Questa è contrapposta ad una visione totalmente differente (a) dell’organizzazione temporale delle vendite nelle attività commerciali. Ovviamente la a) non ha assolutamente la pretesa di essere esaustiva, ma di mostrare al lettore la concreta possibilità di mettere in pratica una propria visione dei fatti. Il criterio da noi seguito nella costruzione di questa gerarchia è legata al fatto che il responsabile commerciale di Sat

solito. In questo caso, infatti, potrebbe essere interessante suddividere gli acquisti in base alle fasce orarie, identificate preliminarmente dall’utente in base alla propria esperienza. Per esempio potrebbe essere significativo distinguere tra fasce a cavallo delle ore di picco di traffico, piuttosto che le ore di punta del mattino e quelle di più basso afflusso del tardo pomeriggio. Salendo nella scala troviamo i giorni settimana, che possono essere visti secondo la concezione classica dal lunedì alla domenica, oppure semplicemente distinguendo tra feriali, festivi e prefestivi. Anche per la categoria più alta, infine, la stagionalità può assumere diversi risvolti. Può essere interpretata secondo le stagioni climatiche, (tra inverno, estate ed intermedie, per intendersi) oppure il manager potrebbe aver identificato delle fasce stagionali che hanno senso di essere interpretate in altro modo. Non è assolutamente fuori luogo pensare che per stagioni si intenda la distinzione tra periodi a cavallo delle feste, religiose o pagane che siano, da quelli privi di festività, per studiare l’andamento delle vendite in rapporto a questi dati.

Da quanto descritto finora dovrebbe risultare ancora più semplice la comprensione delle potenzialità offerte da uno strumento di questo tipo, anche se in realtà le vere potenzialità non sono insite nello strumento ma nelle capacità di chi ne fa uso. Nella fig. 5.5 vediamo degli ulteriori esempi di gerarchie, applicate questa volta alla dimensione aeroporti.

Nazione Continente Zona continentale Importanza territoriale Traffico Città a) b)

Fig. 5.5 esempi di gerarchie applicabile alla dimensione aeroporti

Nella definizione delle gerarchie ciò che si rende di fondamentale importanza è la possibilità di poter ottenere le informazioni necessarie sempre e comunque partendo dai dati contenuti nel Datawarehouse, senza cioè dover attingere a fonti esterne. L’unica cosa necessaria è l’identificazione, da parte dell’utente delle categorie ritenute maggiormente idonee per l’ottenimento di certi tipi di informazioni. Nell’esempio riportato in fig. 5.5 vengono presentati uno accanto all’altro due esempi di gerarchia ottenibile dalla dimensione aeroporti, per la quale abbiamo previsto semplicemente gli attributi codice, città e nazione. I nomi riportati nella figura non rientrano dunque tra gli attributi menzionati, ma li abbiamo ricavati da una possibile interpretazione della realtà. Nel primo caso per importanza territoriale si potrebbe intendere la distinzione tra capitali nazionali, capoluoghi di regione, di provincia, oppure nessuna di queste. Dopodiché, dopo esser passati per l’attributo nazione, già presente nel Datawarehouse, queste possono essere raggruppate per continente, naturalmente sotto identificazione, peraltro ovvia, da parte dell’utente.

La seconda ipotesi è quella di suddividere gli aeroporti in base al traffico, in termini di passeggeri per ogni anno, e quindi per zona continentale. Quest’ultima potrebbe essere vista sia come suddivisione geografica classica, con una distinzione dunque tra paesi scandinavi piuttosto che mediterranei o oceanici, ecc. Potrebbe però essere interpretata anche in un altro modo, ovvero raggruppando le nazioni secondo qualche altro criterio identificato dal soggetto decisore, quale potrebbe essere per esempio una classificazione climatica oppure identificata nel tempo in base a quanto notato a proposito delle similitudini nei comportamenti d’acquisto dei clienti delle varie nazionalità.

Ricordiamo ancora una volta che le gerarchie presentate finora sono soltanto indicative, per quanto abbiamo cercato di utilizzare comunque degli esempi che avessero un significato effettivo, soprattutto in virtù del fatto che nel seguito verranno utilizzate per creare degli esempi di report.

5.6 Tabelle pivot per la reportistica

In precedenza abbiamo parlato di cubi, ne abbiamo visti degli esempi concreti, focalizzandoci su quelle che sono le domande standard cui sono in grado di rispondere. Abbiamo detto anche che la struttura tridimensionale è dovuta alla comodità dettata dall’impatto visivo, e che per rappresentare un numero di dimensioni superiore a tre la soluzione più semplice sarebbe quella di utilizzare un numero di cubi maggiore, aggregando di volta in volta sugli attributi non considerati nella rappresentazione.

Esiste comunque un altro strumento in grado di operare contemporaneamente su un arbitrario numero di dimensioni, e che, seppur a scapito dalla comodità visiva, offre una semplicità di utilizzo che lo rende importante per i manager. Stiamo parlando delle tabelle pivot, che grazie al

maggior dettaglio con il quale sono in grado di rappresentare le informazioni, possono rispondere a domande molto più complesse di quelle viste fino ad ora per i cubi, comportando dunque un vantaggio assoluto per le aziende. Inoltre sono lo strumento ideale soprattutto nel caso in cui si operi su dimensioni con gerarchie.

È ragionevole immaginare uno scenario in cui, dato il rapporto, menzionato in più contesti, tra i ricavi aviation e quelli non-aviation, il manager si trovi a consultare i dati storici rappresentati nella tabella pivot per stimare il possibile impatto dell’inserimento di una nuova rotta nella road-map sui ricavi non-aviation. Per far questo nel migliore dei modi può rivelarsi utile la consultazione dei dati che vengono ritenuti più simili in base a delle caratteristiche identificate, come detto in precedenza, nelle gerarchie.

In fig. 5.6 abbiamo dunque ipotizzato il caso in cui i manager di Sat si trovino a dover scegliere una nuova rotta tra un gruppo di candidate, selezionate su criteri prettamente legati al settore aviation. La tabella può offrire la possibilità di stimare l’impatto della nuova rotta sul settore non-aviation. Nella selezione delle dimensioni e degli attributi abbiamo immaginato che la scelta dovesse ricadere su un aeroporto situato in una città dell’Europa occidentale. Abbiamo dunque ristretto innanzitutto il raggio d’azione effettuando uno slice sull’attributo zona continentale della dimensione

aeroporti, ricavato dalla gerarchia identificata in precedenza. In questo modo si

è reso possibile il restringimento dell’analisi ai soli paesi scandinavi, in modo da poter eliminare dal computo i dati non direttamente interessati. Entrando nel dettaglio della gerarchia troviamo l’attributo traffico, che permette all’utente di catalogare gli aeroporti in base ai volumi annui di traffico passeggeri (dati esterni al DW). In questo caso, ipotizzando che gli aeroporti tra i quali selezionare quello verso cui dirigere la nuova rotta siano tutti compresi nelle fasce 5-10 milioni e 10-20 milioni (valori puramente indicativi), abbiamo

ristretto l’analisi anche in questo senso, considerando appunto solo le due fasce interessate. All’interno delle due fasce potremmo direttamente riportare il totale delle vendite. In realtà, però, potrebbe rivelarsi utile suddividere le vendite anche per singolo negozio, studiando in questo modo i diversi tipi di acquisto effettuati dai clienti. Può ancora essere importante lo studio dell’andamento delle vendite suddivise per singoli anni, magari aggregando (roll-up), come nel nostro caso, quelli precedenti una certa data.

A questo punto è possibile prendere singolarmente gli aeroporti candidati per la nuova rotta e stimare l’impatto della scelta sul volume delle vendite.

Fig. 5.6 esempio di tabella pivot con gerarchia b) sulla dimensione aeroporti Dimensione: Aeroporti

Zona continentale: Europa occidentale

Traffico: 5-10 milioni di pax 10-20 milioni di pax

Dimensione: Negozi Importo

Vendite

(/1000)

Fashion

Gate Oca Bianca … Tot Fashion Gate Oca Bianca … Tot <2001 180 150 .. ₉₈₀ 380 290 .. ₁₅₈₀ 2001 120 80 .. ₆₀₀ 260 210 .. ₁₂₃₀ 2002 120 90 .. ₆₂₀ 220 160 .. ₁₇₆₀ 2003 130 110 .. ₈₀₀ 230 190 .. ₁₃₅₀ Dim: Tempo Tot _{550 430 .. 3000 1090 850 .. 5920}

La supposizione fatta in precedenza in merito alle diverse gerarchie possibili sui dati ci può essere utile anche in questo caso. Può accadere infatti, che il manager non reputi soddisfacenti i risultati della prima tabella, o che comunque, passando ad una seconda fase di analisi, più dettagliata, si giunga fino alla scelta della nazione, e di dover dunque selezionare direttamente la città verso cui dirigere il traffico in partenza e da cui attendere quello in arrivo.

Nell’esempio di fig. 5.7 la gerarchia di tipo b) sulla dimensione aeroporti è stata sostituita dalla a), dove, dopo aver effettuato uno slice sulla Spagna (si ipotizza una destinazione spagnola), vengono messi a confronto i dati di vendita relativi a clienti destinati in (o provenienti da) città spagnole già in contatto con l’aeroporto di Pisa. Se nell’analisi, i comportamenti di acquisto relativi ai passeggeri dei due aeroporti presentassero delle analogie potrebbe essere sensato pensare che anche quelli diretti ad un terzo aeroporto della regione sarebbero dotati di una tale propensione all’acquisto. In caso contrario, invece, il manager potrebbe addirittura essere portato a creare delle nuove gerarchie, in modo da raggruppare gli aeroporti secondo dei criteri completamente diversi, in grado comunque di fornire dei vantaggi al momento dell’analisi.

Fig. 5.7 tabella pivot sulla gerarchia a) della dimensione aeroporti Dimensione: Aeroporti

Continente: Europa Nazione: Spagna

Città: Barcellona Madrid

Dimensione: Negozi Importo

Vendite

A questo punto, supposto che il manager abbia optato per l’inserimento, nella road-map, di una nuova tratta prevista per una destinazione spagnola, supponiamo Valencia, potrebbe voler consultare ancora una volta la struttura

dati per studiare il rapporto tra il numero di passeggeri delle rotte più simili a quella in questione ed il numero di acquisti da essi effettuati nello stesso periodo. Supponiamo allora di prendere in considerazione la stessa gerarchia vista in precedenza e relativa a Stati della stessa Nazione. Questo tipo di analisi potrebbe trovare utilità soprattutto nello studio del numero di voli settimanali da rendere operativi, premettendo che la stima sul riempimento degli aerei arrivi dall’analisi sui dati aviation e quindi esternamente al DW. Il contenuto delle singole celle non è determinato semplicemente dall’attributo importo della tabella dei fatti, come fatto fino ad ora, bensì è calcolato contando il numero delle transazioni che rispettano i vincoli presentati, diviso per il numero totale di passeggeri che in quello stesso periodo hanno preso un certo volo, con una determinata destinazione, ottenendo in questo modo il valore relativo degli acquisti sul totale del traffico.

Fig. 5.8 gerarchia a) sulla dimensione aeroporti e b) su quella del tempo Dimensione: Aeroporti

Continente: Europa Nazione: Spagna

Città: Barcellona Madrid

Dimensione: Negozi Numero

Vendite

(ogni 100 pax)

Fashion

Gate Oca Bianca … Tot Fashion Gate Oca Bianca … Tot Gennaio 35 19 .. ₅₆ 29 18 .. ₄₉ .. .. .. .. _.. .. .. .. _.. <2001 Tot _{28 30 .. 69 26 17 .. 48} Gennaio 13 11 .. ₃₇ 23 19 .. ₃₅ .. _{.. .. .. .. .. .. .. ..} 2001 Tot _{20 28 .. 49 26 21 51} Gennaio 20 20 .. ₄₃ 22 19 .. ₃₇ .. _{.. .. .. .. .. .. .. ..} 2002 Tot _{25 35 .. 59 28 20 .. 46} Gennaio 12 16 .. ₄₃ 22 20 .. ₃₅ .. _{.. .. .. .. .. .. .. ..} 2003 Tot _{20 30 .. 53 26 20 .. 43} Gennaio 20 16 .. 45 24 19 .. 40 .. _{.. .. .. .. .. .. .. ..} Dim: Tempo Tot Tot _{24 31 58 26 19 .. 47}

Le supposizioni fatte fino ad ora, oltre a poter essere ritenute modificabili, hanno la particolarità di cercare di predire l’impatto futuro di una scelta sui ricavi commerciali. La funzione di questi strumenti è però, oltre che predittiva, anche consuntiva, in quanto è di importanza strategica, al termine di ogni periodo, analizzare gli andamenti delle vendite per poter confutare la bontà di alcune scelte e poter dunque prendere in tempo le eventuali decisioni correttive. In fig. 5.9 è riportato un esempio che mette a confronto principalmente due compagnie aeree, una low-cost ed una iata, che operano sulla stessa città, dunque con lo stesso potenziale bacino d’utenza.

Questo tipo di analisi si rende necessario nel momento in cui si vogliono studiare le differenze nella propensione d’acquisto dei passeggeri delle compagnie tradizionali rispetto a quelli delle compagnie low-cost. E’ questo un dilemma che accompagna le quotidiane attività dei manager di Sat, convinti che la caratteristica peculiare delle compagnie low-cost non influisca in alcun modo sul comportamento d’acquisto dei passeggeri, e che in questo modo potrebbero consultare un documento che rilevi effettivamente i risultati di vendita rispondendo esaurientemente alle loro domande, dimostrando la propria teoria.

Fig. 5.9 tabella pivot che mette a confronto i dati relativi ad una lcc e una iata Dimensione: Aeroporti

Città: Londra Dimensione: Voli

Compagnie: British Airways Ryanair

Dimensione: Negozi Importo

Vendite

Gli esempi presentati fino ad ora sono solo una piccola parte delle considerazioni e delle elaborazioni che possono essere svolte sui dati. Abbiamo cercato di utilizzare il maggior numero possibile di dimensioni e di gerarchie proprio per mostrare le potenzialità di questo potente strumento.

5.7 Estrazione della conoscenza

I risultati ottenuti necessitano comunque di una componente umana in grado di sfruttare al meglio le informazioni raccolte, elaborandole grazie alle capacità maturate con la propria esperienza nel settore. Sarà dunque compito del soggetto decisore capire quali siano i reali legami tra il settore aviation e quello non-aviaton, e considerare tutti questi fattori nel momento in cui viene chiamato a prendere le decisioni che caratterizzano il proprio operato. Come già accennato nel capitolo 4, il Datamining e gli altri strumenti di estrazione della conoscenza sono in grado di fornire delle ulteriori indicazioni utili al manager nello svolgere questa difficile attività.

Applicando gli algoritmi sui dati estrapolati dal Datawarehouse il sistema è in grado di trovare automaticamente alcune risposte che vanno al di là della semplice consultazione oggettiva dei dati. La conoscenza, infatti, si distingue dall’informazione perché prendendo in considerazione quest’ultima si necessita di capacità umane per adattarla alle singole esigenze e perché si possa giungere ad una decisione finale, comportando dunque l’acquisizione della conoscenza stessa. Ciò che viene fatto dagli strumenti di Datamining è proprio quello di cercare di imparare a prendere delle decisioni in modo automatico anche in virtù di quanto accaduto in passato, proprio come viene fatto quotidianamente dagli esseri umani.

Nel nostro contesto il Datamining potrebbe essere utile per capire il comportamento e le caratteristiche dei clienti dei negozi semplicemente analizzandone i comportamenti d’acquisto. Nonostante i dati personali dei clienti di cui si dispone siano ridotti al minimo, il sistema potrebbe cercare di creare da sé dei profili che identifichino un cliente, sempre restando nell’ambito delle informazioni già presenti.

Tuttavia in questa sede non è semplice fornire dati significativi riguardo i risultati concreti raggiungibili grazie all’espansione del sistema con questi mezzi informatici. Questo proprio perché trattandosi di informazioni che in realtà sono già presenti nei dati, ma che una elaborazione umana non è quasi in grado di rilevare, non abbiamo la possibilità, in questo momento, di fare degli esempi concreti o delle proiezioni future, né tanto meno di valutarne i benefici in termini pratici. Il Datamining, e gli strumenti di estrazione della conoscenza in genere, vengono menzionati nel presente paragrafo con l’unico scopo di mostrare un ulteriore sviluppo futuro del sistema, senza comunque prevederne un’implementazione nel breve periodo.