Ottimizzazione delle decisioni

L'ottimizzazione è il processo che permette al sistema IDeaS di prendere le decisioni che massimizzano la revenue delle strutture alberghiere. In questa fase dunque il RMS decide come allocare ottimamente le camere a disposizione, cioè la risorsa, in base alle diverse classi di domanda, individuate dai MSG, senza sapere concretamente come si manifesterà la richiesta futura, ma avendo a disposizione il forecast (Talluri e Van Ryzin, 2005) e il volume e il valore della domanda che esso ha precedentemente prodotto.

Nell'ottimizzazione il sistema IDeaS non prende delle decisioni irrevocabili che l'hotel deve subire passivamente, infatti il management attraverso le proprie conoscenze può influenzare le scelte effettuate dal RMS.

Nel sistema il team di RM dell'hotel deve anzitutto inserire gli eventi speciali, che si caratterizzano per differenze nei normali modelli di comportamento relativi alla domanda di tipo transient. Gli eventi speciali differiscono dai comuni modelli comportamentali in termini

occupancy, booking pace, revenue e business mix.

Il sistema IDeaS è in grado di isolare i modelli che ha identificato come eventi speciali, poiché entra in una particolare fase di self-learning che gli permette di riconoscere con un certo anticipo queste particolarità di calendario. La cosa molto importante è che il RMS riconosce i modelli speciali sia che si tratti di eventi cosiddetti one-off, come il Carnevale, o di eventi che ricorrono sempre nello stesso periodo, come il Capodanno.

Figura 4.6: Threshold curve method con 90 giorni di anticipo rispetto alla data di arrivo (Withiam, 2001).

Per riconoscere queste particolarità di calendario, nella modalità di self-learnig, il sistema utilizza anche il threshold curve method. Con esso il sistema necessita in particolare di due valori: la media, μ, e lo scarto quadratico medio, σ, calcolati sullo storico delle prenotazioni per la data esaminata. Il RMS analizza l'andamento delle curve μ + σ, μ + 2σ, μ

- σ, μ – 2σ (figura 4.6), che definiscono dei valori soglia o di allarme, considerandone

l'andamento nei giorni precedenti alla data di arrivo (Withiam, 2001). Questo serve al RMS per capire come l'andamento delle prenotazioni si stia manifestando in relazione al passato. Se un giorno, ad esempio, arriva un numero di prenotazioni maggiore rispetto al punto della curva μ + 2σ con i corrispondenti giorni di anticipo rispetto alla data di arrivo, allora la

struttura può chiudere le classi relative a MSG caratterizzati da prezzi bassi perché le prenotazioni hanno un andamento positivo; al contrario se un giorno il numero dovesse essere minore del punto della curva μ – 2σ, allora sarebbe opportuno riaprire le classi low, cioè quelle caratterizzate da MSG con bassa disponibilità a pagare, qualora fossero state chiuse precedentemente.

Nel caso degli eventi speciali che ricorrono il RMS usa per il forecasting i modelli di comportamento degli anni precedenti.

Ai fini della corretta ottimizzazione del sistema va anche notificato allo stesso quali e quante camere sono fuori servizio e dunque non prenotabili, questo perché la capacità alberghiera ne è condizionata e elementi come il livello di overbooking e il last room value (LRV), di cui si parlerà meglio successivamente, ne risentono.

Elemento fondamentale per la riuscita dell'ottimizzazione è la corretta procedura di registrazione dei no-show. Su questo punto nel primo training il team di IDeaS si è soffermato lungamente, era emerso infatti che nella realtà alberghiera target la procedura di registrazione dei no-show non era adeguata. I dati relativi ai clienti che non si presentano sono però fondamentali al RMS, nella definizione dei livelli di overbooking infatti esso analizza le statistiche relative a cancellazioni e no-show, che vanno di conseguenza registrati correttamente e trattati come elementi distinti.

La necessità di prestare attenzione alla procedura di registrazione dei no-show, ma anche delle cancellazioni, dei walk-in, dei prolungamenti (overstay) e delle partenze anticipate, fa supporre che ai fini della definizione dei livelli ottimi di prezzo e quantità per classi tariffarie, di overbooking e di last room value il sistema utilizzi un modello simile a quello ABC. Con esso si analizza anzitutto la situazione attuale (A) e comprensiva di: camere disponibili, camere occupate, partenze previste e arrivi previsti. A seguire si analizzano i dati storici relativi alle diminuzioni di occupazione, cioè i no-show, le cancellazioni e le partenze anticipate. Poi si analizzano anche i dati storici relativi ad aumenti di occupazione e dunque

overstay e walk-in. I dati storici dipingono una probabilità e dunque una percentuale di

diminuzioni e aumenti di occupazione che si è manifestata nel passato e che viene ora applicata alla situazione attuale (Caldari, 2009).

A conferma del fatto che il sistema è in completo controllo dell'utente, per la procedura di ottimizzazione egli può utilizzare un modulo denominato System Override, nel quale l'utente può sostituirsi al sistema in alcune decisioni. La domanda inerente il perché IDeaS

permetta questa immissione nella procedura di ottimizzazione da parte del team di RM sorge spontanea, tuttavia la risposta è abbastanza semplice: vi sono cose che il sistema non conosce e che invece il management ha ben chiare.

Il management della realtà analizzata ad esempio tiene molto al rapporto con i clienti abituali, ai quali concede una scontistica particolare in ragione del rapporto che li lega alla struttura da anni. Un segmento come questo, chiamato returning guest, dal sistema è chiaramente considerato poco redditizio sia in termini di valore della domanda che in termini di volume. Poiché le valutazioni in merito a questo segmento verranno prese in considerazione proprio dal personale dell'hotel, il management ha optato per l'esclusione di esso dal meccanismo di ottimizzazione della domanda.