Capitolo 3
Una sistema di computer per una gestione
continua ed efficace
Nel terzo capitolo della tesi ci occuperemo di preparare le basi per la risoluzione del problema, avvicinandoci il più possibile ad una vera e propria progettazione del sistema informativo di cui si necessita. La trattazione è strutturata in passi, nei quali vengono descritti uno per uno gli elementi fondamentali nella creazione di tale sistema.
3.1 Presentazione generale
Nei capitoli precedenti abbiamo affrontato un percorso che passando per la descrizione dello scenario attuale del mondo aeroportuale ci ha condotti verso quella che è la realtà dell’aeroporto di Pisa e di Sat, giungendo in modo naturale ad identificare il problema da essi manifestato nel contesto di grande espansione nel quale si trovano ad operare.
Data la consistente mole di lavoro da svolgere nell’ipotetica implementazione del progetto è bene suddividere lo stesso in passi. L’obiettivo di questo capitolo è quello di creare la base informatica per poter implementare in seguito gli strumenti di analisi dati più sofisticati.
Abbiamo detto che desiderio espresso da Sat è la possibilità di controllare le attività commerciali interne all’aeroporto, inteso sia come supervisione delle vendite che controllo di effettiva e corretta operatività. Per raggiungere tale scopo è utile predisporre una postazione (server) dalla quale il personale Sat possa concretamente prendere atto di quanto accade nell’aeroporto.
La presenza di questa postazione si renderebbe comunque vana se non ci fosse nei negozi uno strumento in grado di fornire le necessarie informazioni (clients). Infine è importante predisporre un contenitore che sia in grado di registrare il maggior numero di dati possibile, un vero e proprio archivio da cui attingere le informazioni in qualsiasi momento e relative anche a momenti precedenti (database). Quest’ultimo elemento è indispensabile soprattutto per la costruzione di uno strumento di analisi dei dati che tratteremo nel prossimo capitolo. Nei prossimi paragrafi invece andremo a studiare più nel dettaglio questi tre punti appena menzionati, cercando di adattarli nel miglior modo possibile alle nostre esigenze.
3.2 La rilevazione manuale
Prima di ricorrere all’ausilio dei sistemi informatici Sat ha volutamente testato per due anni un sistema più tradizionale, ma comunque in grado di fornire delle risposte indicative. È stata forse proprio l’importanza di queste risposte ad accrescere l’esigenza di una rilevazione più capillare e continuativa dei dati di vendita. Il metodo adottato consisteva in una serie di tagliandi
distribuiti ai commercianti da far compilare ai propri clienti al momento dell’acquisto. Per motivi di privacy, e probabilmente anche per la scarsa rilevanza per fini statistici, i dati anagrafici del cliente non sono stati registrati. Ciò che interessava erano piuttosto i dati che legavano il settore aviation a quello non-aviation, rappresentato appunto dall’atto di vendita. Il cliente doveva inserire innanzitutto la categoria di appartenenza, distinta tra passeggero in partenza o in arrivo, accompagnatore o staff aeroportuale (ivi compresi anche i dipendenti delle compagnie aeree), negli ultimi anni diventata una categoria di clienti particolare propensa all’acquisto.
Nel caso in cui si trattasse di passeggero, essendo munito di carta d’imbarco poteva inserire i dati relativi al trasporto, cioè il numero del volo, la destinazione (o partenza). Era richiesta poi l’indicazione del sesso e della fascia di età di appartenenza, mentre i dati personali terminavano con l’indicazione della propria nazionalità. Le informazioni relative all’acquisto erano invece costituite dall’ammontare di spesa effettuata nonché dall’orario e data di acquisto.
I dati venivano poi immagazzinati in un database tramite un’apposita interfaccia ed elaborati per poterne ricavare le informazioni desiderate, in quanto un dato, se non accuratamente gestito ed interpretato insieme ad altri dati non rappresenta di per sé un’informazione, ne quest’ultima fornisce conoscenza se non la si unisce ad un opportuno bagaglio culturale ed alla capacità manageriale di chi ne usufruisce.
L’utilità delle informazioni in questo modo rilevate è indubbia, in quanto consente ai responsabili marketing e commerciali di verificare il ritorno economico di alcune decisioni prese o addirittura di investimenti effettuati. Questo però pone un problema importante. Infatti questo sistema presenta degli evidenti limiti rappresentati innanzitutto dalla validità delle libere dichiarazioni effettuate da un’acquirente, senza alcun effettivo riscontro di veridicità, il che
potrebbe portare quindi una persona ad inserire dei dati inesatti o non completi. È proprio ciò che si è verificato nel momento in cui si presentavano delle forti incongruenze sugli importi degli acquisti o sugli orari e i dati dei voli. Applicando i dovuti filtri questi limiti verrebbero comunque superati con relativa facilità. Il secondo problema è rappresentato dalla consistenza dei dati rilevati, il che può far perdere o acquistare valore all’operazione. Basta dire che nell’ultima rilevazione effettuata, durata un mese circa, sono state compilate soltanto 1000 schede, che rappresentano comunque un dato significativo rispetto a quella precedente, quando poco più di 200 persone avevano registrato il proprio acquisto. È da tener presente anche il fatto che i tagliandi erano stati distribuiti in soli sei negozi, mentre attualmente le attività effettivamente operative hanno superato le quindici unità.
L’ultimo passo consisteva nell’inserire manualmente tutti i dati relativi ai tagliandi compilati, comportando per l’azienda un costo aggiuntivo e per il dipendente una perdita di tempo rispetto al lavoro da esso/a svolto quotidianamente.
Dato il carattere statistico di questa operazione è possibile generalizzare per riportare i risultati agli effettivi dati di traffico dell’aeroporto, ma non è sempre facile e soprattutto non lo è il capire quanto questa stima così limitativa possa essere rapportata ai due milioni di passeggeri che attualmente passano in un anno attraverso l’aeroporto, senza contare ovviamente tutti gli accompagnatori ed il personale di staff, raggiungendo un bacino d’utenza che si aggira intorno ai 4-5 milioni di potenziali acquirenti.
3. 3 La rete fisica
Abbiamo volutamente premesso la trattazione del sistema di cui si è avvalsa Sat in questi ultimi due anni sia per capire quali informazioni potessero rivelarsi effettivamente utili per il nostro scopo, sia per mostrare quali limiti noi fossimo chiamati a superare creando un nuovo sistema di rilevazione.
Alla luce di tutto questo possiamo dire che l’idea di fondo da cui possiamo partire è quella di cercare di automatizzare il processo già precedentemente testato da Sat, fornendogli continuità, attendibilità ed immediatezza, nonché la possibilità di andare ben oltre la mera rilevazione dei dati di acquisto, passando attraverso un controllo in tempo reale delle attività e giungendo alla possibilità di sfociare direttamente in nuove strategie di marketing.
Se realmente si vogliono gestire i dati inerenti il regolare svolgersi dell’attività dei commercianti dobbiamo innanzitutto fare in modo che le informazioni possano giungere a noi. Chiaramente non possiamo pensare che questo compito possa essere svolto manualmente dal personale Sat, in quanto ciò sarebbe, oltre che impensabile sotto il profilo organizzativo e umano, impossibile in termini di tempo e numero di persone da impiegare.
La soluzione in questo caso è del tutto fattibile ed è costituita da un normale computer che, collegato con il registratore di cassa, sia in grado in un solo passo di emettere lo scontrino da consegnare al cliente e di tenere traccia di quanto accaduto. Possiamo cioè registrare nella memoria del computer i dati della transazione effettuata. In questo modo, per tornare a quanto precedentemente affermato, possiamo innanzitutto automatizzare la metodologia di rilevazione sperimentata da Sat, il che rappresenterebbe un buon passo in avanti dato che il contenuto delle informazioni che i tagliandi fornivano presentava un buon valore analitico.
Ma se per alcuni dati è immediato comprendere la possibilità di registrazione, come per esempio per quelli inerenti la transazione monetaria, non lo è certo per altri, tra i quali per esempio quelli relativi alla persona, al cliente del negozio. A tal proposito ci vengono incontro alcuni strumenti di nuova generazione quale per esempio il lettore ottico di carte d’imbarco, che consente tramite la semplice lettura della carta appunto la trasmissione dei dati al computer, senza alcun altro inserimento manuale da parte dell’operatore. Da tale documento possono essere estratti il sesso del passeggero, il numero e la destinazione/provenienza del volo, tutti dati che in precedenza dovevano essere inseriti dal passeggero stesso, affidandosi quindi alla sua lealtà e correttezza per quanto riguarda la veridicità di quanto dichiarato. Se non si trattasse di un passeggero, in partenza o arrivo che sia, l’operatore avrà a disposizione la possibilità di selezionare un’opzione che identificherà il cliente nelle categorie di staff aeroportuale o accompagnatore. Naturalmente è bene prevedere sempre la possibilità di un inserimento completamente manuale delle informazioni in quanto potrebbero verificarsi dei casi anomali, quali per esempio il mancato riconoscimento della carta da parte del sistema o il semplice smarrimento della stessa da parte del passeggero (nel qual caso si tratterà verosimilmente di un passeggero in arrivo).
3.4 Un unico server
Immaginando un possibile scenario, giunti a questo punto, vedremmo una serie di negozi, ognuno con il relativo computer e il lettore ottico per le carte di imbarco entrambi collegati al registratore di cassa. Ma tutto ciò non ha motivo di esistere se non come componente di un sistema decisamente più complesso. Infatti non avrebbe senso tenere tutte le informazioni staticamente su ogni
singolo computer, oltre al fatto che verrebbe meno la componente del controllo in tempo reale, dovendo delegare una persona per il rilevamento periodico di quanto registrato nelle singole memorie e che comporterebbe quindi un notevole sfalsamento temporale.
Si avverte quindi a questo punto l’esigenza di mettere in contatto tutti i singoli pc con un nodo centrale, dal quale sia possibile effettuare quanto desiderato. Si profila quindi la presenza di un server, quasi certamente situato negli uffici Sat, il che comporta evidentemente alcuni, seppur piccoli adattamenti. Occorre quindi la creazione di una vera e propria rete che confluisca verso il server, configurandosi in questo modo come una rete a stella, dato che non si ritiene necessario, almeno per il momento, che i singoli negozi possano comunicare tra loro. Nel caso in cui si volessero invece mettere in comunicazione anche i singoli terminali la configurazione della rete prenderebbe il nome di anello o di bus.
Dal server, come detto in precedenza, sarà possibile disporre del flusso di dati provenienti dalle singole postazioni, ovviamente tramite una trasmissione completamente automatica da parte del sistema stesso. A questo punto sarà possibile venire incontro anche alla necessità di supervisionare in ogni momento l’andamento delle vendite, nonché il corretto svolgimento dell’operato dei singoli commercianti. Potrebbe rilevarsi utile allora la creazione di un vero e proprio pannello di controllo, in grado di evidenziare eventuali anomalie. Se per esempio nel negozio del sign. Rossi vengono emessi in media 20 scontrini ogni ora e viene rilevato che da più di due ore non si registrano transazioni, nonostante il notevole flusso di persone all’interno dell’aerostazione, il sistema avviserà l’amministratore del server di tale anomalia invitando quest’ultimo a verificare, a questo punto personalmente, il regolare svolgimento delle attività da parte del sign Rossi o dei suoi collaboratori. Ancora sarà possibile controllare il rispetto, da parte dei
commercianti, degli orari di apertura e chiusura dei negozi. Funzione anche questa semplice da implementare in quanto basterà prevedere un meccanismo di accesso al sistema ogni qualvolta il computer verrà acceso, quindi ogni mattina, e verrà segnalato il momento in cui l’utente si disconnetterà dalla rete, corrispondente al momento della chiusura giornaliera. Quanto descritto, principalmente in merito alle anomalie sul numero degli acquisti, vedono il sistema imparare regolarmente dalle sue stesse rilevazioni. Grazie alla Business Intelligence, che tratteremo in maniera approfondita nel prossimo capitolo, ogni volta che il sistema verifica un’anomalia lancia una sorta di segnale. Se il segnale dovesse poi rivelarsi errato, e ciò può avvenire su inserimento manuale di informazioni o tramite rilevazione automatica, il sistema sarà in grado di aggiornare automaticamente la propria conoscenza, e probabilmente nel caso in cui in futuro si verificasse una circostanza analoga non verrebbe rilevata come anomala.
Nell’ambito di trattazione dei ricavi non-aviation per le società di gestione aeroportuale, in particolare per Sat, è da notare il fatto che una motivazione fondamentale della progettazione (e in futuro possibile implementazione) di questo sistema informativo è quella di poter ottenere in automatico, tra le altre cose, i dati riguardanti i volumi di fatturato dei negozi. Questo ha l’evidente scopo di ricavare l’ammontare della royalty spettante a Sat, determinata appunto in percentuale rispetto ai ricavi dei singoli sub-concessionari. Quanto finora previsto per il nostro sistema consentirebbe agevolmente tale rilevazione, permettendo tra l’altro, e senza alcuna forzatura, di consultarli in qualsiasi momento, anche senza aspettare la fine del mese. È questa una evidente conquista, che dà la possibilità di fare dei confronti più approfonditi, segmentando per settimane, giorni della settimana, giorni del mese, o addirittura per orario. Anche questo è un campo in cui la Business Intelligence è in grado di fornire degli strumenti di conoscenza molto avanzati, che
permettano al sistema di andare oltre la mera rilevazione dei dati di fatturato, estrapolando ulteriore conoscenza insita nei dati stessi.
3.5 Contenere i dati: il database
Tutto ciò che i computer registreranno quotidianamente dovrà essere archiviato nel modo più opportuno affinché la mole di dati non possa influenzarne l’organizzazione e la reperibilità. A tal proposito ci viene incontro ancora la tecnologia, in questo caso con i database, dei veri e propri raccoglitori, dai quali sarà possibile in qualsiasi momento, e con ordinarie operazioni estrarre i dati o comunque interrogare in merito alle informazioni in essi contenuti.
Considerando l’elevato numero di transazioni registrate nonché la quotidianità delle operazioni, nel nostro caso si rende fondamentale l’utilizzo di una base di dati, anche per non correre il rischio di perdere delle informazioni molto importanti soprattutto per il futuro.
In realtà, come il lettore dovrebbe già sapere, il database più che un contenitore è un insieme di contenitori, legati tra loro da vere e proprie relazioni. Cercheremo quantomeno di identificare tali contenitori, nonché di osservare le relazioni che verosimilmente li legano. Nella tabella riportata in seguito possiamo delineare, almeno nei suoi tratti fondamentali, lo scenario generale.
Abbiamo innanzitutto la tabella vendite, nella quale vengono registrati appunto i dati prettamente inerenti la transazione, ovvero la data, comprendente l’orario, il giorno, il mese e l’anno dell’acquisto e l’importo speso. Questa collezione di dati è, come si può semplicemente notare, il centro di tutto il sistema e dal quale partono dei collegamenti con altri insiemi di
elementi. Possiamo osservare infatti che dalle vendite parte un collegamento verso i Clienti. Il verso della freccia mostra il fatto che un acquisto potendo essere effettuato da una sola persona è associato ad un'unica vendita. Allo stesso modo una transazione è relativa ad un solo Negozio. L’ultima tabella è relativa ai Voli, caratterizzati da un codice univoco e i dati relativi a orario e data della partenza, rilevabili dalla carta di imbarco.
Nelle tabelle della figura 3.1 vengono riportati anche i singoli attributi, anche se a titolo puramente esemplificativo. In neretto sottolineato vengono riportati, per ogni tabella, gli attributi chiave mentre in corsivo sono identificate le chiavi esterne.
SessoCliente CodVolo DataOraPartenza NazionalitàCliente CodTransaz CodNegozio SessoCliente CodNegozio CodVolo
NomeNegozio Importo NazionalitàCliente
Vendite Clienti Negozi Voli effettuate a passeggero di rilevate in effettuate a DataOraVendita
I dati rappresentati nella tabella di fig. 3.1 possono essere interamente ricavati dalla registrazione della transazione tramite la rete descritta nei paragrafi precedenti, senza l’ausilio di fonti esterne e sono interamente inerenti al settore non-aviation. In realtà ci sono però alcuni dati riguardanti il settore aviation che possono rivelarsi di strategica importanza, soprattutto in seguito, quando tratteremo le analisi da svolgere sulle informazioni registrate. A tal proposito, non disponendo della struttura dati concretamente operativa nell’aeroporto per la gestione e la registrazione dei voli, abbiamo riportato in fig. 3.2 una possibile organizzazione dei dati inerenti i voli ed i collegamenti con le compagnie aeree e gli aeroporti di partenza/destinazione, nonché le singole partenze relative ad ogni volo. La distinzione tra volo e partenza in questo caso è dettata dalla netta separazione che in questo caso viene effettuata tra la descrizione di un volo (e quindi del codice univoco), ed i singoli viaggi che vengono effettuati quotidianamente da o per quell’aeroporto, e caratterizzati, oltre che dalla compagnia e dall’aeroporto, anche dalla data, dal numero di passeggeri effettivamente presenti nell’aereo, nonché dal numero di posti disponibili per quello stesso viaggio. Per rendere meglio il significato della distinzione è come se considerassimo la differenza tra un libro, identificato da titolo, autore ed editore, ed il volume di quel libro di cui io sono in possesso.
È importante ricordare che la rappresentazione di fig 3.2 non è ricavata dalla realtà, ma che comunque rispecchia senz’altro una buona visione di quanto effettivamente disponibile nelle strutture dati utilizzata da Sat
CodCompagnia CodCompagnia CodAeroporto effettuati da partiti/destinati Relativa a CodVolo DataOra Npasseggeri Nposti CodVolo CodAeroporto
NomeCompagnia NomeAeroporto Nazione
Città
Voli Aeroporti
Compagnie aeree
Partenze
Fig.3.2 struttura database settore aviation
Come preannunciato la struttura presentata non ha assolutamente la pretesa di essere totalmente esaustiva, ma al contrario rappresenta una linea guida nella trattazione dell’argomento e come vedremo nel prossimo capitolo si rivelerà molto utile per la progettazione di un sistema ancora più complesso.
Abbiamo parlato di database, di contenitori, ma quel che è importante in questo caso non è tanto la possibilità di registrare le informazioni, quanto quella di poterle richiamare ed interrogare in seguito, il che è senz’ombra di dubbio l’obiettivo ultimo dell’archiviazione.
A questo punto sarebbe il momento di andare un po’ più a fondo nell’analizzare quelli che sono i risultati ottenibili attraverso l’implementazione del sistema, nonché di valutarne i benefici, confrontandoli con il volume di costi da sostenere. In realtà, però, abbiamo preferito spostare la trattazione di questi argomenti agli ultimi capitoli, in quanto nel prossimo presenteremo un possibile sviluppo del sistema in questione, che prevede l’adozione di nuove tecnologie e nuovi strumenti, con un conseguente elevato volume di investimenti. Alla luce di questo è preferibile confrontare costi e benefici dei due sistemi solo dopo averne affrontato completamente la trattazione, in modo da avere a disposizione tutti gli elementi di valutazione.
