Rezervasyon profilleri ve talep tahmini

Spill bölümleri talebin kapasiteye çarptığı anı modelliyordu: uçak dolunca kaç yolcunun dışarıda kaldığını. Bu bölüm bir adım geri çekilip o talebin zaman içinde nasıl geldiğine bakıyor. Kaynak metin tanımı tek cümleyle koyuyor: bir uçuşun kalkıştan önceki rezervasyon hızı bir rezervasyon profilinde yakalanır ve bu profiller talep tahmininin önemli bir bileşenidir. Rezervasyon profili, sistemin kaydettiği satışların eğrisi değil, satışa açık olduğu anlarda gördüğü talebin eğrisidir. Aradaki fark küçük görünüyor ama tahmin motorunun doğru ya da sistematik olarak eksik çalışması tam bu farka bağlı.

Profil, geleceğin zamanlamasını geçmişten okuyor

Rezervasyon profili, bir uçuşun kalkışından önceki zaman diliminde rezervasyonların hızını ve dağılımını haritalandırıyor. Yatay eksende kalkışa kalan gün, dikey eksende birikmiş rezervasyon var. Geçmiş uçuşların eğrileri, gelecekteki bir uçuşun talebinin ne zaman geleceğini öngörmek için kullanılıyor. Yani profil yalnızca “kaç yolcu” sorusuna değil, “ne zaman” sorusuna da cevap veriyor; envanter kontrolünün asıl ihtiyacı da bu ikincisi.

Slaytın alt bandı profilin operasyondaki yerini gösteriyor. Analistler profilleri günlük izliyor; gelecekteki bir uçuşun rezervasyonları tarihsel profilden belirgin biçimde hızlı ya da yavaş gidiyorsa sistem, rezervasyon sınıfı tahsisini ayarlamak için uyarı üretiyor. Yazılım tarafında bunun karşılığı bir sapma alarmı: bugünkü noktayı aynı okuma günündeki tarihsel banda karşı test eden bir kural. O kuralın anlamlı olması için de iki uçuşun aynı eksende karşılaştırılabilmesi gerekiyor.

Havayolu zamanı takvimle değil, kalkışa kalan günle sayıyor

Rezervasyon hızı “okuma günleri” (reading days, RD) ya da “veri toplama noktaları” (data collection points, DCP) denen, kalkış tarihine kadar uzanan belirli anlarda takip ediliyor. Kaynak metin profili, kalkış tarihine kadar olan farklı zaman noktalarındaki rezervasyon hızını gösteren şey olarak tanımlıyor. Sistem her okuma gününde rezervasyon durumunun anlık görüntüsünü alıyor ve bunu tarihsel veriyle karşılaştırarak talep eğrisini kuruyor.

Bu endeksin mühendislik anlamı şu: ilkbaharda kalkan bir uçuşla sonbaharda kalkan bir uçuş takvimde hiçbir noktada çakışmıyor, ama ikisinin de bir “kalkışa 30 gün” anı var. Profil bu anları hizalıyor. Slayttaki not, eski PSS’lerin bu anlık görüntüleri kesin DCP’lerde gün sonu toplu işleriyle topladığını, modern sürekli RM sistemlerinin bunu gerçek zamanlı yapmaya çalıştığını ama RD endekslemesinin farklı kalkış tarihlerini karşılaştırmanın standart çerçevesi olarak kaldığını söylüyor. Yani veri akışı olay tabanlı olsa bile, tahmin katmanının beklediği şekil hâlâ “uçuş, sınıf, okuma günü” anahtarlı bir tablo. Akışı ne kadar sık tutarsanız tutun, sonunda bu ızgaraya indirgemek zorundasınız.

Tam ücretli ve indirimli sınıflar birbirinin ayna görüntüsü

Profilin tek bir eğri olmamasının sebebi yolcunun tek tip olmaması. İş kuralı, tam ücretli (unrestricted) sınıfların kalkışa çok yakın zirve yapacağını, indirimli sınıfların ise erken satın alma kısıtları yüzünden kalkıştan çok önce rezervasyon alacağını öngörüyor.

Esnek, kısıtsız tam ücretli bilet alan yolcu biletlemeyi genellikle uçuşa çok kısa süre kala yapıyor; talep kalkışa yakın zirve yapıyor. Havayolunun kârlılığı büyük ölçüde bu geç gelen, yüksek ödeyen yolcuya dayanıyor ve envanter bu yüzden erken alıcılardan korunuyor.

İndirimli sınıf tam tersini yapıyor. Derin indirimli, katı kurallı tatil ve eğlence biletleri kalkıştan çok önce satılıyor, kalkışa yakın dönemde ise hiç aktivite görmüyor. Kaynak metin bunun sebebini açıkça söylüyor: bu ücret sınıfı kalkışa yakın dönemde hiçbir rezervasyon aktivitesi görmez, çünkü erken satın alma kuralları kalkışa yakın rezervasyonları yasaklar.

Düz çizgi iki farklı şey söyleyebilir

Erken satın alma kısıtı, belirli bir tarihten sonra o sınıfta rezervasyon yapılmasını teknik olarak engelliyor. Profilde bu, o noktadan sonra yatay bir seyir olarak görünüyor. Brifingin buradaki iş kuralı net: tahmin algoritması bu durulmayı talep azlığı olarak değil, sistemsel bir kısıt olarak okumalı. Slayttaki örnekte ATPCO ücret kuralı kalkıştan 14 gün önce satın almayı şart koşuyorsa, RM sistemi T-14’ten sonra o sınıf için talep öngörmemesi gerektiğini biliyor.

Yazılım tarafında bunun karşılığı, ücret kuralının tahmin katmanına veri olarak girmesi. Eğer tahmin motoru yalnızca rezervasyon sayılarını görüp ücret kuralını görmüyorsa, T-14 sonrasındaki sıfırları “bu sınıfa son iki haftada talep gelmiyor” diye öğreniyor. Bu tesadüfen doğru bir sonuç, ama yanlış bir sebepten. Kural değiştiğinde, diyelim ki AP süresi kısaldığında, model eski sıfırları taşımaya devam ediyor. Aynı ilişki fiyatlandırma tarafına da uzanıyor: brifing, kısıtlı ücretlerin rezervasyon eğrisinin promosyonların ne zaman bitmesi gerektiğini belirleyen erken satın alma kurallarıyla doğrudan uyumlu olması gerektiğini söylüyor.

İki eğrinin yan yana konması envanter kontrolünün mantığını açıklıyor. Ucuz talep önce geliyor, pahalı talep sonra. Her koltuğu ilk gelene satarsanız pahalı yolcu geldiğinde yer kalmıyor; koltuğu gereğinden fazla korursanız uçak boş kalkıyor. Kapaktaki spoilage ve spill ikilemi bu iki eğrinin çakışmasından doğuyor. Slayttaki not bunu iç içe envanterin varoluş sebebi olarak koyuyor: RM motoru bu eğrileri karşılaştırarak bir koltuk için kabul edilebilir minimum geliri, teklif fiyatını hesaplıyor. Profil yanlışsa, o eşik de yanlış.

Tahmin bir boru hattı, profil onun ortasında duruyor

Rezervasyon profili tek başına bir çıktı değil; talep tahmininin ardışık adımlarından biri. Sunum bu akışı dokuz adımlı bir döngü olarak çiziyor: tarihsel veri toplama, aykırı değer tespiti, veri temizleme, tarafsız profil çıkarma, talep bütünleme (untruncation), tahmin modelleri, parametre tahmini, talep tahmini üretimi ve doğruluk ölçümü. Son adım sürekli geri bildirimle ilk adıma dönüyor.

Slayttaki notun verdiği örnek akılda kalıcı: tek bir futbol takımının grup rezervasyonu, normal yolcular için temel talep tahminini zehirleyebilir. Aykırı değer tespiti bu yüzden profilden önce geliyor. Yazılım tarafında her adım ayrı bir sorumluluk; sunum bunu bir RM tahmin motorunun mikro hizmet mimarisi olarak adlandırıyor. Hizmetlere bölmeseniz bile, adımların arasındaki veri sözleşmesini ayrı tutmak işe yarıyor: temizlenmiş veriyle ham veriyi aynı tabloda tutan bir sistemde, doğruluk ölçümü hangi versiyonun ölçüldüğünü bilemiyor.

Profil segment sınıfında kuruluyor, çünkü açık/kapalı bilgisi orada

Profilin hangi ayrıntı düzeyinde kurulacağı ikinci tasarım kararı. Tahmin ve envanter kontrolü için profiller genellikle segment rezervasyon sınıfı (segment booking class) düzeyinde oluşturuluyor. Alternatifi bacak sınıfı (leg class). Brifingin gerekçesi pratik: çoğu rezervasyon sistemi açık ve kapalı bilgisini segment düzeyinde sunuyor, dolayısıyla bu seviye daha ayrıntılı analiz imkânı veriyor.

Brifingin stratejik çıkarımı da aynı yönde: segment bazlı kontrol, bacak bazlı kontrole göre daha hassas veri sunduğu için gelir yönetimi sistemlerinde öncelikli olmalı. Buradaki mühendislik dersi, profil düzeyinin bir modelleme tercihi olmaktan önce bir veri mevcudiyeti sorusu olması. Aşağıda görüleceği gibi, tarafsız profil her okuma günü için “bu sınıf açık mıydı” sorusunun cevabına ihtiyaç duyuyor. O cevabı hangi düzeyde saklıyorsanız, profili de o düzeyde kurabiliyorsunuz.

Kapalı dönemdeki sıfır, talebin sıfır olduğu anlamına gelmiyor

Profilin tarafsız olması için yalnızca satışa açık dönemlerin verisi baz alınmalı. İki okuma günü arasında sınıf kapalıysa, o aralıktaki veri kısıtlanmış (truncated) sayılıyor. Kaynak metin bunun için açık bir gereklilik koyuyor: tarafsız segment sınıfı ya da bacak sınıfı rezervasyon profillerinin oluşturulması, okuma günü bazında açık ve kapalı göstergelerini gerektiriyor; 0 açık, 1 kapalı demek. Sistem bu göstergeyle yalnızca açık dönemlerdeki akışı kısıtlanmamış talep olarak tanımlıyor.

Bu slaytta küçük ama pahalı bir tuzak var. Göstergede 0 açık demek; ama notun anlattığı GDS uygunluk yanıtında sınıf kapalıyken dönen değerlerden biri de 0. İlki bir durum bayrağı, ikincisi kapalı sınıfın yanıtı. İki sistem arasında veri taşıyan bir entegrasyonda bu iki sıfırın aynı sütuna düşmesi, açık ile kapalıyı ters çevirmenin en kısa yolu. Göstergeyi bir tamsayı olarak değil, adı konmuş bir durum olarak saklamak bu riski ortadan kaldırıyor.

Eğer veri günlük anlık görüntüler olarak toplanıyorsa, iki okuma günü arasındaki kapanma oranları da hesaplanabiliyor. Brifing buna parçalı kapanma (fractional closure) diyor ve hesabın envanter detay kayıtlarındaki tarihsel koltuk uygunluğunu gözlemleyerek yapılması gerektiğini söylüyor. Okuma günleri seyrekleştikçe, örneğin -90 ile -60 arasında, bir sınıfın o aralığın bir kısmında açık bir kısmında kapalı olması olasılığı artıyor. Aralığı tek bir 0 ya da 1 ile etiketlemek o durumda bilgi kaybı. Brifingin veri yönetimi çıkarımı bu yüzden günlük snapshot’ı kritik sayıyor: okuma günleri arasındaki boşluklarda olan doluluk değişimlerini görmenin ve parçalı kapanma analizi yapmanın yolu o.

Bütünleme, kapalı musluğun arkasındaki talebi geri koyuyor

Kapalı dönemleri ayıklamak işin yarısı. Diğer yarısı, o dönemde kaybedilen potansiyel talebi matematiksel olarak geri koymak: bütünleme (untruncation, unconstraining). Sunumdaki not bunu gelir yönetimindeki muhtemelen en zor matematiksel problem olarak niteliyor ve bir örnek veriyor: uçak kalkıştan 30 gün önce dolarsa, son 30 günde tam olarak sıfır tarihsel rezervasyon olur. Bütünleme algoritmaları, EM gibi yöntemler, kaç kişinin rezervasyon yapmaya çalıştığını tahmin ediyor ve havayolunun gelecek yıl için eksik tahmin yapmasını önlüyor.

Yanılgının döngüsel olduğunu görmek önemli. Bu yıl erken kapanan bir sınıfın son haftalarındaki sıfırlar bütünlenmeden tahmine girerse, model gelecek yıl o haftalara daha az talep bekliyor. Daha az talep bekleyen sistem koltuğu daha erken ucuz sınıflara açıyor, sınıf yine erken doluyor, yine sıfır kaydediliyor. Her tur bir öncekinin hatasını pekiştiriyor. Brifingin tahmin modeli çıkarımı bu döngüyü kıracak kuralı koyuyor: talep tahmin modelleri yalnızca tarihsel rezervasyonları değil, bu rezervasyonların yapıldığı dönemdeki satışa açıklık durumunu da işlemek zorunda.

Slaytın ortasındaki formül profilin standart hale getirilmesini anlatıyor. Belirli bir aralıktaki ortalama rezervasyon, o sınıfta (segment ya da bacak düzeyinde) gerçekleşen toplam rezervasyona bölünüyor ve her okuma günü aralığı için ortalama bir yüzde çıkıyor. Bu yüzde, gelecekteki uçuşların doluluk hızını kıyaslamak için bir kıyas noktası oluyor. Mutlak sayı yerine yüzde kullanmak, farklı büyüklükteki uçuşların profillerini karşılaştırılabilir kılıyor. Bu yüzdenin anlamlı olması için payın da paydanın da bütünlenmiş veriden gelmesi gerekiyor; aksi halde kapalı dönemin sıfırları oranın içine sızıyor.

Tek bir rezervasyonun yolculuğu

Sunumun sentez slaytı bütün bu parçaları tek bir veri noktasının hikâyesine bağlıyor. Bir yolcu kalkışa 45 gün kala bilet alıyor. Sistem o anda ilgili segment sınıfının açık olup olmadığına bakıyor. Kapalı günlere ait veriler algoritmalarla bütünleniyor. Veri, ilgili bilet türünün tarihsel profiline ekleniyor. Sonunda gelecek uçuşlar için talep tahmini güncelleniyor ve yeni fiyatlamalar optimize ediliyor.

Alt banttaki uçtan uca akış, bu bölümü dağıtım bölümlerine bağlıyor: alışveriş, sipariş yönetimi, envanter kaydı, RM bütünlemesi, tahmin, gelecek optimizasyonu. Satış tarafında yazılan her sistem, envanter kaydına düşen olayın içeriğini belirliyor. O olay “bir rezervasyon oldu” bilgisinin yanında “o anda bu sınıf açıktı” bilgisini de taşımıyorsa, bütünleme adımı elindeki en önemli girdiyi başka bir yerden, genellikle daha kaba bir snapshot’tan yeniden kurmak zorunda kalıyor.

Yarın işe yarayacak dört çıkarım

1. Rezervasyonla birlikte satışa açıklık durumunu da sakla. Talep tahmin modeli yalnızca tarihsel rezervasyon sayılarını değil, her okuma günü için sınıfın açık mı kapalı mı olduğunu da işlemeli. Açık/kapalı göstergesi olmayan bir geçmiş, tarafsız profil üretemez; kapalı dönemin sıfırları talep yokluğu olarak öğrenilir ve bir sonraki yılın tahminini aşağı çeker.
2. Günlük snapshot al. Okuma günleri seyrek olsa bile envanter durumunu günlük topla. İki okuma günü arasındaki parçalı kapanmaları ancak böyle hesaplayabilirsin; aralığı tek bir 0 ya da 1 ile etiketlemek, aralığın içinde açılıp kapanan sınıfların bilgisini siler.
3. Profili segment sınıfı düzeyinde kur. Segment bazlı veri, bacak bazlı veriye göre daha hassas ve rezervasyon sistemleri açık/kapalı bilgisini çoğunlukla bu düzeyde sunuyor. Gelir yönetimi sisteminde önceliği segment bazlı kontrole ver.
4. Erken satın alma kuralını tahmine ve promosyona aynı kaynaktan besle. Kısıtlı ücretin AP kuralı, tahmin motoruna “bu tarihten sonra talep bekleme” bilgisini, fiyatlandırmaya da “promosyon burada biter” bilgisini veriyor. İkisi ayrı yerlerden okunursa kural değiştiğinde biri eski eğriyle çalışmaya devam eder.

Bu bölümde ne yok: bütünleme algoritmalarının kendisi ve kapasiteye çarpan talebin nasıl modellendiği (spill bölümleri, özellikle “Beklenen kapasite aşımı (expected spill) ve Boeing modeli analizi”), iptallerin profile etkisi ve tahmin modellerinin nasıl seçildiği. Bu bölüm yalnızca tahmin motoruna giren eğrinin nasıl kurulduğunu ve o eğrinin hangi veri olmadan yanlış kurulacağını anlatmak için var.