Yazılımın Oracle OPERA Cloud'a bağlanmasıyla ilgili konuşmaların çoğu, bağlantı kurulduğunda neyin mümkün olabileceğine odaklanır: otomatik mesajlaşma, daha akıllı üst satışlar, daha hızlı hizmet kurtarma. Bunlardan herhangi birinin gerçekten işe yarayıp yaramadığını belirleyen şeye daha az konuşma odaklanılıyor: her iki sistemin de baktığı misafir kaydının aynı kayıt olup olmadığı.
Bu küçük bir detay gibi görünüyor. Pratikte bu, akıllı görünen bir yapay zeka katmanı ile geri dönen bir konuğu yeniymiş gibi karşılayarak veya okuduğu profil üç saat eski olduğu için bir VIP'nin şikayetini yanlış departmana yönlendirerek oteli sessizce utandıran katman arasındaki farktır.
Veriler gerçekte OHIP'te nasıl taşınır?
Oracle'ın Otelcilik Entegrasyon Platformu (OHIP), OPERA Cloud'un önünde bulunan API katmanıdır. Bağlı sistemler PMS veritabanını doğrudan okumaz. Rezervasyonlar, profiller, foliolar, temizlik durumu ve ücret verileri için REST uç noktalarını çağırırlar ve bazı durumlarda PMS tarafında bir değişiklik olduğunda tetiklenen etkinlik bildirimlerine abone olurlar.
Bağlı bir sistemi güncel tutmak için iki genel model vardır:
- Oylama: bağlı sistem belirli aralıklarla (her birkaç dakikada bir veya bir personel misafir profilini açtığında talep üzerine) OHIP'i sorgular ve elde ettiği verileri kendi kayıt kopyasıyla karşılaştırır.
- Olaya dayalı senkronizasyon: OPERA Cloud, bir rezervasyon, profil veya folio değiştiğinde bir bildirim gönderir ve bağlı sistem, yerel kopyasını neredeyse gerçek zamanlı olarak günceller.
Olay odaklı senkronizasyon daha hızlıdır ve eski okumaların sayısını azaltır, ancak risksiz değildir. Bildirimler sıra dışı gelebilir, ağ kesintisi sırasında kesilebilir veya aynı değişiklik için iki kez tetiklenebilir. Her olayın tam olarak bir kez, sırayla gerçekleşeceğini varsayan herhangi bir sistem, eninde sonunda gerçeklikle eşleşmeyen bir konuk kaydı oluşturacaktır.
Konuk kayıtlarının gerçekte birbirinden ayrıldığı yer
Uygulamada uyumsuzluklar rastgele ortaya çıkmak yerine az sayıda öngörülebilir nokta etrafında kümelenme eğilimindedir.
Profil birleştirmeleri ve yinelenen işlemleri işleme
OPERA, misafir başına benzersiz bir profil kimliği tutar, ancak ön büro personeli, özellikle randevusuz gelenler için veya adın yazılışı biraz farklı olan bir kanal üzerinden rezervasyon geldiğinde sürekli olarak yinelenen profiller oluşturur. OPERA iki profili birleştirdiğinde, bağlı sistemin bu birleştirme olayını doğru bir şekilde alması ve işlemesi gerekir, aksi takdirde artık profil kimliği üzerinde çalışmaya devam edecek ve söz konusu misafirin konaklama geçmişini, tercihlerini veya sadakat katmanını sessizce kaybedecektir.
Giriş ve çıkış sırasında zamanlama boşlukları
Rezervasyon durumu değişikliği (şirket içi olarak rezerve edilmiş, şirket içinden çıkışa kadar), genellikle bağlı sistemlerin bir misafirin ne yapıp ne yapamayacağına karar vermek için kullandığı tetikleyicidir; örneğin bir mobil talebin oda temizliğine mi yoksa rezervasyonlara mı yönlendirileceği. Bağlı katman, etkinliği hemen almak yerine her on dakikada bir yoklama yaparsa, yeni giriş yapmış bir misafirin hâlâ gelecekteki bir rezervasyon olarak değerlendirildiği bir pencere bulunur.
Ücret ve folyo alanları statik olarak değerlendirilir
Bazı entegrasyonlar, profil ve rezervasyon verilerini rezervasyon sırasında bir kez alır ve hiçbir zaman yenilemez; oda türü, ücret kodu veya özel istekler gibi alanları sabit olarak değerlendirir. Bir misafir tarihleri değiştirmek veya çağrı merkezi aracılığıyla bir istek eklemek için aradığında, PMS anında güncellenir ancak bağlı sistemin kopyası bir sonraki tam senkronizasyona kadar güncellenmez.
Açıklayıcı bir örnek: OPERA ile birlikte üç bağlantılı araç kullanan bir tesis, mesajlaşma platformunun, ek satış motorunun ve değerlendirme-yanıt aracının her birinin, her biri farklı bir programa göre senkronize edildiğinden, aynı misafirin konaklama tarihlerinin biraz farklı bir versiyonunu barındırdığını buldu.
Doğru, senkronize kayıtların gerçekte kilidini açtığı şey nedir?
Bir otel bu boşlukları giderdiğinde, bağlı her sistemin aynı güncel profilden ve rezervasyon durumundan okuma yapması sağlanırsa, pratik kazanımlar gösterişli özelliklerden ziyade konukların ve personelin hissettiği sürtüşmenin ortadan kaldırılmasına yönelik olur.
- Bir sohbet widget'ı aracılığıyla kaydedilen bir misafir isteği, doğru oda numarası, sadakat kademesi ve konaklama geçmişi önceden eklenmiş olarak gelir; böylece personelin, otelin cevabını zaten bilmesi gereken soruları sorması gerekmez.
- Hizmet kurtarma, eski bir kayda uygulanan genel bir kural yerine, doğru zamanda doğru sinyalle (örneğin, bilinen bir tercihle birlikte gecikmiş bir check-in) tetiklenir.
- Departmanlar arası raporlama, kendi kendisiyle fikir ayrılığına düşmeyi bırakır. Gelir, ön büro ve misafir hizmetleri, hafta sonunda üç ihracatı uzlaştırmak yerine aynı doluluk ve profil numaralarına bakabilir.
Bu, GadgetMall'ın Hermes platformunun üzerinde çalışmak üzere oluşturulduğu katmandır: konuk verilerini ayrı bir siloda kopyalamak yerine, OHIP aracılığıyla OPERA Cloud'a bağlanır ve istek yönlendirmeyi ve konuk istihbaratını PMS'nin tuttuğu aynı canlı kayda bağlı tutar; böylece ön büro, temizlik ve hizmet kurtarma, gerçeğin üç yerine tek bir sürümüyle çalışır.
Başka bir bağlı araç eklemeden önce sorulmaya değer sorular
Bir otel, OPERA'nın üzerine yeni bir yapay zeka katmanı eklemeden önce, satıcının pazarlamasının bunu kapsadığını varsaymak yerine, kısa bir soru listesine somut yanıtlar almak faydalı olacaktır:
- Araç, olay bildirimlerini, yoklamayı veya her ikisini de kullanıyor mu ve bir PMS değişikliği ona ne kadar hızlı ulaşır?
- OPERA iki misafir profilini birleştirdiğinde ne olur?
- Bırakılan veya yinelenen bir olay bildirimini nasıl ele alır?
- Personel, aracın bir kaydının kopyasının OPERA'ya karşı en son ne zaman onaylandığını bir bakışta görebiliyor mu?
Bu soruların hiçbiri heyecan verici değil. Ayrıca, bağlantılı bir sistemin, oteli misafirlerin önünde şık mı göstereceğini yoksa sadece verilerin sessizce uyuşmadığı bir yer daha mı ekleyeceğine karar verenler de bunlardır.