1. PMS Go-Live Öncesi Son Hazırlıklar
Go-live öncesi son hazırlıklar, “kapanışa” giden yolun temiz olmasını sağlar. Bu aşamada hedef; mapping’in kilitlenmesi, kritik entegrasyonların doğrulanması, kullanıcı rollerinin doğru atanması ve dry run ile “sahte gün”ün provasıdır.
Bu bölümde ne öğreneceksiniz?
- •Dry run ve parallel run farkı
- •Son 48 saat kontrol seti
- •Vardiya bazlı destek planı
PMS Go-Live öncesi yapılması gereken son kontroller
- •RoomType/RatePlan mapping kilitli mi? (değişiklik dondurma)
- •OTA/Channel Manager senkron testi (Varsayım: kanal kullanımı)
- •Fatura/folyo ve temel rapor seti doğrulaması
- •Kullanıcı rolleri (RBAC) ve kritik yetkiler kontrolü
- •Night audit / EOD deneme kapanışı (dry run)
- •Hata log + iletişim kanalı (tek kaynak)
- •Go-live destek vardiya planı (kim, hangi saat)
Mini Check
- • Son 48 saat değişiklik dondurma kararı var mı?
Ne yapmalıyım?
- • Go-live’dan önce “değişiklik freeze” uygula
- • Dry run raporlarını arşivle ve kabul kriterine bağla
- • Vardiya destek planını yazılı yayınla
2. İlk Gün Operasyon Senaryoları
İlk gün, “en basit gün” değildir; çoğu otelde en stresli gündür çünkü hem ekip yeni sisteme alışır hem de canlı misafir trafiği vardır. Bu yüzden ilk gün senaryoları önceden seçilip test edilmelidir: check-in/out, oda değişimi, iptal/no-show, ödeme/fatura, rapor kontrolü.
Bu bölümde ne öğreneceksiniz?
- •İlk günün 5 kritik senaryosu
- •Hızlı eskalasyon ve tekrar test mantığı
- •Resepsiyon–muhasebe ortak kontrol noktaları
İlk gün minimum senaryo seti
- Normal check-in/out + folyo kapanışı
- Oda değişimi + fiyat farkı (Varsayım)
- İptal/no-show işleme
- OTA’dan gelen rezervasyon değişikliği (Varsayım)
- Fatura kesimi + gelir kod kontrolü
- Açık folyo/pending post kontrolü
- Gün sonu rapor seti üretimi
Mini Check
- • İlk gün senaryoları için “pass/fail” kriteriniz var mı?
Ne yapmalıyım?
- • İlk gün için 1 sayfalık “komuta merkezi” planı çıkar
- • Hata olursa “kapat–tekrar test et” döngüsünü işlet
- • Misafir etkisi yüksek hataları (fiyat/oda) önceliklendir
3. İlk 7 Günlük Kontrol Listesi
İlk 7 gün, PostLaunchOptimization’ın en verimli dönemidir. Amaç; hata türlerini sınıflandırmak, tekrar eden sorunları kök nedene bağlamak ve sistemin “yeni normal”ini oturtmaktır. Aşağıdaki tablo “print edilebilir” bir günlük checklist olarak tasarlanmıştır.
Mini Check
- • Her gün aynı 4 alanı (check-in/out, rezervasyon, fatura, rapor) kontrol ediyor musunuz?
Ne yapmalıyım?
- • Checklist’i vardiya kapanışında imzalat (Varsayım)
- • Hataları tek issue board’da topla
- • Gün 7’de “stabilizasyon kapanış” mini toplantısı yap
| Gün | Check-in/out & Oda | Rezervasyon & Kanal | Fatura/Folyo | Rapor & Kapanış | Not |
|---|---|---|---|---|---|
| 1 | 10 işlem örneklemi | OTA değişiklik testi | 5 fatura kontrol | 3 rapor seti | pass/fail |
| 2 | oda status tutarlılığı | iptal/no-show | açık folyo taraması | EOD dry check | hata log |
| 3 | oda değişimi senaryosu | rate plan doğrulama | gelir kod kontrol | segment raporu | tekrar test |
| 4 | yoğun saat akışı | parallel run kıyası | düzeltme sayısı | fark analizi | kök neden |
| 5 | eğitim mini refresh | kanal senkron | iade/ters kayıt | rapor arşivi | SOP notu |
| 6 | hız KPI kontrol | rezervasyon tutarlılık | fatura hata oranı | dashboard kontrol | iyileştirme |
| 7 | final örneklem | mapping freeze | kapanış mutabakat | stabilizasyon raporu | kapanış |
4. Hata ve Geri Bildirim Süreçleri
Go-live sonrası hatalar kaçınılmazdır; kritik olan hatayı “dağınık konuşmak” değil, tek bir IssueTracking kanalıyla yönetmektir. Hata–geri bildirim–düzeltme döngüsü, özellikle vardiya değişimlerinde bilgi kaybını engeller.
Bu bölümde ne öğreneceksiniz?
- •Hata sınıflandırma (kritik/orta/düşük)
- •Tekrar üretme (repro) ve log mantığı
- •Vardiya bazlı iletişim rutini
Teknik + organizasyonel öneri
- •Kritik: yanlış fiyat/yanlış oda/ödeme sorunu → aynı gün hotfix
- •Orta: rapor tutarsızlıkları → 48 saat içinde düzeltme
- •Düşük: UI alışkanlık sorunları → eğitim/rehber
Mini Check
- • Hata takibi WhatsApp’ta mı, tek issue listesinde mi?
Ne yapmalıyım?
- • Hata şablonu kullan: tarih, senaryo, ekran, sonuç, çözüm
- • Düzeltme sonrası aynı senaryoyu tekrar test et
- • Günlük 15 dk “go-live standup” yap (ilk 7 gün)
5. Go-Live Sonrası İyileştirme Planı
İlk 7 günün sonunda amaç “bitti” demek değil, iyileştirme planını sprint’e bağlamaktır: top 10 hata, top 3 kök neden, eğitim ihtiyacı ve rapor standardı. Paralel çalışma yapılan otellerde ilk ay hata oranının anlamlı ölçüde düştüğü; paralel çalışma olmayanlarda ise ilk hafta kaosu yaşanabildiği yönünde pratik deneyimler vardır (tesis ölçeğine göre değişir). Bu yüzden parallel run, küçük otellerde bile kısa süreli uygulanabilecek bir “sigorta”dır.
Mini Check
- • Gün 7 sonunda “top 3 kök neden”i yazabiliyor musunuz?
Ne yapmalıyım? (hemen uygulanabilir 5 aksiyon)
- • Top 10 hatayı listele, sahip ata
- • 2 haftalık iyileştirme sprint’i planla
- • Eğitim refresh oturumu koy (resepsiyon + muhasebe)
- • KPI paneli kur: check-in süresi, açık folyo, hata oranı
- • Sezon öncesi ikinci bir kontrol penceresi planla (Antalya/Belek)
6. PMS Go-Live İlk 7 Gün Checklist’ini İndir — PMS & OTA Yönetimi / Go-Live
PMS Go-Live İlk 7 Gün Checklist’ini İndir — PMS & OTA Yönetimi / Go-Live (v1.0)
Bu asset, PMS go-live sonrası ilk 7 günü vardiya bağımsız standartlaştırmak için gün gün kontrol listesi, issue tracking şablonu ve 14 günlük stabilizasyon sprint planı sunar. Parallel run/dry run yaklaşımını pratikleştirir. Amaç, ilk hafta kaosu yerine kontrollü geçiş ve hızlı iyileştirme sağlamaktır.
Kim Kullanır?
PMS proje ekibi + front desk support + muhasebe + IT/entegrasyon (go-live komuta merkezi).
Nasıl Kullanılır?
- Go-live öncesi son kontrolleri tamamlayıp değişiklik freeze uygulayın.
- İlk 7 gün checklist’i vardiya kapanışında doldurun, hataları tek issue listesinde toplayın.
- 14 günlük sprint planıyla top hataları kapatıp SOP’u kilitleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Mapping freeze (RoomType/RatePlan)
- ▢ ✅ Dry run tamam + rapor arşivi
- ▢ ✅ Parallel run süresi net (Varsayım: 2–7 gün)
- ▢ ✅ Vardiya destek planı hazır
- ▢ ✅ İlk gün 5 senaryo test edildi
- ▢ ✅ Issue tracking tek kanalda
- ▢ ✅ Gün 7 stabilizasyon raporu üretilecek
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
7. Sonuç: PMS Go-Live İlk Hafta Kaosu Değil, Kontrollü Stabilizasyon Olmalı
PMS Go-Live, teknik kurulumun bittiği nokta değil; otel operasyonunun yeni sisteme güvenle taşındığı kritik geçiş fazıdır. Dry run, parallel run, vardiya desteği, issue tracking ve 7 günlük checklist birlikte çalıştığında ilk hafta kaosu yerine kontrollü stabilizasyon sağlanır.
Bu nedenle go-live süreci yalnızca IT veya PMS sağlayıcısının sorumluluğu gibi görülmemelidir. Ön büro, muhasebe, operasyon, GM ve entegrasyon ekipleri aynı kontrol listesiyle ilerlediğinde hatalar erken yakalanır, tekrar test edilir ve sistem yeni normaline daha hızlı oturur.
Bir Sonraki Adım
İlk hafta operasyonunu vardiya bazlı destekle yönetip hataları hızlı kapatmak isteyen GM ve proje ekipleri için.
Sık Sorulan Sorular
PMS Go-Live süreci nasıl yönetilir?▾
PMS canlıya alınmadan önce hangi testler yapılmalı?▾
PMS geçişinde ilk 7 günde nelere dikkat edilmeli?▾
Eski sistemle paralel çalışma ne kadar sürmeli?▾
İlgili İçerikler