Yeni PMS kurulumu: oda tipi, fiyat kodu, gelir kodu ve kullanıcılar hangi sırayla tanımlanır?

Bir otel yönetim sistemi (PMS), bağımlılık sırasına göre kurulur: önce oda tipleri ve oda numaraları, sonra fiyat kodları, paketler ve pansiyon tipleri, ardından gelir ve ödeme kodları ile vergi ayarları, sonra pazar ve kaynak kodları, en son kullanıcılar, roller ve belge şablonları. Her tablo bir sonrakini besler; eski sistemin listeleri körü körüne kopyalanırsa yanlış raporlar yıllarca sürer.

Sözleşme imzalandı, geçiş gecesi takvime alındı, eğitmen pazartesi geliyor. Ama kimin bir gelir kodunun ne olduğunu söylemeye yetkili olduğu henüz karara bağlanmamış; eski sistemin listesi ise uzun, yarısı ayrılmış yöneticilerin adını taşıyor. Bu rehber, otel programı kurulumunun izlemesi gereken sırayı, her yapılandırma tablosunun ardındaki kararı ve imza yetkisinin kime ait olduğunu veriyor. Veri taşıma ve geçiş gecesi ayrı işlerdir; PMS değiştirirken veri taşıma ve geçiş gecesi kontrol listesi rehberlerinde ayrıca ele alınıyor.

PMS kurulumunda sıra neden önemli?#

Çünkü her yapılandırma tablosuna bir sonraki tablo referans verir: bir fiyat kodu oda tipi olmadan var olamaz, bir harcama gelir kodu olmadan hesaba işlenemez ve her rapor hepsini birleştirir. Sırayı bozarsanız ya kendinizi bloke edersiniz ya da ileride yeniden kurmak zorunda kalacağınız bir yapı kurarsınız.

Otel yönetim sistemi, rezervasyonları, odaları, hesapları ve raporları tutan yazılımdır; Türkiye'de otelciler arasında yaygın adı otel programıdır. Adı ne olursa olsun, bağımlılık zinciri şöyle işler: önce odalar, sonra fiyatlar, sonra para kodları, sonra segmentler ve kaynaklar, en son kullanıcılar ve belgeler. Her adım, bir öncekinin karara bağlanıp imzalandığını varsayar.

Eski sistemin listelerini kopyalamak, o listedeki tarihi de taşır: ölü kodlar, eski bir yöneticinin adıyla değiştirilmiş kodlar, çoktan bitmiş tek bir sözleşme yüzünden var olmuş kodlar. Bir kodu sonradan yeniden adlandırmak teknik olarak mümkündür, ama geçmiş raporlar ya geçmişi yeniden etiketler ya da tek satırı ikiye böler; ikisi de yıl sonunda bir tartışmaya mal olur.

Yapılandırma günlüğünden bir kişiyi sorumlu yapın: neyin eklendiğini, değiştirildiğini veya çıkarıldığını, hangi tarihte ve kimin onayıyla tutan tek bir tarihli liste. İlk tablo doldurulmadan önce dondurma kuralında anlaşın: imzadan sonra tablo kilitlenir, yeni bir şey yalnızca yazılı gerekçe ve tarihle eklenir.

İyi bir yapının sınavı bir menü değil, bir sorudur: yeni sistem, elektronik tablo kullanmadan, oda tipi bazında ve pazar segmenti bazında geliri yanıtlayabiliyor mu? Yanıtlayamıyorsa yapı henüz bitmemiştir.

Oda tipleri ve oda numaraları: önce ne karara bağlanır?#

Oda tipi listesi her şeyden önce karara bağlanır, çünkü oda tipi, fiyatların belirlendiği ve raporların oda tipine göre ayrıştırıldığı birimdir. Oda, numarası olan fiziksel bir kapıdır; oda tipi ise satılabilir bir kategoridir ve ikisi ayrı ayrı sayılmalıdır.

Her fiziksel oda tam olarak bir oda tipine aittir ve tip başına düşen sayı, geçiş gününde kat hizmetleri listesiyle eşleşmelidir. Buradaki bir uyumsuzluk her gece yanlış bir müsaitlik rakamı demektir. Tip listesini resepsiyonun baskı altında kullanabileceği kadar kısa tutun: yalnızca kat veya manzara farkıyla ayrışan bir tip, genellikle ayrı bir tip değil, bir öznitelik olarak ele alınmalıdır.

Yatak düzeni, manzara, balkon ve erişilebilirlik gibi öznitelikler tip adında değil, oda kaydında yer alır; aksi halde her öznitelik kombinasyonu fiyat kodlarınızı çoğaltır. Birleşik odalar bir tip değil, iki oda numarası arasındaki bir ilişkidir; çifti kaydedin ki rezervasyon ekranı ikisini birlikte sunabilsin.

Veri girişinden önce oda numaralandırma düzenini ve kat mantığını karara bağlayın; arızalı (out-of-order) ve bakımdaki (out-of-service) odaların nasıl ve ne kadar süreyle işaretleneceğini de dahil edin. Fiziksel olarak var olan ama satılmayan odaları, örneğin müdür dairesi veya depo odasını ne yapacağınızı belirleyin ve gerekçeyi yapılandırma günlüğüne yazın.

İmzadan önce şunu kontrol edin: sistemdeki toplam oda sayısı binadaki toplam oda sayısına eşit ve her tip için en az bir fiyat kodu planlanmış.

Oda tablosu imzalandığında fiziksel gerçeklik, daha geniş veri taşımasının parçası olarak geçer. Aşağıdaki mantık kopyalanmaz; yeniden kurulur.

Fiyat kodları ve paketler: kaç tane gerekiyor?#

Gerçekten sattığınız ve gerçekten raporladığınız her kombinasyon için bir fiyat kodu. Daha fazla kod, bakım yükünü ve yanlış fiyat riskini çoğaltır; daha az kod, raporda iki ürünü ayırt etme yeteneğini kaybettirir.

Bir fiyat kodu; oda tipi bağlantısı, pansiyon tipi, iptal ve garanti koşulu, geçerlilik süresi, pazar veya segment bağlantısı ve varsa paket içeriği taşır. Bunlardan ikisi farklıysa, iki koddur. Pansiyon tipleri bir kez karara bağlanmış kısa ve sabit bir liste olmalıdır, çünkü onaylarda, raporlarda ve misafirin neyin dahil olduğu beklentisinde görünür.

Çocuklar ve ek yataklar, yapılandırmadan önce yazılı bir kural ister: yaş aralıkları, üçüncü yatağın ücretli olup olmadığı ve hangi fiyat kodlarının buna izin verdiği. Bunun resepsiyona bırakılması tutarsız hesaplar üretir. Kahvaltı, akşam yemeği veya spa kredisi içeren bir paket, hesaba işlenirken gelir kodlarına bölünmelidir; bu bölüşümü paket oluşturulmadan önce muhasebeyle karara bağlayın.

Sezonsal ve konaklama süresine dayalı fiyatları bir temel fiyattan türetin; aynı rakamları kodlara kopyalamayın. Kopya, bir fiyat değişikliğinin gözden kaçtığı yerdir. Personel devri sonrası da okunabilen bir adlandırma kuralı kullanın, örneğin önce pansiyon tipi, sonra esneklik, sonra oda tipi; böylece bir kod açılmadan okunabilir.

İmzadan önce test ortamında her fiyat koduyla bir rezervasyon oluşturun, harcamaları hesaba işleyin ve ortaya çıkan misafir hesabını satır satır okuyun.

Gelir kodları, ödeme yöntemleri ve vergiler: kim karar verir?#

Gelir kodu listesine ve vergi ayarlarına muhasebe karar verir, günlük operasyonun bunlara nasıl eşleneceğine otel karar verir ve ikisi aynı kağıdı imzalar. Kestirmenin en pahalıya mal olduğu tablo budur, çünkü her gece muhasebe aktarımını besleyen yerdir.

Gelir kodu, bir harcamanın düştüğü kovadır: oda, yemek, içecek, spa veya minibar gibi. Gün sonu aktarımının okuduğu şey budur; bu yüzden resepsiyonun alışkanlıklarına değil, muhasebe planına uymak zorundadır. Listeyi kısa ve istikrarlı tutun: her küçük kalem için yeni bir kod, yıl bazında karşılaştırmayı parçalar; kimse yapamayacağı bir karşılaştırma, kimsenin okumadığı bir rapordur.

Ödeme yöntemleri gelir kodu değildir. Ödeme bir hesabı kapatır, gelir yaratmaz; ikisini karıştırmak hem gelir raporunu hem kasa raporunu bozar. Vergi ayarları muhasebecinin gösterdiği şekilde girilir; bu rehber oran veya fatura kuralı vermez, çünkü bunlar mükellefin durumuna bağlıdır ve değişir. Tarihleri, yaptırımları ve kendi durumunuzu muhasebeciniz ya da hukuk danışmanınızla teyit edin.

Eşleştirme tablosunu bir kez kurun: solda PMS kodu, sağda muhasebe hesabı, kod başına bir satır, imzalı ve tarihli; yapılandırma günlüğüyle birlikte saklayın. Düzeltme silmeden yapılabilir olmalıdır: sistemin bir kaydı silmek yerine iptal ve ters kayıtla düzelttiğini kontrol edin ki günün toplamları yine uzlaşsın. Gün sonunda neyin aktarıldığını ve eksiksiz ulaştığını nasıl kontrol edeceğiniz gün sonu aktarım rehberinde anlatılıyor.

İmzadan önce her türden bir harcama ve her yöntemden bir ödeme işleyin, iş gününü kapatın ve gün sonu toplamlarını muhasebecinin beklediğiyle karşılaştırın.

Pazar ve kaynak kodları: neden devreye almadan önce kurulur?#

Çünkü rezervasyon oluşturulduğu ana iliştirilirler. Segment kodu olmadan alınan bir rezervasyona sonradan kod verilemez; veri gecikmez, kaybolur.

İki ayrı alan tutun. Pazar segmenti misafirin kim olduğunu anlatır: bireysel, kurumsal, grup gibi. Kaynak, rezervasyonun nasıl geldiğini anlatır: direkt, acente, tur operatörü veya rezervasyonsuz gelen misafir (walk-in) gibi. İkisini tek listede birleştirmek iki raporu birden yok eder: hangi kanalın hangi tür misafiri getirdiğini göremezsiniz, oysa listenin var olma nedeni tam olarak bu sorudur.

Listeyi, rezervasyon görevlisinin birkaç saniyede seçebileceği kadar kısa tutun ve büyümesine izin vermek yerine her ay birinin gözden geçirdiği tek bir "diğer" kodu ekleyin. Seçimi rezervasyon ekranında zorunlu hale getirin, varsayılan koymayın; çünkü varsayılan bir kod, aceleye getirilen her rezervasyonu sessizce yutar ve veri gibi görünür. Her bağlı kanalı, kanal devreye girmeden önce tam olarak bir kaynak koduna eşleyin ki kanal rezervasyonları bilinmiyor olarak gelmesin.

Devreye alma sonrası ilk haftada kontrol edin: varsayılan veya "diğer" kodunda bekleyen rezervasyonları sayın. Yüksek bir sayıyı sistem sorunu değil, eğitim sorunu olarak ele alın. Segment listesinin tasarımının tamamı pazar segmentasyonu rehberinde var.

Kullanıcılar, roller ve belge şablonları: resepsiyonun ilk günü neye ihtiyaç duyar?#

Herkesin işini yapmasına izin veren en küçük role sahip, adı yazılı hesaplar ve misafirin gerçekten eline aldığı belgeler. İkisi de eğitim değil yapılandırmadır ve ikisi de genellikle son haftaya bırakılır.

Kişi başına bir hesap, asla ortak bir resepsiyon girişi değil. Sistemin kim ne yaptı kaydını tutmasının nedeni denetim izidir; ortak giriş bunu çöpe atar. Rolleri unvana değil göreve göre kurun, çünkü aynı unvana sahip iki kişi çoğu zaman farklı yetkilere ihtiyaç duyar ve unvana dayalı rol ya fazla geniş ya fazla dardır.

Hassas yetkileri az elde tutun: fiyat değişiklikleri, iptal ve ters kayıtlar, iadeler, gün sonu ve iş günü kapanışı. Her birini kimin tuttuğunu listeleyin ve ilk aydan sonra gözden geçirin. Otelin gerçekten düzenlediği belge şablonlarını hazırlayın; yasal ayrıntıları ve misafir profilinin gerektirdiği dil seçeneklerini içersin ve her birini test ortamında gerçek bir belge üreterek deneyin.

Devreye almadan önce, ayrılan personel ve sezonluk çalışanlar için devre dışı bırakma rutinini karara bağlayın ki erişim, istihdamdan uzun yaşamasın. Yetkilerin daha geniş bir ele alınışı kullanıcı yetkileri kontrol listesinde var.

Yapılandırmanın bittiğini nasıl anlarsınız?#

Her ilgili departman kendi tablosunu imzaladığında ve rezervasyondan gün sonuna, muhasebe aktarımına uzanan tam bir test haftası uçtan uca koştuğunda. Test haftası olmayan imzalı bir tablo bir niyettir, bir sonuç değil.

Dört sütunlu bir imza sayfası tutun: tablo, sahip departman, tarih ve sürüm. İmzası olmayan tablo, proje planı ne derse desin hâlâ açıktır. Test haftasını tüm zincir üzerinde koşurun: birkaç fiyat kodunda rezervasyonlar, her gelir kodunda harcamalar, her yöntemden bir ödeme, bir gün sonu ve muhasebecinin beklentisiyle karşılaştırılan bir muhasebe aktarımı.

Test haftası boyunca yapılandırmayı dondurun ve her değişikliği günlüğe yazın, çünkü hareket eden bir yapılandırma test sonucunu anlamsızlaştırır. Önceden karara bağlayın: neler devreye alma sonrasına kalabilir, örneğin yeni paketler, ek raporlar ve türetilmiş fiyatlar; neler kalamaz, örneğin oda tipleri, gelir kodları ve segment listesi.

İmzalı sayfaları ve yapılandırma günlüğünü eğitimi yürütecek kişiye teslim edin ki eğitmen, tedarikçinin demo verisini değil, otelin gerçekten kurduğu sistemi anlatsın. İlk gözden geçirmeyi devreye alma sonrası yaklaşık bir ay sonrasına planlayın: raporları okuyun, varsayılan kodlardaki rezervasyonları sayın ve listenin etrafından dolaşmak yerine listeyi düzeltin.

Şimdi ne yapmalı#

Bağımlılık sırasını tek bir sayfaya yazın ve her tablonun sahibini adıyla belirleyin; sonra tabloları bu sırayla doldurun ve bir önceki imzalanmadan bir sonrakine geçmeyi reddedin. Odalar neyin satılabileceğini, fiyatlar hangi bedelle, para kodları muhasebeye nasıl ulaştığını, segment ve kaynak kodları sonradan neyi öğrenebileceğinizi, kullanıcılar ve belgeler ise resepsiyonun ilk sabah çalışıp çalışamayacağını belirler. Veri taşıma ve geçiş gecesi bunun ardından gelir, bunun yerine geçmez.