Di seguito, per chi fosse interessato, proverò a dare un'idea del funzionamento del Departure Control Sistem (sistema di accettazione) sviluppato ed utilizzato tuttora da AZ. Notare che in molti scali del territorio nazionale, questo sistema viene utilizzato in una forma più scarna e con meno "facilities" anche da compagnie terze; compagnie che ad esempio hanno pochi voli da/per lo scalo, compagnie il cui sistema non si interfaccia con il server DCS in uso nello scalo o compagnie che in sede di contrattazione con l'handler hanno ritenuto più economico/remunerativo/utile appoggiarsi a detto sistema.
Il nome del sistema è: ARCO. Romanticamente mi piace pensare che, essendo un sistema sviluppato interamente da AZ, i progettisti abbiano voluto ispirarsi alla Freccia Alata: quale miglior modo per prenotare, accettare e "lanciare" a destinazione un passeggero a bordo di un volo delle Freccie Alate Alitalia se non un ARCO?
Bando alle ciance. Chi di voi ha sbirciato il monitor di un qualsiasi banco accettazione AZ (fatto salvo Punta Raisi dove l'handler si appoggia alla vecchia piattaforma AF Gaetan) avrà notato che il sistema, per quanto concerne l'interfaccia, è altamente rudimentale. Si tratta, infatti, di una interfaccia molto simile al sistema DOS dei pc. Lo sfondo in questo caso, anzichè essere nero, è verde e/o grigio e c'è la possibilità di suddividere il monitor in due aree distinte ma collegate tra loro: potrò quindi visualizzare un'operazione nella parte alta dello schermo e visualizzarne un'altra in quella inferiore; entrambe una volta lasciate non permetteranno però di andare avanti con quell'operazione. In parole povere, posso visualizzare il nome di un passeggero in una schermata e passare a quella sotto per vedere simultaneamente le informazioni di un volo ma una volta tornato sul passeggero non potrò compiere alcuna azione su di esso e sarò costretto a richiamarlo da capo. Il sistema si basa su input alfanumerici standardizzati. La scuola di pensiero dei progettisti fino a qualche tempo fa era dell'idea che l'utilizzo della sola tastiera e la navigazione all'interno del DCS senza ausilio di mouse o con una grafica ad esempio a icone, fosse estremamente più veloce ed è in parte vero. E' altrettanto vero che dover ripetere ogni volta stringhe di input di almeno 20/25 caratteri può allungare la procedura (es. PAP: Vorrei Finestrino avanti a destra.. Una volta stampata la carta d'imbarco.. PAP: Anzi no, corridoio in fondo ma non vicino alle toilet.. -molto importante, su Arco non si vede l'ubicazione delle toilet, quindi tutto dipende dalla passione e voglia dell'agente ckin-). Gli input devono essere obbligatoriamente imparati a memoria ma al giorno d'oggi, specialmente in quegli aeroporti in cui l'handler non è direttamente AZ, un addetto ckin in media opera su almeno 3 o 4 DCS differenti (e quando dico differenti intendo totalmente diversi in tutto e per tutto). Vogliate quindi essere magnanimi se all'addetto capiterà a volte di sbirciare fra gli appunti o di chiedere al collega a fianco. Con Arco la stessa operazione, se fatta in due momenti diversi della procedura, ha un input totalmente diverso. Arco ci da quasi tutte le informazioni di cui abbiamo bisogno. Per ogni pap, ci mostra oltre a nome e cognome ed eventuali voli in coincidenza anche il numero di FF (ivi compresi eventuali status), l'eventuale gruppo di pax che viaggiano nella stessa prenotazione formato da una lettere ed un numero, il codice di prenotazione, il numero di biglietto elettronico, eventuale API (advance passenger informations, passaporto o carta d'identità, indirizzo di soggiorno, residenza, ecc.) quando richiesto dalla destinazione e tutte le richieste particolari (assistenze, armi al seguito, minore non accompagnato, strumenti musicali, attrezzature sportive, ecc). Se manca il numero di biglietto, se il pap non risulta in lista ed altri miliardi di se, la transazione si allunga ed il sistema da veloce e semplice, diventa per l'addetto, macchinoso e snervante.
Chiaramente per motivi di sicurezza non posso divulgare informazioni circa gli input che si utilizzano per accettare un passeggero. Credo che nessuno me ne voglia se però vi scrivo (per darvi modo di comprendere meglio) l'input che ci permette di vedere tutte le informazioni su un dato volo: routing, aeromobile, configurazione, numero pax prenotati, numero pax accettati, timing ecc. ecc.
ENAZ066/12MAD Questo chiaramente è uno dei più semplici: EN identifica la richiesta, nel nostro caso le informazioni su un volo (non perdete la testa a decrittare EN, gli input di Arco ahimè non sono acronimi), AZ066 la numerazione, / data del volo seguita dal codice IATA della destinazione. Chiaramente per correre in aiuto degli addetti ckin i progettisti hanno introdotto un input che permette ad inizio sessione di "dedicarsi" ad un volo in particolare, così da evitare che ogni volta si debba ripetere la stringa per intero.. datemi retta, quando c'è da richiamare un passeggero, magari per 3 o 4 volte durante una transazione può diventare un pelino fastidioso.
Chiaramente, e questo vale per tutti i DCS, tutto quello che noi inseriamo nel file di un passeggero poi viene trasmesso a tutti gli uffici interessati: centraggio, rampa, compagnia ed infine l'equipaggio. E' per questo motivo che se il vostro bagaglio pesa 28 kg, il biglietto ne prevede 23 e l'agente vi chiede di pagare l'eccedenza voi dovreste cercare di evitare il litigio. Se lui inserisce 28 ma non viene emesso il pagamento, AZ se la rifarà su di lui; se lui inserisce 23, ci saranno 5 chili in meno sul piano di carico alla voce bagagli, sommateli a tutte le eccedenze che un volo da 200 e passa pax genera ed ecco che lo sbilanciamento del carico è servito. Quando poi l'aeroplano andrà ad operare in condizioni particolari: pista corta, maltempo, ecc. il pilota maledirà gli addetti ckin. Credetemi, è capitato che dopo atterraggi o decolli stranamente turbolenti il comandante abbia richiesto la pesa dei bagagli e che questa magicamente non si avvicinasse per niente a quella riportata sul piano di carico.
Arco non è un sistema moderno, quindi capita che esso non si interfacci con i sistemi di altre compagnie (anche se queste ultime fanno magari parte della stessa alleanza). Può succedere che ad esempio si riesca ad accettare il pap sul volo di coincidenza ma non si riesca ad emettere la carta d'imbarco o che non si riesca a visualizzare la seat map del secondo volo o che addirittura proprio non si riesca ad accettare del tutto il pap nel/nei volo/i in coincidenza (nell'ultimo caso saranno i responsabili di scalo o di compagnia ad informare lo scalo di transito degli eventuali pax non in possesso di carta d'imbarco). La cosa che accade con Arco e non con gli altri sistemi di accettazione è che, qualora sia l'agente ad inserire il volo in coincidenza, il bagaglio seguirà l'indicazione dell'agente anche qualora il volo o la destinazione inseriti non siano esatti. Mi spiego meglio, se inserisco un volo sbagliato di coincidenza o il volo giusto ma la destinazione errata il sistema mi risponderà che non può effettuare il trough ckin e quindi emettere la carta d'imbarco ma il bagaglio verrà comunque inviato alla destinazione data. Rapido esempio. Passeggero da TRN a NRT via FCO/DXB. Il sistema accetterà il passeggero solo sulla prima tratta operata da AZ ma non sulle altre operate da EK. In caso di biglietto unico posso, da regola AZ, inviare il bagaglio direttamente a NRT. Inserisco quindi tutti i numeri di volo, AZ111/13FCO, EK222/13DXB, EK333/14HND.. ops il bagaglio, qualora EK vada a Tokio Haneda arriverà su questo aeroporto oppure finirà al lost & found di DXB. Quindi, ricordando che una delle affermazioni più odiate dagli addetti ckin è: "Non mi mandi il bagaglio a JFK o ATL perchè io vado a DEL", qualora il vostro itinerario inizi con AZ da uno scalo che utilizza Arco e non riceviate le carte d'imbarco per i voli in coincidenza controllate che l'etichetta bagaglio sia giusta.
Spero di non essere stato noioso, buon proseguimento.
Il nome del sistema è: ARCO. Romanticamente mi piace pensare che, essendo un sistema sviluppato interamente da AZ, i progettisti abbiano voluto ispirarsi alla Freccia Alata: quale miglior modo per prenotare, accettare e "lanciare" a destinazione un passeggero a bordo di un volo delle Freccie Alate Alitalia se non un ARCO?
Bando alle ciance. Chi di voi ha sbirciato il monitor di un qualsiasi banco accettazione AZ (fatto salvo Punta Raisi dove l'handler si appoggia alla vecchia piattaforma AF Gaetan) avrà notato che il sistema, per quanto concerne l'interfaccia, è altamente rudimentale. Si tratta, infatti, di una interfaccia molto simile al sistema DOS dei pc. Lo sfondo in questo caso, anzichè essere nero, è verde e/o grigio e c'è la possibilità di suddividere il monitor in due aree distinte ma collegate tra loro: potrò quindi visualizzare un'operazione nella parte alta dello schermo e visualizzarne un'altra in quella inferiore; entrambe una volta lasciate non permetteranno però di andare avanti con quell'operazione. In parole povere, posso visualizzare il nome di un passeggero in una schermata e passare a quella sotto per vedere simultaneamente le informazioni di un volo ma una volta tornato sul passeggero non potrò compiere alcuna azione su di esso e sarò costretto a richiamarlo da capo. Il sistema si basa su input alfanumerici standardizzati. La scuola di pensiero dei progettisti fino a qualche tempo fa era dell'idea che l'utilizzo della sola tastiera e la navigazione all'interno del DCS senza ausilio di mouse o con una grafica ad esempio a icone, fosse estremamente più veloce ed è in parte vero. E' altrettanto vero che dover ripetere ogni volta stringhe di input di almeno 20/25 caratteri può allungare la procedura (es. PAP: Vorrei Finestrino avanti a destra.. Una volta stampata la carta d'imbarco.. PAP: Anzi no, corridoio in fondo ma non vicino alle toilet.. -molto importante, su Arco non si vede l'ubicazione delle toilet, quindi tutto dipende dalla passione e voglia dell'agente ckin-). Gli input devono essere obbligatoriamente imparati a memoria ma al giorno d'oggi, specialmente in quegli aeroporti in cui l'handler non è direttamente AZ, un addetto ckin in media opera su almeno 3 o 4 DCS differenti (e quando dico differenti intendo totalmente diversi in tutto e per tutto). Vogliate quindi essere magnanimi se all'addetto capiterà a volte di sbirciare fra gli appunti o di chiedere al collega a fianco. Con Arco la stessa operazione, se fatta in due momenti diversi della procedura, ha un input totalmente diverso. Arco ci da quasi tutte le informazioni di cui abbiamo bisogno. Per ogni pap, ci mostra oltre a nome e cognome ed eventuali voli in coincidenza anche il numero di FF (ivi compresi eventuali status), l'eventuale gruppo di pax che viaggiano nella stessa prenotazione formato da una lettere ed un numero, il codice di prenotazione, il numero di biglietto elettronico, eventuale API (advance passenger informations, passaporto o carta d'identità, indirizzo di soggiorno, residenza, ecc.) quando richiesto dalla destinazione e tutte le richieste particolari (assistenze, armi al seguito, minore non accompagnato, strumenti musicali, attrezzature sportive, ecc). Se manca il numero di biglietto, se il pap non risulta in lista ed altri miliardi di se, la transazione si allunga ed il sistema da veloce e semplice, diventa per l'addetto, macchinoso e snervante.
Chiaramente per motivi di sicurezza non posso divulgare informazioni circa gli input che si utilizzano per accettare un passeggero. Credo che nessuno me ne voglia se però vi scrivo (per darvi modo di comprendere meglio) l'input che ci permette di vedere tutte le informazioni su un dato volo: routing, aeromobile, configurazione, numero pax prenotati, numero pax accettati, timing ecc. ecc.
ENAZ066/12MAD Questo chiaramente è uno dei più semplici: EN identifica la richiesta, nel nostro caso le informazioni su un volo (non perdete la testa a decrittare EN, gli input di Arco ahimè non sono acronimi), AZ066 la numerazione, / data del volo seguita dal codice IATA della destinazione. Chiaramente per correre in aiuto degli addetti ckin i progettisti hanno introdotto un input che permette ad inizio sessione di "dedicarsi" ad un volo in particolare, così da evitare che ogni volta si debba ripetere la stringa per intero.. datemi retta, quando c'è da richiamare un passeggero, magari per 3 o 4 volte durante una transazione può diventare un pelino fastidioso.
Chiaramente, e questo vale per tutti i DCS, tutto quello che noi inseriamo nel file di un passeggero poi viene trasmesso a tutti gli uffici interessati: centraggio, rampa, compagnia ed infine l'equipaggio. E' per questo motivo che se il vostro bagaglio pesa 28 kg, il biglietto ne prevede 23 e l'agente vi chiede di pagare l'eccedenza voi dovreste cercare di evitare il litigio. Se lui inserisce 28 ma non viene emesso il pagamento, AZ se la rifarà su di lui; se lui inserisce 23, ci saranno 5 chili in meno sul piano di carico alla voce bagagli, sommateli a tutte le eccedenze che un volo da 200 e passa pax genera ed ecco che lo sbilanciamento del carico è servito. Quando poi l'aeroplano andrà ad operare in condizioni particolari: pista corta, maltempo, ecc. il pilota maledirà gli addetti ckin. Credetemi, è capitato che dopo atterraggi o decolli stranamente turbolenti il comandante abbia richiesto la pesa dei bagagli e che questa magicamente non si avvicinasse per niente a quella riportata sul piano di carico.
Arco non è un sistema moderno, quindi capita che esso non si interfacci con i sistemi di altre compagnie (anche se queste ultime fanno magari parte della stessa alleanza). Può succedere che ad esempio si riesca ad accettare il pap sul volo di coincidenza ma non si riesca ad emettere la carta d'imbarco o che non si riesca a visualizzare la seat map del secondo volo o che addirittura proprio non si riesca ad accettare del tutto il pap nel/nei volo/i in coincidenza (nell'ultimo caso saranno i responsabili di scalo o di compagnia ad informare lo scalo di transito degli eventuali pax non in possesso di carta d'imbarco). La cosa che accade con Arco e non con gli altri sistemi di accettazione è che, qualora sia l'agente ad inserire il volo in coincidenza, il bagaglio seguirà l'indicazione dell'agente anche qualora il volo o la destinazione inseriti non siano esatti. Mi spiego meglio, se inserisco un volo sbagliato di coincidenza o il volo giusto ma la destinazione errata il sistema mi risponderà che non può effettuare il trough ckin e quindi emettere la carta d'imbarco ma il bagaglio verrà comunque inviato alla destinazione data. Rapido esempio. Passeggero da TRN a NRT via FCO/DXB. Il sistema accetterà il passeggero solo sulla prima tratta operata da AZ ma non sulle altre operate da EK. In caso di biglietto unico posso, da regola AZ, inviare il bagaglio direttamente a NRT. Inserisco quindi tutti i numeri di volo, AZ111/13FCO, EK222/13DXB, EK333/14HND.. ops il bagaglio, qualora EK vada a Tokio Haneda arriverà su questo aeroporto oppure finirà al lost & found di DXB. Quindi, ricordando che una delle affermazioni più odiate dagli addetti ckin è: "Non mi mandi il bagaglio a JFK o ATL perchè io vado a DEL", qualora il vostro itinerario inizi con AZ da uno scalo che utilizza Arco e non riceviate le carte d'imbarco per i voli in coincidenza controllate che l'etichetta bagaglio sia giusta.
Spero di non essere stato noioso, buon proseguimento.
Ultima modifica:
