Bir Bodrum butik otel zincirinin genel müdürünü düşünün — 78 odalı iki tesisi var, her ikisinde de ayrı rezervasyon motoru, ayrı çağrı merkezi yazılımı, üç farklı OTA kanalı ve resepsiyonda kendi başına çalışan bir PMS sistemi. Pazarlama departmanı ayrı bir CRM kullanıyor, mobil uygulamayı dışarıdan bir ajans yönetiyor. Misafir web sitesinden rezervasyon yapıp akşam çağrı merkezini aradığında, operatörün önünde o misafiri tanıyan hiçbir ekran yok. Aynı misafir check-in sırasında özel bir oda isteğini belirttiğinde, bu bilgi ertesi sabah kahvaltı ekibine ulaşmıyor. Tüm bu araçlar ayrı ayrı çalışıyor ve hepsi kendi başına makul bir işi yapıyor — ama hiçbiri diğerinin ne bildiğini bilmiyor. Bu resim 2019 Türkiye otelciliğinde istisna değil, kural.Bu noktada sektörde iki ayrı kampın tartıştığını görüyoruz. Birinci kamp şunu savunuyor: ‘En iyi aracı al, sonra bağla.’ Yani önce en güçlü rezervasyon motorunu, en gelişmiş CRM’i, en kapsamlı PMS’i satın al — entegrasyon sorunu zaten çözülür, çünkü API’lar var. İkinci kamp ise tam tersini öne sürüyor: ‘Önce ortak veri modeli kur, sonra araç seç.’ Hangi sistem hangi formatta hangi veriyi üretiyor, kimin erişim hakkı var, misafir kimliği nerede tek kaynağa bağlanıyor — bunlar netleşmeden araç satın almak evi duvar koyarak inşa etmektir. Benim tezim şu: Her iki kampın da haklı olduğu bir nokta var — ama Türkiye’deki orta ölçekli bağımsız oteller için birinci kampın tavsiyesi, mevcut ekip yapısı ve bütçe kısıtı göz önüne alındığında genellikle çok pahalı bir hata üretir.Birinci kampın neden cazip göründüğünü anlamak zor değil. Özellikle 2018 kurunun fırlayıp döviz bazlı teknoloji harcamalarını ikiye katladığı bir ortamda, ‘zaten ödüyorum, en iyisini alayım’ mantığı işletilebilir görünüyor. Üstelik büyük rezervasyon motorları ve kurumsal PMS sistemleri gerçekten güçlü API kütüphaneleriyle geliyor — teoride her şey bağlanabilir. İkinci kampın argümanı ise daha kuru ama daha sağlam: API bağlantısı teknik bir sorun değil, veri semantiği sorunudur. Bir sistemde ‘misafir’ alanı pasaport numarasıyla tanımlanıyorsa, diğerinde e-posta adresiyle, üçüncüsünde rezervasyon numarasıyla — bu üç sistem aynı misafiri konuştuklarında aynı kişiyi mi anlıyorlar? Cevap hayır ise, entegrasyon katmanı ne kadar gelişmiş olursa olsun üstüne yanlış veri akıyor demektir. Saha gözlemimde pek çok otelin bu sorunla karşılaştığını gördüm: sistemler bağlanmış, gösterge tablosu parlıyor, ama misafir profilleri birkaç ayda bir çürüyor çünkü kimlik çözümleme (identity resolution) mekanizması kurulmamış.Türkiye otelciliğinin kendine özgü bir dinamiği bu tartışmayı daha da keskinleştiriyor: OTA bağımlılığı. Antalya bölgesindeki orta ölçekli bir resort için Booking.com ve Expedia üzerinden gelen rezervasyonların toplam rezervasyon içindeki payı kolaylıkla %52’yi aşabiliyor — bu rakam Ege kıyısındaki butik tesisler için de benzer seyrediyor. OTA’lar misafir verisi üzerinde ciddi kısıtlamalar koyuyor; tesisin elinde tam bir iletişim bilgisi yerine OTA’nın maskelediği bir e-posta adresi kalıyor. Bu gerçek, ‘önce veri modeli kur’ argümanını güçlendiriyor: OTA kanalından gelen misafiri doğrudan iletişime geçince yakalayabilmek için check-in anındaki veri toplama sürecinin net bir şekilde tasarlanmış olması gerekiyor. Bu süreç CRM’in özelliği değil — misafir yolculuğunun temas noktalarına gömülü, kasıtlı bir veri mimarisi kararıdır.Peki hangi koşulda araç önce, hangi koşulda mimari önce? Üç veya daha fazla tesis işleten, ortak sadakat programı kurmayı hedefleyen, gelecekte doğrudan rezervasyon oranını artırmak isteyen bir otel grubu için mimariyi önce kurmak hem daha ucuz hem daha az hata üretiyor. Sistemler arası misafir kimliği tutarsızlığını sonradan düzeltmek, doğru yapmaktan iki ila üç kat daha pahalı çıkıyor — bu kendi gözlemlediğim vakalarda tutarlı biçimde görünen bir örüntü. Buna karşın tek tesisli, sezonu kısıtlı, BT desteği için dışarıya bağımlı küçük bir butik otel için önce en basit şekilde çalışan bir PMS-CRM köprüsü kurmak ve üzerinde öğrenmek daha mantıklı. Mimari kararı o öğrenmeden sonra almak daha sağlıklı sonuçlar veriyor. Burada önemli bir uyarı var: ‘önce basit başla’ yaklaşımı kolaylıkla ‘hiç mimari kurma’ya dönüşüyor. Altı ayda bir yeni bir araç eklenen, hiçbir veri standardı olmayan sistemlerin bakım maliyeti, ilk başta doğru yapmanın maliyetini aştığında genellikle kimse fark etmiyor — çünkü bu maliyet IT faturasında değil, yanlış kişiselleştirme kararlarında ve kaçan tekrar rezervasyonlarında gizleniyor.Somut olarak ne yapılabilir? Birinci adım, her temas noktasındaki veri üretim sorumluluğunu tek bir tabloya çıkarmak. Web sitesi hangi alanı hangi formatta üretiyor, çağrı merkezi bunu nasıl alıyor, PMS bu ikisini nasıl eşleştiriyor — bu tablo yoksa entegrasyon konuşmaya başlamamak gerekir. İkinci adım, misafir kimliğini çözümleyecek ‘altın kayıt’ (golden record) mantığını belirlemek: hangi sistem birincil kaynak, çakışma durumunda kural ne. Bu karar teknik değil, iş süreci kararıdır ve genel müdürün onaylaması gereken bir karardır. Üçüncü adım, sezon dışında — Kasım veya Ocak gibi operasyon yavaşladığında — bu mimariyi test etmek için en az sekiz hafta ayırmak. Sezon içinde entegrasyon düzeltmeye çalışmak hem riskli hem verimsiz. Son olarak: bu süreci dış bir yazılım danışmanına değil, otel içinden bir süreci bilen birine sahiplendirin. Müdür yardımcısı veya satış direktörü, projenin iş gereklilikleri tarafını yönetmek zorunda — teknik ekip arkadan desteklemeli.Bodrum’daki o genel müdüre döneceğim: Eğer iki tesisin verilerini birleştirip ortak bir misafir profili oluşturmak istiyorsa, şu an kullandığı araçların hiçbirini değiştirmeden sadece kimlik çözümleme katmanını ve veri sahipliği kararlarını netleştirerek başlayabilir. Bu kararlar yerleşmeden yapacağı her yeni araç alımı, üstüne bina koyulan çürük bir temel olmaya devam edecek. Dijital dönüşüm otelcilikte araç satın almak değil, bu kararları almak demektir.