1. Çok Otelli Yapılarda PMS Entegrasyon Mimarisi Nasıl Tasarlanmalı?
Çok otelli mimari tasarımının hedefi iki şeyi aynı anda başarmaktır:
- Merkez ofis için tek dilde raporlama (Group Report) ve standart entegrasyon yönetimi
- Tesis için operasyonel gerçeklik ve esneklik (Property-level rules)
Tasarım prensipleri: “tek dil” + “yerel esneklik”
- •Tek dil: KPI tanımları, kanal sınıfları, rate plan sözlüğü, oda tipi sınıfları
- •Yerel esneklik: her tesisin segment/destinasyon dinamikleri, operasyon farklılıkları, yerel regülasyonlar
- •Merkez yönetişim: entegrasyon standartları, loglama, erişim ve denetim
Multi-property’de en büyük tuzak
En büyük tuzak, raporlamayı birleştirmeye çalışırken tesisleri “aynı otel” gibi zorlamaktır. Örneğin Bodrum resort ile şehir otelinin minimum konaklama, paket yapısı ve kanal karması farklıdır. Mimari model, bu farkı yönetmelidir.
Mini Check
- • Grup için “tek rapor dili” tanımlandı mı? (KPI sözlüğü)
- • Tesislerin yerel esneklik alanları net mi? (kural setleri)
- • Entegrasyonlar merkezden mi yönetilecek, tesis bazlı mı?
- • Kullanıcı erişimleri tesis bazlı ayrışıyor mu?
- • Veri lokasyonu ve regülasyon uyumu (KVKK/benzeri) ele alındı mı?
Ne yapmalıyım?
- • 1. KPI sözlüğünü kilitleyin (grup dili).
- • 2. “Tesis esnekliği” sınırlarını yazın (nerede farklı olabilir?).
- • 3. Entegrasyon yönetim modelini seçin (merkez / hibrit).
- • 4. Güvenlik ve veri lokasyonu maddesini tasarıma ekleyin.
2. Grup ve Zincir Otellerde PMS Yapısı Nasıl Kurgulanmalı?
Bir zincir ya da grup otelde PMS yapısı, “merkez ofis mi güçlü, tesis mi bağımsız?” sorusuna göre şekillenir. İdeal yaklaşım genelde uçlarda değil, hibrit bir modeldedir: grup görünürlük ister, tesis operasyon ister.
Merkez ofis hedefleri
- •grup gelir/doluluk tek panel
- •kanal payı ve komisyon görünürlüğü
- •standart raporlama ritmi
- •entegrasyon ve güvenlik denetimi
Tesis hedefleri
- •hızlı operasyon (front office)
- •yerel fiyat/kural esnekliği
- •destinasyona göre kanal karması
- •yerel ekiplerin rol bazlı yetkileri
Mini örnek: Antalya–Belek bölgesinde resort’larda paket/kampanya yapısı ağır basarken, city otelde hafta içi iş seyahati segmenti belirleyicidir. Grup raporu tek olmalı; ama tesis kural seti farklı olabilir.
Mini Check
- • Grup raporu için ortak KPI seti hazır mı?
- • Oda tipi ve rate plan sözlüğü standardize mi?
- • Tesislerde farklı para birimi/vergisel ihtiyaç var mı? (Varsayım)
- • Entegrasyonları kim yönetiyor? (merkez/tesis)
- • Yetki matrisi tesis bazlı ayrışıyor mu?
Ne yapmalıyım?
- • 1. Grup raporu hedeflerini netleştirin (hangi kararlar?).
- • 2. Sözlük standardı kurun (oda tipi, kanal, rate plan).
- • 3. Tesis kural setini “modül” gibi düşünün: ortak çekirdek + yerel fark.
- • 4. Yetki ve denetimi merkezden standardize edin.
3. Tek PMS – Çok Tesis vs Tesis Bazlı PMS Modelleri
Burada “doğru/yanlış” yok; bağlama göre doğru model var. Karar, büyüklük, ülkeler, operasyon çeşitliliği ve entegrasyon ekibinin olgunluğuna bağlıdır.
Tek PMS – Çok tesis (single instance / shared database)
Artılar
- •tek rapor dili ve merkezi yönetim daha kolay
- •entegrasyon standardı tek yerden ilerler
- •grup seviyesinde görünürlük hızlı
Eksiler
- •bir değişiklik tüm tesisleri etkileyebilir
- •yerel farklılıkları yönetmek zorlaşabilir
- •regülasyon/veri lokasyonu kısıtlarında zorlanabilir
Tesis bazlı PMS (multi instance / ayrı PMS’ler)
Artılar
- •tesis bağımsızlığı yüksek
- •yerel regülasyon ve süreçlere uyum kolay
- •risk izolasyonu (bir tesis etkilenir)
Eksiler
- •grup raporu ve veri birleştirme maliyeti artar
- •entegrasyon standardı dağılabilir
- •farklı PMS versiyonları “teknik borç” yaratır
Mini örnek: Bodrum ve Antalya’da farklı segmentlerde tesisleriniz varsa, tesis bazlı model operasyonel esneklik sunar; ama grup raporu için BI katmanı şarttır. Tek PMS modelinde ise BI daha hızlı başlar; fakat yerel farklılıklar iyi tasarlanmazsa sahada sürtünme artar.
Mini Check
- • Grup raporu “anlık” mı “günlük/haftalık” mı gerekli?
- • Tesislerin süreçleri çok farklı mı?
- • Ülke/regülasyon farklılıkları var mı?
- • Entegrasyon ekibiniz merkezi standardı yönetebilir mi?
- • Risk izolasyonu ihtiyacı yüksek mi?
Ne yapmalıyım?
- • 1. Kararı “rapor ihtiyacı + operasyon farklılığı” matrisiyle verin.
- • 2. Tek PMS seçiyorsanız: yerel kural setlerini iyi tasarlayın.
- • 3. Çok PMS seçiyorsanız: BI katmanını zorunlu kabul edin.
- • 4. Her iki modelde de: entegrasyon standartlarını yazılı hale getirin.
4. Merkez Ofis, Otel ve Departman Bazlı Erişim ve Raporlama
Multi-property’de “erişim” konusu sadece güvenlik değil; operasyonel verimlilik konusudur. Merkez ofis herkesin ekranına girmemeli; ama grup raporu için yeterli görünürlük olmalı. Aynı şekilde otel içindeki departmanlar (ön büro, revenue, muhasebe, call center) farklı yetkilere sahip olmalı.
Rol & raporlama tasarım mantığı
- •Property-level user: sadece kendi tesisi
- •Group user: tesisler arası rapor (maskeli/aggregate)
- •Department roles: iş süreçlerine göre minimum yetki
Grup vs otel bazlı KPI yaklaşımı
Grup raporu ile otel raporu aynı KPI’ları farklı granülerlikte taşır:
- •Grup: trend, karşılaştırma, risk sinyali
- •Otel: aksiyon, operasyon detayı, görev listesi
| KPI | Grup Seviyesi Ne İçin? | Otel Seviyesi Ne İçin? |
|---|---|---|
| Doluluk | tesisler arası kıyas | oda/segment aksiyonu |
| ADR | portföy fiyat stratejisi | rate plan optimizasyonu |
| RevPAR | yatırım ve hedef takibi | kampanya/kanal kararları |
| Kanal Payı | OTA bağımlılığı resmi | kanal bazlı müdahale |
| İptal/No-show | risk profili | garanti/ön provizyon aksiyonu |
| Pickup | erken uyarı | günlük fiyat/limit aksiyonu |
Destinasyon ve segment farklarının rapora yansıması
Antalya/Belek resort’larında sezon ve minimum konaklama etkisi büyükken, city otelde hafta içi/hafta sonu dengesi belirleyicidir. Grup raporu bu farkı saklamamalı; “segment/destinasyon etiketi” ile görünür kılmalıdır.
Mini Check
- • Grup kullanıcıları için erişim maskeli/aggregate mi?
- • Tesis kullanıcıları sadece kendi property’sini mi görüyor?
- • Departman rolleri yazılı mı?
- • KPI’lar grup ve otel seviyesinde aynı sözlüğe mi bağlı?
- • Benchmark raporu için etiketler (destinasyon/segment) var mı?
Ne yapmalıyım?
- • 1. Rol matrisini “property + department” olarak tasarlayın.
- • 2. Grup raporunu maskeli/aggregate standarda bağlayın.
- • 3. KPI sözlüğünü tekleştirin; rapor seviyesini filtreyle yönetin.
- • 4. Benchmark için segment/destinasyon etiketleri ekleyin.
5. OTA, Kanal Yönetimi ve Raporlamayla Çok Otelli Entegrasyon
Tek otelde bile kanal yönetimi karmaşıktır; çok otelde “karmaşıklık” katlanır. Multi-property’de hedef; kanal entegrasyonunu merkezden standardize etmek ama tesis bazlı kural esnekliğini korumaktır.
PMS–Kanal Yöneticisi–OTA mimarisini çok otelli düzleme taşımak
Temel ilke:
- •Merkez standartları: mapping, rate plan sözlüğü, loglama, entegrasyon SLA
- •Tesis kuralları: stop-sale, min-stay, paketler, pazar stratejisi
Raporlama katmanı (BI) zorunluluğu
Özellikle tesis bazlı PMS modelinde, grup raporu için BI katmanı şarttır. Tek PMS modelinde de BI, “yönetim paneli” için hız kazandırır.
Regülasyon ve veri lokasyonu notu (teknik)
Çok ülkeli yapıda verinin nerede tutulduğu, kimlerin eriştiği ve logların nerede saklandığı kritik hale gelir. KVKK ve benzeri regülasyonlarla uyum için:
- •veri lokasyonu ve erişim sınırları teknik olarak kurgulanmalı
- •cross-border erişimler kayıt altına alınmalı (log)
- •mümkünse tenant/instance ayrımı değerlendirilmelidir (Varsayım)
Mini Check
- • Kanal mapping ve rate plan sözlüğü grup standardı mı?
- • Entegrasyon logları tesis ve grup bazında izleniyor mu?
- • Tesis kuralları (min-stay/stop-sale) esnek mi?
- • BI katmanında grup raporu net mi?
- • Veri lokasyonu ve regülasyon uyumu tasarıma eklendi mi?
Ne yapmalıyım?
- • 1. Kanal entegrasyon standartlarını yazın (mapping, sözlük, log).
- • 2. Tesis kural setlerini modüler yönetin.
- • 3. Grup raporu için BI panelini zorunlu hale getirin.
- • 4. Veri lokasyonu/erişim/regülasyon maddelerini teknik tasarıma ekleyin.
6. Örnek Multi-Property Senaryoları ve Karar Çerçevesi
Karar çerçevesini “şu daha iyi” diye değil, senaryoyla kurun:
Senaryo 1: Aynı destinasyon, benzer tesisler (ör. Antalya bölgesinde 3 resort)
- •Tek PMS–çok tesis modeli çoğu zaman avantajlıdır
- •merkez raporu kolaylaşır, standardizasyon hızlı olur
- •tesis farklılıkları “kural seti” ile yönetilir
Senaryo 2: Farklı destinasyon + farklı segment (Bodrum resort + city otel)
- •Hibrit yaklaşım (tek PMS çekirdek + tesis esnekliği) daha sağlıklı olabilir
- •eğer çok PMS ise BI katmanı şarttır
- •rol/raporlama ayrışımı daha kritik hale gelir
Senaryo 3: Çok ülke / regülasyon farklılığı
- •veri lokasyonu, erişim ve mevzuat uyumu belirleyici olur
- •tenant/instance ayrımı değerlendirilebilir (Varsayım)
- •güvenlik & audit süreçleri standartlaştırılmalıdır
Key Statistics / Data Point (sheet – senaryo): Doğru kurgulanmış multi-property PMS mimarisine sahip zincirlerde, grup seviyesinde gelir ve doluluğu tek panelden görmek ve tesis bazlı aksiyon almak kolaylaşır; bu da ölçek ekonomisi ve stratejik karar kalitesini artırabilir.
Multi-Property PMS Mimari Karşılaştırma & Raporlama Şablonunu İndir — Otel Grubu / PMS Mimari (v1.0)
Bu şablon, çok otelli yapılarda “tek PMS–çok tesis” ile “tesis bazlı PMS” modellerini aynı çerçevede kıyaslamanızı sağlar ve kararın raporlama/entegrasyon/güvenlik etkisini görünür kılar. Ayrıca grup vs otel KPI sözlüğünü kilitleyerek, yönetim panelinin tek dilde çalışmasını kolaylaştırır.
Kim Kullanır?
Merkez ofis (CEO/COO/Revenue) + IT/BI + tesis GM’leri birlikte.
Nasıl Kullanılır?
- Mimari seçenekleri karşılaştırma matrisiyle puanlayın (rapor ihtiyacı, operasyon farkı, regülasyon, risk).
- Rol & raporlama şablonunda “grup/tesis/department” erişimlerini netleştirin.
- OTA/kanal entegrasyonu standardını ve BI panel mimarisini karar çıktısı olarak yazın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Mimari Karşılaştırma Matrisi (Boş Şablon)
- ▢ ✅ Rol & Erişim Şablonu (Grup–Tesis–Departman)
- ▢ ✅ Grup rolü: ____________________ (maskeli/aggregate mi?)
- ▢ ✅ Tesis rolü: ____________________ (sadece property mi?)
- ▢ ✅ Departman rolleri: Ön Büro/Revenue/Muhasebe/Call Center → ___________
- ▢ ✅ Kritik işlemler onayı: ____________________ (Varsayım: mümkünse)
- ▢ ✅ KPI Sözlüğü Şablonu (Grup Dilini Kilitle)
- ▢ ✅ OTA/Kanal Entegrasyonu Standardı (Boş Alanlar)
- ▢ ✅ Oda tipi sözlüğü: ____________________
- ▢ ✅ Rate plan sözlüğü: ____________________
- ▢ ✅ Mapping standardı: ____________________
- ▢ ✅ Log & SLA: ____________________
- ▢ ✅ BI paneli: ____________________ (Looker/diğer)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Mini Check
- • Model kararı KPI hedefleriyle ilişkilendirildi mi?
- • BI gereksinimi net mi?
- • Rol ve erişim modeli property bazında ayrışıyor mu?
- • Entegrasyon log & SLA standardı var mı?
- • Regülasyon/veri lokasyonu değerlendirmesi tamam mı?
Ne yapmalıyım?
- • 1. Kararı senaryoyla verin; “tek doğru” aramayın.
- • 2. BI’ı erken planlayın (özellikle çok PMS).
- • 3. Rol/erişim ve KPI sözlüğünü en başta kilitleyin.
- • 4. Entegrasyon standardını yazın ve denetleyin.
Bir Sonraki Adım
Grup görünürlüğü ile tesis esnekliğini aynı mimaride kurmak isteyen zincirler için.
Sık Sorulan Sorular
Grup ve zincir oteller için PMS entegrasyonu nasıl kurgulanmalı?▾
Tek PMS ile çok otel mi, her otel için ayrı PMS mi daha doğru?▾
Grup seviyesinde doluluk ve gelir raporu nasıl alınır?▾
Çok otelli yapılarda OTA ve kanal entegrasyonu nasıl çalışır?▾
Farklı ülkelerde tesis varsa veri lokasyonu ve regülasyon nasıl yönetilir?▾
Multi-property mimaride en sık hata nedir?▾
İlgili İçerikler