Tüm Sistemlerinizi Birbiriyle Uyumlu Hale Getirin

PMS bir otelin muhasebe defteri değil, ticari omurgasıdır. Fiyat oradan çıkar, rezervasyon oraya düşer, doluluk oradan okunur, rapor oradan üretilir. Bu yüzden entegrasyon meselesi bir bilgi işlem konusu gibi görünse de sonuçları doğrudan ticaridir: kopuk bir bağlantı yanlış fiyata satış, fazla satış ya da güvenilmez rapor olarak geri döner.

Otellerde bu sorun genellikle tek bir arıza olarak değil, sürekli bir düzeltme emeği olarak görünür. Her sabah birinin bir tabloyu elle düzelttiği, her ay birinin iki raporu uzlaştırdığı bir düzen kurulmuştur. Bu emek görünmezdir ve tam olarak entegrasyon eksikliğinin maliyetidir.

Veri akışı sağlıklı olmayan oteli şu belirtilerden tanırsınız:

• Aynı gün için PMS ile channel manager farklı doluluk gösteriyor.
• Kanaldan gelen rezervasyonların bir kısmı elle giriliyor ya da elle düzeltiliyor.
• İptal kanalda işleniyor ama PMS'te oda hâlâ satılmış görünüyor.
• Fiyat güncellemesinin kanala ulaşması dakikalar değil saatler alıyor.
• Ay sonunda muhasebe ile oda geliri tutmuyor; fark her ay aynı kalemden çıkıyor.
• Rapor üretmek için birden çok sistemden dışa aktarım alınıp birleştiriliyor.
• Aynı misafir sistemde birden çok kayıtla duruyor.

Entegrasyonun amacı sistem sayısını azaltmak değil, aynı sayının her yerde aynı olmasını sağlamaktır. İki sistem farklı sayı gösteriyorsa sorun hangisinin doğru olduğu değil, hangisinin kaynak kabul edildiğinin tanımlanmamış olmasıdır.

Entegrasyon planı, hangi verinin hangi yönde aktığının yazılmasıyla başlar. Yön belirsizse iki sistem birbirinin üzerine yazar ve kimse hangisinin kazandığını bilmez.

Bu tablo doldurulduğunda genellikle iki şey görünür: bazı bağlantılar hiç kurulmamıştır ve bazı veriler iki farklı yerden besleniyordur. İkincisi daha tehlikelidir, çünkü hata vermez — yalnızca sessizce farklı sonuç üretir.

Oda tipi ve fiyat kodu eşlemesi

PMS'teki oda tipi ile kanaldaki ürünün, PMS'teki fiyat kodu ile kanaldaki fiyat planının birebir eşleşmesi gerekir. Eşleme yanlışsa hata bir kez değil, her rezervasyonda tekrarlanır ve genellikle aylar sonra fark edilir.

Gecikme

Fiyat ve stop-sale güncellemesinin kanala ulaşma süresi kurulumda ölçülür. Yüksek talepli bir tarihte birkaç saatlik gecikme, kapatılamayan envanter demektir.

İptal ve değişiklik senkronu

Yeni rezervasyonun aktarılması genellikle çalışır; asıl kırılma iptal ve tarih değişikliğinde olur. Test yalnızca rezervasyon oluşturmayla yapılırsa bu senaryo hiç denenmemiş olur.

Mükerrer misafir kaydı

Aynı misafirin birden çok kayıtla durması, tekrar konaklama oranını ve sadakat çalışmasını anlamsız kılar. Birleştirme kuralı kurulumda tanımlanır; sonradan temizlemek çok daha pahalıdır.

Vergi ve fiyat gösterimi

Fiyatın vergi dahil mi hariç mi taşındığı, kanal ile PMS arasında en sık karışan konudur. Karıştığında hem misafire yanlış tutar görünür hem ay sonunda gelir tutmaz.

Entegrasyon hatalarının ortak özelliği sessiz olmalarıdır. Sistem uyarı vermez; yalnızca yanlış sayı üretir. Bu yüzden kurulumun değeri bağlantının kendisinde değil, test senaryolarının kapsamındadır.

Yeni bir bağlantı ya da yeni bir PMS, canlıya alınmadan önce uçtan uca denenir. Sıra şudur:

1. 01Sistem envanteri — hangi sistemler var, hangileri birbirine bağlı, hangi veri nereden geliyor.
2. 02Kaynak tanımı — her sayı için tek bir doğru kaynak seçilir. Aynı metriğin iki kaynağı varsa rapor tartışmalı olur.
3. 03Eşleme tablosu — oda tipleri, fiyat kodları, segment ve kanal kodları karşılıklı yazılır. Bu belge kurulumun en değerli çıktısıdır.
4. 04Test senaryoları — yeni rezervasyon, tarih değişikliği, iptal, no-show, oda değişikliği, grup bloğu, ek harcama. Her senaryo iki sistemde de doğrulanır.
5. 05Gecikme ölçümü — fiyat ve stop-sale güncellemesinin kanala ne kadar sürede ulaştığı kayda geçer.
6. 06Paralel çalışma — mümkünse bir dönem eski ve yeni akış birlikte yürütülür, sayılar karşılaştırılır.
7. 07Canlıya geçiş ve gözetim — ilk günlerde günlük mutabakat yapılır; hata bu pencerede yakalanır.
8. 08Devir — kontrol listesi, eşleme tablosu ve sorun giderme adımları yazılı olarak otelde kalır.

Bu adımların en çok atlananı test senaryolarıdır ve atlanmasının bedeli hep aynı yerde ödenir: açılış ya da geçiş gününde, misafirin karşısında.

Entegrasyon teknik olarak çalışıyor olabilir ve rapor yine de güvenilmez kalabilir. Sebep genellikle veri girişinin tutarsızlığıdır: aynı segmentin farklı kodlarla girilmesi, kanal kodunun boş bırakılması, grup rezervasyonlarının bireysel gibi kaydedilmesi.

• Segment ve kanal kodları sınırlı ve yazılı tutulur; serbest metin alanı raporu bozar.
• Zorunlu alanlar operasyonu yavaşlatmayacak kadar az, raporu ayakta tutacak kadar çok seçilir.
• Giriş kuralları resepsiyon ve rezervasyon ekibine anlatılır; kural bilinmeden tutarlılık beklenemez.
• Düzenli bir veri denetimi yapılır: kodsuz kayıtlar, mükerrer misafirler, olağandışı fiyatlar.
• Tanımlar tek bir belgede durur ve raporlama bu belgeyle aynı dili konuşur.

Raporun kalitesi, en zayıf veri girişinin kalitesidir. Bu yüzden entegrasyon çalışması sistemlerle başlar ama ekibin günlük alışkanlıklarıyla biter.

• Sistem haritası — hangi veri nereden nereye akıyor, hangi yönde.
• Kaynak tanımı — her metrik için tek doğru kaynak.
• Eşleme tablosu — oda tipi, fiyat kodu, segment ve kanal karşılıkları.
• Test senaryosu listesi — geçiş öncesinde ve sonrasında kullanılacak kontrol seti.
• Gecikme ölçümü — kritik güncellemelerin kanala ulaşma süresi.
• Veri giriş kuralları — resepsiyon ve rezervasyon için kısa, uygulanabilir kılavuz.
• Mutabakat düzeni — PMS ile muhasebe ve kanal arasındaki günlük/aylık karşılaştırma.
• Devir dosyası — sorun giderme adımları ve sorumluluklar.

Amaç sistemi değiştirmek değil, mevcut sistemlerin birbirini doğru anlamasını sağlamaktır. Doğru kurulduğunda entegrasyonun görünen sonucu şudur: kimse sabahları tabloyu elle düzeltmez.