Yeni bir sistemi PMS’e bağlamadan önce: entegrasyon test listesi

PMS entegrasyon testi, yeni bir sistemin otelinizin otel yönetim sistemiyle (PMS) canlı veri alışverişine girmeden önce yapılacak kabul işidir. Dört şeyi denetler: her mesajın yönü ve zamanlaması, iki taraftaki kod eşleştirmeleri, bağlantının kötü günlerde nasıl davrandığı ve kabulü kimin imzaladığı.

Satıcı arayüzün bittiğini söyler. Üç hafta sonra ay sonu bakiyesi tutmaz ve hangi sistemin harcamayı taşıdığını kimse söyleyemez. Sorun nadiren yazılımdadır; asıl eksik, kimsenin yazıya dökmediği kabul işidir. Bu yazının sonunda yapılandırılmış bir PMS entegrasyon testini yürütebilirsiniz: koşulları kâğıda geçirmek, kodları eşleştirmek, on senaryoyu çalıştırmak, başarısız mesajın akıbetini tanımlamak ve üç yerden imza almak.

PMS entegrasyon testi nedir ve gerçekte neyi denetler?#

Yeni bir sistemin PMS’nizle canlı veri alışverişine girip giremeyeceğine karar veren kabul işidir. Demo ekranlarını değil, mesajları denetler.

Bir entegrasyon, iki sistemin mesaj alışverişidir. Her mesajın bir yönü (kim gönderir), bir tetikleyicisi (ne zaman gider), bir biçimi (hangi alanları taşır) ve bir sahibi (kim sorumludur) vardır. Test etmek, yeni bağlantının taşıyacağı her mesaj için bu dört özelliği kanıtlamaktır.

“Bağlantı çalışıyor” ile “veri doğru”yu ayırın. Bir bağlantı hızlı bir denemeden geçebilir ve yine de yanlış tutarı yanlış hesaba işleyebilir. Teste başlamadan üç hata sınıfını adlandırın, çünkü her biri farklı bir senaryoya gereksinim duyar.

Testi, satıcının demo tesisinde değil, gerçekçi veriyle canlı sistemin bir kopyasında çalıştırın; böylece kendi oda tipleriniz, vergileriniz ve departmanlarınız devreye girer. Kabul ölçütlerini ilk testten önce yazın; ölçüt yoksa “çalışıyor” bir görüş olur ve tartışma faturaya taşınır. Testi satıcı yürütmüş olsa bile sahibi oteldir: tarafınızda biri, neyin test edildiğini ve neyin atlandığını söyleyebilmelidir.

İlk testten önce kâğıda ne geçirmelisiniz?#

Her mesaj için dört şey: yön, alanlar, zamanlama ve sahip. Dördünden biri eksikse test başarısız olamaz; sadece tartışır.

Yön, her alan için hangi sistemin doğruluk kaynağı olduğunu yazmaktır. Bir fiyatın, bir misafir adının ve bir hesap toplamının kaynağı farklı olabilir; yazılı olduğu sürece bu sorun değildir. Alanlar, tam olarak neyin gönderildiğini ve bilinçli olarak neyin gönderilmediğini listelemektir: misafir notları ya da kimlik belgesi ayrıntıları gibi, yanına gerekçesi yazılarak.

Zamanlama, mesajın anında mı, sabit saatte bir toplu işle mi yoksa biri bir düğmeye bastığında mı gittiğini ve hangi gecikmenin arıza sayılacağını belirtmektir. Sahip, bir alan yanlış olduğunda kimin sorumlu olduğunu ve canlıya geçişten sonra eşleştirmeyi kimin değiştirebileceğini adlandırmaktır. İki kişinin değiştirdiği bir eşleştirme, kimsenin denetlemediği bir eşleştirmedir.

Anlaşmayı sözleşmenin tarihli bir ekine koyun. Sözlü anlaşan kişi bir gün gidecektir; kalacak olan ektir. Kısa bir “asla” listesi ekleyin: yeni sistem PMS’de kendi başına asla değiştirmemeli, örneğin kapanmış bir hesabı ya da geçmiş bir iş gününü.

İki taraftaki eşleştirmeyi nasıl denetlersiniz?#

Ekranları değil, kod listelerini karşılaştırırsınız. Bir sistemdeki her kodun diğerinde adı yazılı bir karşılığı olmalı ve o karşılık test edilmelidir.

Üç sütunlu tek bir tablo kurun: gönderen sistemdeki kod, alıcı sistemdeki kod, test edildi mi. Üçüncü sütun dolmadan hiçbir şey bitmiş sayılmaz. Ay sonunda en çok iş çıkaran aileleri kapsayın: oda tipleri, fiyat planları, vergi oranları, ödeme türleri, gelir departmanları ve muhasebe hesapları.

Eşit görünen ama eşit olmayan kodlara dikkat edin. Tek bir “standart” koduna eşlenen iki oda tipi, doğru görünen bir hesap ve yanlış bir gelir dağılımı üretir. Bire-çoğa da dikkat edin: tek bir restoran departmanı iki muhasebe hesabına bölünmek zorunda kalabilir ve bölme kuralı varsayılmamalı, yazılmalıdır.

Bilerek zor bir vakayla test edin: bir indirim, bölünmüş bir hesap, sıfır tutarlı bir harcama, diğer sistemin kabul etmeyeceği karakterler içeren bir misafir adı. Tabloyu canlıya geçişten sonra da saklayın; altı ay sonra bir sayı yanlış göründüğünde ihtiyaç duyulan ilk belge odur. Bu bağlantıların mesajları nasıl taşıdığının arka planı için PMS entegrasyonu nasıl çalışır? API’yi sade bir dille anlamak yazısına bakın.

Canlıya geçmeden önce hangi senaryolar geçmelidir?#

Normal günler ve kötü günler. Temiz bir rezervasyon bağlantının var olduğunu kanıtlar; aşağıdaki on senaryo güvenilir olduğunu kanıtlar.

Her senaryoyu aynı anda iki sistemi de izleyen gerçek bir kişiyle çalıştırın ve sonucu tarih ve adla kaydedin. En az bir senaryoyu gün sonu işleminden geçecek şekilde kurun, çünkü mesaj yoldayken gün değişimi, tarih mantığının kırıldığı yerdir. Bilerek en az bir yinelenen mesaj gönderin; alıcı sistem, daha önce işlediği bir mesajı tanıyor mu, görün. Ağın kapalı olduğu bir senaryo ekleyin; gönderen sistem, teslim edemediği mesajla ne yapıyor, görün.

Kanal ya da dağıtım bağlantısında son madde en önemlisidir: tek yönü değil, gidiş dönüşü denetleyin. Bir kanal bağlantısının mesajları, gecikmeleri ve hataları nasıl ele aldığı kanal yöneticisi entegrasyonu nasıl çalışır? İki yönlü bağlantı, gecikme ve hatalar yazısında anlatılıyor.

Bir mesaj gelmediğinde ne olmalıdır?#

Görünür olmalı, belli bir sınıra kadar yeniden denenmeli ve adı yazılı bir kişiye ait olmalıdır. Sessizce kaybolan bir mesaj, en pahalı arıza türüdür.

Sınırlı yeniden deneme yapın, sonra mesajı bir kişinin görebileceği bir yere koyun. Sessizce kaybetmek ve sonsuza dek yeniden denemek, ters yönlerde olmak üzere ikisi de hatadır. Alıcı tarafta yinelenen mesaj koruması isteyin ki yeniden denenen bir mesaj, misafir hesabına ikinci bir harcama olarak dönmesin.

Bağlantı bir tam ay sonu kapanışında kendini kanıtlayana dek, iki taraftaki sayı ve toplamların günlük mutabakatını bir kişi yapsın. Uyarıları bir kişiye değil, bir role yönlendirin: saat 02:00’de kime telefon edilir, saat 10:00’da kime. Gece görevlisi, sabahın üçünde bir arayüzde hata ayıklayamaz.

Yazılı bir manuel yedek yöntem anlaşın ve personele öğretin: harcamayı elle hesaba işleyin, gerekçesini not edin ve bağlantı döndüğünde mutabakata bağlayın. Mesaj günlüğünü bir ay sonu kapanışını kapsayacak uzunlukta tutun ki dördüncü haftada sorulan bir soru hâlâ yanıtlanabilsin. Satıcıdan yanıt süreleri konusunda ne isteyeceğiniz SLA nedir? Otel yazılımı destek sözleşmelerindeki terimler: yanıt süresi, RTO ve RPO yazısında yer alıyor.

Kim imzalar ve ne zaman yeniden bakılır?#

Üç imza ve bir gözden geçirme tarihi. Ön büro misafir tarafındaki doğruluğu, muhasebe paranın doğruluğunu, bilişim işletimsel doğruluğu onaylar.

Satıcı teknik föyü imzalar; otel kabul belgesini. Bunlar farklı belgelerdir ve tek belgede birleştirilmemelidir. Kabul belgesi, tarih ve adlarla neyin test edildiğini ve eşit ölçüde neyin test edilmediğini, dolayısıyla kimsenin sözünün kapsamadığını listeler.

İlk ay sonu kapanışından sonra bir gözden geçirme tarihi saptayın ve sakin bir haftanın sakladığını hacmin ortaya çıkardığı ilk yüksek sezondan sonra ikincisini. Her iki taraftaki sürüm değişikliğinden önce haber ve değişenlerin sürüm notu diliyle değil düz bir dille yazılı dökümünü isteyin. Paraya ve tarihe dokunan beş altı senaryoluk kısa bir regresyon listesi tutun ve her güncellemeden sonra yeniden çalıştırın. Canlıya geçişten sonra eşleştirme değişikliğini kimin onaylayabileceğini kaydedin; o ad olmazsa entegrasyon, onu tanımlayan belgeden yavaş yavaş uzaklaşır. Para tarafını düzgün denetlemek için otel programından muhasebe programına: gün sonunda ne aktarılır, nasıl kontrol edilir? yazısına bakın.

Şimdi ne yapmalı#

Test randevusu almadan önce, her mesaj için dört satırlık anlaşmayı yazın: yön, alanlar, zamanlama, sahip. Liste ancak kâğıt önce varsa işler, çünkü bir test ancak yapılmış bir anlaşmayı doğrulayabilir. Sonra on senaryoyu çalıştırın, üç yerden imzalayın ve gözden geçirme tarihini ay sonu kapanışının yanına takvime yazın.