1. Tek Otelden Çok Otelli Mimarilere Geçiş
Tek tesis büyürken süreçler “insanla” yönetilebilir; fakat tesis sayısı arttığında değişiklikler ölçeklenir: oda/fiyat güncellemeleri, kampanya yayılımı, kanal yönetimi ve raporlama artık merkezî kontrol ister. Burada geçişi doğru yapmak için önce “neden multi-property?” sorusunu netleştirin: tek panel raporlama mı, ortak fiyat stratejisi mi, merkezi denetim mi?
Bu bölümde ne öğreneceksiniz?
- •Tek tesis yaklaşımının hangi noktada kırıldığını
- •Multi-property geçişin hangi kazanımı getirdiğini
- •Pilot ve yayılım (rollout) mantığını
Ne yapmalıyım?
- • Geçiş hedefini tek cümle yaz: “tek panel rapor + ortak tanımlar”
- • Pilot tesis/cluster seç ve önce orada stabilize et
- • Eski düzenle yeni düzen arasında çift kayıt dönemini net yönet
2. Grup/Zincir Oteller İçin PMS Mimari Modelleri
Çok otelli yapılarda iki ana yaklaşım vardır: tek PMS instance ile çok tesis veya tesis bazlı PMS instance’ları. Hangisinin doğru olduğu; markalar/destinasyonlar, operasyon standardı ve raporlama ihtiyacına bağlıdır. Yanlış seçim, ya “merkez her şeyi kilitler saha yavaşlar” ya da “her otel ayrı çalışır veri dağılır” sorununu doğurur.
Bu bölümde ne öğreneceksiniz?
- •Tek PMS mi çoklu PMS mi karar kriterleri
- •Hibrit modelin ne zaman mantıklı olduğu
- •Kanal yönetimi ve raporlama etkileri
Model 1: Tek PMS instance (merkezî mimari)
- •Artı: ortak tanımlar, konsolide rapor, merkezi denetim
- •Eksi: yerel esneklik doğru tasarlanmazsa saha yavaşlayabilir
Model 2: Çoklu PMS instance (tesis bazlı)
- •Artı: yerel operasyon bağımsızlığı, farklı süreçlere esneklik
- •Eksi: konsolidasyon zorlaşır, veri sözlüğü şart
Model 3: Hibrit (grup standart + yerel varyasyon)
- •Artı: merkez standardı korur, saha esnekliği var
- •Eksi: governance (değişiklik yönetimi) zayıfsa bozulur
| Kriter | Tek PMS Instance | Çoklu Instance | Hibrit |
|---|---|---|---|
| Konsolide rapor kolaylığı | Yüksek | Orta | Yüksek |
| Yerel esneklik | Orta | Yüksek | Yüksek |
| Governance ihtiyacı | Orta | Yüksek | Çok yüksek |
| Kanal yönetimi standardı | Kolay | Zor | Orta |
| Ölçeklenebilirlik | Yüksek | Orta | Yüksek |
Ne yapmalıyım?
- • Karar matrisini çıkar: rapor ihtiyacı, marka farkı, entegrasyon karmaşıklığı
- • Hibritte “istisna listesi” ve onay kuralını yazılılaştır
- • Kanal/OTA tarafında mapping standardını tek sözlük yap
3. Kullanıcı ve Yetki Yapısı
Multi-property yapılarda güvenlik ve hız aynı anda yönetilmelidir. En kritik risk, yanlış kurgulanmış yetkilerle “grup tanımı”nın otel tarafından değiştirilmesi ve yanlış fiyat yayılımıdır. Yetki katmanını Corporate HQ → Cluster → Property şeklinde düşünün; hangi rol hangi seviyede değişiklik yapabilir netleşmelidir.
Bu bölümde ne öğreneceksiniz?
- •Grup/cluster/otel rol katmanları
- •En az yetki + görev ayrımı
- •Denetim ve loglama gereksinimleri
Ne yapmalıyım?
- • “Shared definitions değişikliği” yetkisini minimum rolde tut
- • Rol matrisi + log/denetim rutini kur
- • Sezon öncesi erişim gözden geçirme sprint’i yap (Antalya/Bodrum örneği)
4. Raporlama ve Konsolide Gelir Analizi
Konsolide raporlama, multi-property mimarinin “en görünür” kazancıdır. Merkez ofisin tüm tesislerin doluluk, gelir ve kanal performansını tek dashboard’da görmesi, yalnızca BI aracıyla değil; ortak tanımlar + KPI sözlüğü + veri disiplin ile mümkün olur. Yanlış mimaride ise her otel farklı tanım kullanır, raporlar birleştirilemez ve yönetim “yanlış doğru” ile karar alır.
Bu bölümde ne öğreneceksiniz?
- •KPI sözlüğü ve tanım standardı
- •Konsolide dashboard kurgusu
- •Kanal ve fiyat stratejisini raporla bağlama
Karşı örnek & doğru örnek
Doğru PMS mimarisinde Corporate HQ tüm tesislerin doluluk ve gelirini tek dashboard’da izler; yanlış mimaride veri dağınıklığı yüzünden aynı raporu üretmek bile zorlaşır.
Ne yapmalıyım?
- • Grup KPI sözlüğü yayınla (doluluk, ADR, RevPAR vb.) (Varsayım: metrik seti)
- • Tesis bazlı istisnaları raporda etiketle (karşılaştırılabilirlik için)
- • Looker Studio/BI katmanında tek panel model kur
5. Uygulama Örnekleri ve Yaygın Hatalar
Multi-property mimaride hatalar genelde 3 noktada toplanır: (1) shared definitions dağılması, (2) yetki katmanının yanlış kurulması, (3) rapor tanımlarının standardize edilmemesi. Antalya + Bodrum gibi iki farklı destinasyonda oteli olan gruplarda, pazar/dil/kampanya farkları sebebiyle yerel esneklik gerekir; ama bu esneklik kontrolsüz olursa “standardın bozulması”na dönüşür.
Yaygın hatalar
- •Her otelin ayrı oda/fiyat sözlüğü tutması
- •İstisnaların onaysız açılması
- •Grup rate plan’lerinin otel bazında rastgele değiştirilmesi
- •Kanal yönetimi mapping standardının olmaması
- •KPI tanımlarının otelden otele değişmesi
- •Pilot yapmadan tüm gruba yayılım
- •Log/denetim olmadan değişiklik yapmak
Ne yapmalıyım? (hemen uygulanabilir 5 aksiyon)
- • Shared definitions sözlüğü oluştur ve versiyonla
- • Yetki matrisi + denetim raporu rutini kur
- • Kanal yönetimi mapping tablosunu tek kaynak yap
- • Pilot tesisle başla, sonra yay
- • KPI sözlüğünü kilitle, dashboard’u standartlaştır
6. Çok otelli yapılarda PMS mimarisi nasıl kurulmalı?
- Model seçin: tek PMS instance / çoklu instance / hibrit (hedeflere göre)
- Shared definitions kilitleyin: oda tipi, rate plan, şirket/acenteler sözlüğü
- Yetki katmanlayın: Corporate HQ → cluster → property; en az yetki + log
- Konsolide raporlayın: KPI sözlüğü + tek dashboard + veri disiplin
- Rollout yapın: pilot → stabilizasyon → yayılım; istisnaları onayla yönetin
Ne yapmalıyım?
- • Mimari karar dokümanı (2 sayfa) çıkar
- • Antalya+Bodrum gibi farklı destinasyonlar için “yerel varyasyon” politikasını yaz
- • 90 gün içinde governance retrosu planla
7. Multi-Property PMS Mimari Checklistini İndir — PMS & OTA Yönetimi / Multi-Property
Multi-Property PMS Mimari Checklistini İndir — PMS & OTA Yönetimi / Multi-Property (v1.0)
Bu checklist, çok otelli yapılarda PMS mimarisini model seçimi, shared definitions, yetki katmanları, channel manager standardı ve konsolide raporlama başlıklarıyla tek dosyada netleştirir. Mimari kararların kişi bağımlı kalmasını önler. Pilot→yayılım sürecinde “boşlukları” erken yakalamanızı sağlar.
Kim Kullanır?
Corporate HQ + grup IT/entegrasyon + grup gelir + BI/raporlama + property GM’ler.
Nasıl Kullanılır?
- Model seçimi bölümünü doldurup tek/çoklu/hibrit kararını netleştirin.
- Shared definitions ve yetki matrisi alanlarını doldurup governance’i kilitleyin.
- 14 günlük sprint planıyla pilot tesis üzerinde test edip yayılıma geçin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Model seçimi yapıldı (tek/çoklu/hibrit) ve gerekçelendirildi
- ▢ ✅ Shared definitions sözlüğü (room type/rate plan/şirket) hazır
- ▢ ✅ İstisna politikası yazıldı (destinasyon/marka varyasyonları)
- ▢ ✅ Yetki katmanı (HQ/cluster/property) net ve test edildi
- ▢ ✅ Channel Manager mapping standardı tek kaynak doküman
- ▢ ✅ KPI sözlüğü ve konsolide dashboard taslağı hazır
- ▢ ✅ Pilot tesis seçildi ve kabul kriterleri belirlendi
- ▢ ✅ Log/denetim rutini tanımlandı
- ▢ ✅ Rollout takvimi ve eğitim planı hazır
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Multi-property PMS başarısı model, yetki ve rapor disiplinidir
Çok otelli yapılarda PMS mimarisi yalnızca teknik kurulum değildir; model seçimi, shared definitions, yetki katmanı, channel manager standardı ve konsolide raporlama birlikte tasarlanmalıdır. Tek PMS, çoklu PMS veya hibrit model kararı; grubun rapor ihtiyacı, destinasyon çeşitliliği ve operasyon standardına göre verilmelidir.
Doğru mimaride merkez ofis tüm tesislerin doluluk, gelir ve kanal performansını tek dashboard’da izlerken; property ekipleri kendi operasyonlarını kontrollü esneklikle yönetir. Başarı için önce mimari karar dokümanını netleştirin, sonra pilot tesisle test edip governance modelini kilitleyin.
Bir Sonraki Adım
Merkez ofisin yetki, fiyat ve rapor katmanlarını doğru kurması için.
Sık Sorulan Sorular
Çok otelli yapılarda PMS mimarisi nasıl kurulmalı?▾
Grup oteller için tek PMS mi, çoklu PMS mi?▾
Zincir otellerde kullanıcı ve yetki yapısı nasıl tasarlanır?▾
Grup seviyesinde PMS raporları nasıl görünür?▾
İlgili İçerikler