1. PMS Entegrasyon Projesinde Kim Ne Yapmalı?
Proje üç ana “taraf”la yürür: otel (iş sahibi), tedarikçi (uygulayıcı/ürün sahibi), ajans/web ekibi (uç sistemler ve dijital kanallar). Her tarafın rolü netleşmezse, iş paketleri gri alanda kalır ve gecikir.
Proje aşamaları: nerede kim öne çıkar?
- •Discovery/Analiz: otel + tedarikçi (ajans consulted)
- •Tasarım (mapping/kurallar): tedarikçi + otel ana kullanıcı (revenue/FO)
- •Geliştirme: tedarikçi (otel consulted)
- •Test/UAT: otel accountable, tedarikçi fix, ajans uç testlerde destek
- •Go-live: hepsi “war-room”
- •Hypercare (ilk 2–4 hafta) (Varsayım): tedarikçi + otel birlikte
Mini Check
- • Proje sponsoru ve proje yöneticisi belli mi?
- • Ana kullanıcılar (FO, revenue, muhasebe) atandı mı?
- • Ajans/web ekibi kapsamı net mi?
- • UAT onayı kimde?
- • Go-live sonrası hypercare sorumluluğu yazılı mı?
Ne yapmalıyım?
- • Sponsor + PM + ana kullanıcıları resmi atayın.
- • İş paketlerini “kim onaylar?” sorusuyla netleştirin.
- • UAT’yi otelin sahiplenmesini şart koşun.
- • Go-live sonrası 2–4 hafta hypercare planı yazın.
2. Otel, PMS Tedarikçisi ve Ajans Arasında Rol Dağılımı Nasıl Kurulur?
Rol dağılımının en pratik aracı RACI’dir: Responsible (yapan), Accountable (son karar/onay), Consulted (danışılan), Informed (bilgilendirilen). Otellerde en büyük sorun, “Responsible” ile “Accountable”ın karışmasıdır.
RACI matrisi (örnek)
| İş Paketi | Otel | PMS Tedarikçisi | Ajans/Web | Not |
|---|---|---|---|---|
| İş hedefleri & kapsam | A | C | C | sponsor onayı |
| Süreç analizi | R/A | C | I | FO + revenue |
| Mapping (oda/rate/kod) | A | R | I | değişiklik yönetimi |
| Entegrasyon geliştirme | C | R/A | C | API/connector |
| UAT test senaryosu | R/A | C | C | uç sistemler |
| Bug fix | C | R/A | C | sprint |
| Go-live cut-over | A | R | C | war-room |
| Monitoring & SLA | A | R | C | operasyonel sahiplik |
| Dokümantasyon | A | R | C | tek kaynak |
A=Accountable, R=Responsible, C=Consulted, I=Informed (örnek)
Sorumluluk diyagramı: 3 taraflı iş akışı
- •Otel: süreç + onay + UAT + operasyonel sahiplik
- •Tedarikçi: teknik çözüm + geliştirme + destek
- •Ajans/Web: web/CRM/ölçüm uçları + test desteği
Mini Check
- • Her iş paketi için A ve R tek kişi/ekip mi?
- • Mapping değişikliği onay süreci var mı?
- • Ajans kapsamı “uç sistemlerle” sınırlı mı?
- • Monitoring & SLA sahipliği otelde mi?
- • Decision Log tutuluyor mu?
Ne yapmalıyım?
- • RACI’yi 1 sayfada yayınlayın ve “tek kaynak” yapın.
- • Mapping değişikliklerini onaya bağlayın.
- • Ajans rolünü uç test + ölçümleme ile netleştirin.
- • Monitoring ve SLA’nın sahibi otel olsun; tedarikçi işletim desteği versin.
3. Otel Ekibi: Operasyon, IT, Revenue, Satış Kim Ne Yapar?
Otel içinde rol dağılımı yoksa dış taraflarla RACI çalışmaz. Çünkü dış taraflar “iş sahibini” bulamaz.
Proje sponsoru (GM/owner)
- •kapsam/öncelik çatışmalarını çözer
- •bütçe ve kaynak sağlar
- •go/no-go kararını verir
Proje yöneticisi (PM)
- •takvim, risk/issue, karar kayıtları
- •toplantı ritmi ve aksiyon takibi
- •tek iletişim kapısı (single point of contact)
Ana kullanıcılar (FO, revenue, muhasebe, HK, call center)
- •süreç doğrulama ve UAT
- •mapping/kurallar onayı
- •eğitim ve adaptasyon planı
Mini Check
- • PM tek iletişim kapısı mı?
- • Ana kullanıcılar isim bazında belli mi?
- • UAT onay mekanizması var mı?
- • Eğitim planı takvimde mi?
- • Go-live gününde vardiya planı hazır mı?
Ne yapmalıyım?
- • Ana kullanıcıları departman bazında atayın.
- • UAT onayı olmadan go-live yapmayın.
- • Eğitim ve iletişim planını takvime bağlayın.
- • Go-live gününü “operasyon planı” gibi yönetin.
4. Proje Yönetimi: Toplantı Ritmi, Dokümantasyon ve Go-Live Sonrası
Proje yönetimi, toplantı yapmak değil; doğru toplantıyı doğru ritimde yapıp kararları kayda geçirmektir. “Konuşuldu ama yapılmadı” en büyük kayıptır.
Haftalık toplantı ritmi (örnek)
- •30–45 dk haftalık durum toplantısı
- •10 dk risk/issue
- •10 dk karar gerektiren konular
- •10 dk test/go-live hazırlığı
- •5 dk aksiyon kapanış
| Bölüm | Süre | Çıktı |
|---|---|---|
| Durum özeti | 10 dk | ilerleme |
| Risk/Issue | 10 dk | owner + tarih |
| Kararlar | 10 dk | Decision Log |
| Test/Go-live | 10 dk | plan |
| Aksiyonlar | 5 dk | next steps |
Dokümantasyon: tek kaynak (Single Source of Truth)
- •RACI
- •mapping dokümanı
- •test senaryoları + UAT sonuçları
- •karar kayıtları (Decision Log)
- •go-live runbook + rollback plan (Varsayım)
Başlamanız için 10 soruluk proje hazırlık checklist’i
- Sponsor kim?
- PM kim?
- Ana kullanıcılar kim?
- Kapsam: hangi entegrasyonlar var?
- Mapping sahibi kim?
- UAT kriteri nedir?
- Go-live günü kim nöbette?
- Hypercare süresi kaç hafta? (Varsayım)
- Monitoring ve SLA sahibi kim?
- Decision Log nerede tutulacak?
Key Statistics / Data Point (sheet – senaryo): İyi tanımlanmış proje yapısı olan otellerde; entegrasyonun süre ve hata sayısı “kimin sorumluluğu” tartışmalarının yaşandığı projelere göre çok daha düşük kalabilir. Etkiyi yaratan; RACI + toplantı ritmi + karar kayıtlarının birlikte işletilmesidir.
Mini Check
- • Haftalık ritim sabit mi?
- • Aksiyonlar owner + tarih ile kapanıyor mu?
- • Decision Log güncel mi?
- • Go-live runbook var mı?
- • Hypercare sorumluluğu yazılı mı?
Ne yapmalıyım?
- • Haftalık ritmi sabitleyin; kararları log’a yazın.
- • Dokümantasyonu tek kaynakta toplayın.
- • Go-live runbook + rollback planı yazın.
- • Hypercare’de incident triage ve eskalasyon süreci belirleyin.
5. PMS Projesi İçin RACI Matrisi & Toplantı Ajandası Şablonunu İndir
PMS Projesi İçin RACI Matrisi & Toplantı Ajandası Şablonunu İndir — Otel / Project Governance (v1.0)
Bu şablon, PMS entegrasyon projesinde otel–tedarikçi–ajans rollerini RACI ile netleştirir, haftalık toplantı ritmini ve karar kayıtlarını (Decision Log) standartlaştırır. Amaç; “kim sorumlu” tartışmalarını azaltıp kararları hızlandırmak, takvimi gerçekçi yönetmek ve go-live sonrası sorumluluğu baştan belirlemektir.
Kim Kullanır?
Proje sponsoru + PM + otel ana kullanıcıları + tedarikçi PM + ajans lead birlikte.
Nasıl Kullanılır?
- İş paketlerini listeleyin ve her satıra RACI atayın.
- Haftalık ajandayı sabitleyin; aksiyonları owner+tarih ile kapatın.
- Go-live öncesi runbook ve hypercare sorumluluklarını aynı dokümana ekleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ RACI Matrisi Şablonu (Boş)
- ▢ ✅ Haftalık Toplantı Ajandası (Sabit)
- ▢ ✅ Durum (10 dk)
- ▢ ✅ Risk/Issue (10 dk)
- ▢ ✅ Karar gerektirenler (10 dk)
- ▢ ✅ Test/Go-live hazırlığı (10 dk)
- ▢ ✅ Aksiyonlar & kapanış (5 dk)
- ▢ ✅ Decision Log (Karar Kaydı)
- ▢ ✅ Go-live Runbook Mini Şablon
- ▢ ✅ Cut-over adımları: ____
- ▢ ✅ Rollback planı: ____ (Varsayım)
- ▢ ✅ War-room iletişim: ____
- ▢ ✅ Nöbet/vardiya: ____
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
6. Sonuç: PMS entegrasyonunda teknik başarı, governance netliğiyle gelir
PMS entegrasyonu teknik olduğu kadar yönetsel bir projedir. Otel, tedarikçi ve ajans rollerini netleştirmeden; doğru RACI, doğru toplantı ritmi ve doğru karar kaydı kurulmadan takvim, kalite ve go-live başarısı sürdürülebilir hale gelmez.
Bu çerçeveyle proje “kim ne yapacak?” tartışmasından çıkar, ölçülebilir ve yönetilebilir bir çalışma modeline dönüşür. Sponsor, PM, ana kullanıcılar, tedarikçi ve ajans aynı oyun planında buluştuğunda gecikme ve yeniden iş azalır; hypercare dönemi daha kontrollü yönetilir.
Bir Sonraki Adım
Rol karmaşasını azaltıp projeyi kontrollü yürütmek isteyen oteller için.
Sık Sorulan Sorular
PMS entegrasyon projesinde otel ekibinin rolü ne olmalı?▾
PMS sağlayıcısı ve ajans hangi işlerden sorumlu?▾
RACI matrisi PMS projelerinde nasıl kullanılır?▾
Proje toplantıları ve karar kayıtları nasıl tutulmalı?▾
Go-live sonrası sorumluluk paylaşımı nasıl olmalı?▾
İlgili İçerikler
İlgili Yazılar