Bir PMS veya otel teknoloji sağlayıcısı seçmek, yalnız ekranları ve fiyat tekliflerini karşılaştırmak değildir. Seçilen hizmet rezervasyon, folyo, ödeme, oda durumu, kimlik verisi, kanal bağlantıları ve raporlar gibi kritik süreçlerin ortasına yerleşir. Bu nedenle karar; ürün demosundan önce iş kapsamını, güvenlik kanıtlarını, hizmet seviyesini, entegrasyon davranışını, veri taşınabilirliğini ve sözleşme bittiğinde çıkış yolunu birlikte değerlendirmelidir. İyi bir tedarikçi değerlendirmesi, satış sunumundaki vaatleri ölçülebilir gereksinimlere ve doğrulanabilir kanıtlara dönüştürür.

What you will learn in this article
  • Tedarikçi değerlendirmesi ürün özelliklerinden değil, otelin kritik iş süreçleri, veri akışları ve kabul edilebilir kesinti sınırlarından başlamalıdır.
  • Sertifika veya genel güvenlik beyanı tek başına yeterli değildir; kapsam, tarih, istisna, olay bildirimi ve alt hizmet sağlayıcılar doğrulanmalıdır.
  • Sözleşme imzalanmadan önce veri dışa aktarma biçimi, süreleri, maliyeti, silme kanıtı ve alternatif sisteme geçiş provası tanımlanmalıdır.

Start with the hotel’s critical business processes

İlk adım, ürün listesi hazırlamak değil hizmetin otelde hangi işi taşıyacağını yazmaktır. Rezervasyon alma, oda atama, check-in, folyo, tahsilat, e-belge, kanal envanteri, misafir mesajı, kimlik bildirimi ve yönetim raporu için iş sahibi belirlenmelidir. Her süreçte hangi kullanıcıların çalıştığı, hangi verinin işlendiği, hangi dış sistemlerin devreye girdiği ve hizmet durduğunda operasyonun ne kadar süre devam edebileceği kaydedilmelidir. Böylece değerlendirme, yüzlerce genel özellik yerine tesise özgü kritik senaryolara odaklanır.

Aday sistemler aynı senaryo setiyle test edilmelidir. Örneğin değişen fiyatlı çok geceli rezervasyon, kısmi ödeme, oda değişikliği, erken çıkış, iptal edilen fatura, çevrim dışı çalışma ve gün sonu geri alma gibi gerçek akışlar demo ortamında yürütülmelidir. Başarı yalnız işlemin tamamlanması değildir; yetki kontrolü, log, finansal toplam, entegrasyon sonucu ve hata sonrasında geri dönüş de izlenmelidir. Satış sunumunda var denilen işlevin hangi paket, ülke, para birimi ve entegrasyonda geçerli olduğu yazılı olarak teyit edilmelidir.

  • Kritik süreçler, veri türleri, bağımlılıklar ve iş sahipleri tek envanterde toplandı.
  • Kesinti etkisi ve manuel çalışma sınırı her süreç için ayrı belirlendi.
  • Adaylar aynı gerçek otel senaryoları ve aynı başarı ölçütleriyle test edildi.
  • Paket, ülke, para birimi ve entegrasyon kısıtları teklif ekinde doğrulandı.

Make data roles, flows and subprocessors visible

PMS'te ad, iletişim, kimlik, konaklama, folyo, ödeme referansı, kullanıcı ve işlem geçmişi gibi farklı nitelikte veriler bulunabilir. Hangi verinin hangi amaçla işlendiği, nerede barındırıldığı, hangi ülkelere aktarıldığı, ne kadar tutulduğu ve kimlerle paylaşıldığı veri akışında gösterilmelidir. Otelin ve sağlayıcının veri sorumlusu ya da veri işleyen rolü somut işlem bazında değerlendirilmelidir; sözleşmedeki genel bir cümle bütün işleme faaliyetlerini açıklamaz.

KVKK'nın veri güvenliği açıklamasına göre veri sorumlusu, kendi adına veri işleyen tarafla birlikte gerekli tedbirlerin alınması konusunda müştereken sorumludur ve gerekli denetimleri yapmak veya yaptırmak zorundadır. Bu nedenle bulut altyapısı, e-posta, destek, analitik, çağrı merkezi, ödeme, yedekleme ve entegrasyon hizmeti veren alt sağlayıcılar listelenmelidir. Yeni alt sağlayıcı eklenmeden önce bildirim, itiraz ve risk değerlendirme yolu sözleşmede tanımlanmalı; verinin silinmesi ve aktarım sonrası korunması zincirin tamamını kapsamalıdır.

  • Kişisel veri türleri, amaç, hukuki dayanak, konum, alıcı ve saklama süresi eşleştirildi.
  • Otel ve sağlayıcının rolleri her işleme faaliyeti için ayrı değerlendirildi.
  • Bulut, destek, analitik, ödeme ve entegrasyon alt sağlayıcıları açıklandı.
  • Alt sağlayıcı değişikliği için bildirim, değerlendirme ve çıkış hakkı yazıldı.

Ask for verifiable evidence instead of security claims

Güvenli, şifreli veya standartlara uygun ifadeleri tek başına ölçülebilir değildir. CISA'nın Secure by Demand rehberi, yazılım müşterilerinin güvenliği satın alma sürecinde açıkça talep etmesini ve üreticinin güvenli tasarım yaklaşımını sorgulamasını önerir. Değerlendirme; çok faktörlü kimlik doğrulama, görev bazlı yetki, ayrı yönetici hesabı, aktarımda ve depoda şifreleme, olay logları, güvenlik açığı yönetimi, güncelleme süresi, güvenli geliştirme ve destek erişiminin kontrolü gibi somut başlıklara ayrılmalıdır.

Bağımsız denetim veya sertifika sunuluyorsa adı kadar kapsamı da incelenmelidir: hangi ürün, şirket, veri merkezi, dönem ve kontroller dahil; önemli istisna var mı; raporun tarihi nedir? Sızma testi özeti, kritik bulguların kapatılma kanıtı ve güvenlik açığı bildirim kanalı istenebilir. Tedarikçi gizlilik gerekçesiyle ham raporu paylaşamıyorsa kontrollü inceleme, denetçi görüşü veya kapsam özeti sunmalıdır. Kanıtların yenilenme sıklığı ve geçerlilik sahibi değerlendirme tablosunda kayıtlı olmalıdır.

  • MFA, yetki, şifreleme, log, yama ve destek erişimi ölçülebilir gereksinimlere çevrildi.
  • Sertifika ve denetim raporlarının ürün, dönem, konum ve kontrol kapsamı doğrulandı.
  • Kritik güvenlik bulgularının kapatılması ve yeniden test kanıtı istendi.
  • Güvenlik kanıtlarının sahibi, son tarihi ve yenileme takvimi kaydedildi.

Define the SLA beyond an uptime percentage

Hizmet seviyesi sözleşmesi yalnız aylık erişilebilirlik yüzdesi içerdiğinde otelin gerçek riskini açıklamaz. Ölçümün hangi uçtan yapıldığı, planlı bakımın nasıl sayıldığı, kısmi işlev kaybının kesinti kabul edilip edilmediği ve raporun müşteriye nasıl verildiği belirtilmelidir. Rezervasyon arama çalışırken folyo veya kanal güncellemesi durmuşsa hizmet teknik olarak açık görünse bile operasyon kritik ölçüde etkilenebilir. Bu nedenle kritik işlevler için ayrı hizmet göstergeleri gerekebilir.

Destek saatleri, dil, iletişim kanalı, önem seviyeleri, ilk yanıt, geçici çözüm, kalıcı çözüm ve yöneticiye yükseltme süreleri açık olmalıdır. Kurtarma süresi hedefi ile kabul edilebilir veri kaybı hedefi ayrıca yazılmalı ve test sonucu talep edilmelidir. Planlı bakım bildirim süresi, yoğun tarihlerde bakım kısıtı ve durum sayfası da değerlendirmeye girer. Hizmet kredisi zararı bütünüyle karşılamaz; tekrarlayan ihlal durumunda düzeltme planı, bağımsız inceleme ve cezasız çıkış gibi haklar daha işlevsel olabilir.

  • Erişilebilirlik ölçüm noktası, hariç tutmalar ve kritik işlevler açıkça tanımlandı.
  • Önem seviyesine göre yanıt, geçici çözüm, kalıcı çözüm ve yükseltme süreleri yazıldı.
  • Kurtarma süresi ile veri kaybı hedefleri test kanıtlarıyla birlikte istendi.
  • Tekrarlayan SLA ihlali için düzeltme, denetim ve çıkış hakları belirlendi.

Do not approve integrations merely because a connection exists

Kanal yöneticisi, ödeme, e-belge, muhasebe, kilit, POS ve kimlik bildirimi bağlantıları PMS seçiminin görünmeyen maliyetini oluşturabilir. Her entegrasyon için veri sahibi, yön, sıklık, benzersiz kimlik, hata kuyruğu, yeniden deneme, mükerrer kayıt önleme ve mutabakat yöntemi belgelenmelidir. Sertifikalı entegrasyon ifadesi, bütün alanların ve bütün senaryoların desteklendiği anlamına gelmeyebilir; oda değişikliği, kısmi iade, vergi ayrımı ve geçmiş tarih düzeltmesi gibi zor durumlar ayrıca test edilmelidir.

API kullanılıyorsa sürümleme, kullanım sınırı, değişiklik bildirimi, geriye dönük uyumluluk, test ortamı, erişim anahtarı yönetimi ve log erişimi sözleşmede yer almalıdır. Sağlayıcının tek taraflı alan veya uç nokta değişikliği otelin operasyonunu durdurmamalıdır. Pilot aşamada bağlantı kesintisi, geç gelen mesaj, tekrarlanan bildirim ve hatalı kur senaryoları uygulanmalı; hangi tarafın düzeltme ve veri uzlaştırma sorumluluğunu aldığı yazılı hale getirilmelidir.

  • Her entegrasyonun veri yönü, hata kuyruğu, yeniden deneme ve mutabakatı belgelendi.
  • Zor operasyon senaryoları test verisiyle uçtan uca doğrulandı.
  • API sürümleme, değişiklik bildirimi, test ortamı ve kullanım sınırı tanımlandı.
  • Kesinti ve mükerrer kayıt durumunda sorumluluk ile düzeltme akışı yazıldı.

Test data portability and the exit plan before signing

Bir sistemden çıkış, sözleşmenin son günü başlayan proje olmamalıdır. Otelin kendi verisini hangi biçimde, ne kadar sürede ve hangi maliyetle alabileceği satın alma aşamasında belirlenmelidir. Dışa aktarma yalnız misafir ve rezervasyon tablosunu değil; folyo hareketleri, ödemeler, faturalar, oda durumu geçmişi, fiyat ve vergi kuralları, şirket hesapları, notlar, belgeler, kullanıcı ve denetim kayıtları gibi gerekli bağları da kapsayabilir. Dosya biçimi açık, makinece okunabilir ve alan sözlüğüyle birlikte olmalıdır.

Aday tedarikçiden örnek veri paketi alınarak alternatif sisteme veya doğrulama ortamına aktarım provası yapılmalıdır. Kayıt sayıları, finansal toplamlar, bağlantılar, karakterler, tarih ve para birimi alanları kontrol edilmelidir. Sözleşme sona erdiğinde dışa aktarma penceresi, geçiş desteği, salt okunur erişim, veri silme süresi, yedeklerdeki imha takvimi ve yazılı silme kanıtı tanımlanmalıdır. Sağlayıcı bağımlılığını azaltan unsur yalnız API değil, düzenli test edilmiş çıkış kabiliyetidir.

  • Dışa aktarılacak tablolar, belgeler, loglar ve ilişkiler ayrıntılı listelendi.
  • Biçim, alan sözlüğü, teslim süresi, maliyet ve destek koşulları yazıldı.
  • Örnek veri paketiyle aktarım ve finansal mutabakat provası yapıldı.
  • Sözleşme sonunda erişim, silme, yedek imhası ve kanıt takvimi belirlendi.

Put incident notice, support access and logs into the contract

Güvenlik veya veri olayı sırasında otelin karar verebilmesi için hızlı ve anlamlı bilgi gerekir. Sözleşme; olayın hangi anda bildirileceğini, ilk bildirimin hangi bilgileri içereceğini, güncelleme sıklığını, delillerin korunmasını, kök neden raporunu ve düzeltici faaliyetleri açıklamalıdır. Yalnız kesin ihlal doğrulandıktan sonra bildirim yapılması, otelin kendi yükümlülüklerini değerlendirmesi için geç olabilir. Bildirim kanalı, yedek irtibat ve mesai dışı yöntem önceden test edilmelidir.

Tedarikçi destek personelinin üretim verisine erişimi kalıcı ve görünmez olmamalıdır. Talep numarası, gerekçe, onay, süreli yetki, yapılan işlem ve kapanış kaydı tutulmalıdır. Uzak oturumlar mümkün olduğunda denetlenmeli; ortak hesap yerine kişisel hesap kullanılmalıdır. Otel, kendi kullanıcılarının ve tedarikçi erişimlerinin gerekli loglarını makul süreyle görebilmeli veya dışa aktarabilmelidir. Logların saat senkronizasyonu, bütünlüğü ve olay sonrasında teslim süresi sözleşmede açıklanmalıdır.

  • Olay tanımı, ilk bildirim süresi, güncelleme sıklığı ve rapor içeriği belirlendi.
  • Mesai dışı olay irtibatı ve yedek iletişim kanalı test edildi.
  • Destek erişimi talep, onay, süre, kişisel hesap ve işlem kaydıyla sınırlandı.
  • Log erişimi, bütünlük, saat eşitleme, saklama ve teslim süresi tanımlandı.

Continue managing the vendor after selection

İlk değerlendirme, ürün ve risk değiştikçe güncelliğini kaybeder. NIST CSF 2.0'ın tedarik zinciri yaklaşımı, tedarikçi gereksinimlerinin tanımlanmasını ve yaşam döngüsü boyunca izlenmesini destekler. Otel; iş sahibi, teknik sahip, KVKK sorumlusu ve sözleşme sahibini belirlemeli; kritik tedarikçiler için en az yıllık kapsamlı, daha sık operasyonel gözden geçirme yapmalıdır. SLA raporu, olaylar, alt sağlayıcı değişiklikleri, güvenlik kanıtları, yetkiler, entegrasyon hataları ve veri dışa aktarma başarısı aynı kayıt üzerinden izlenmelidir.

Çeyreklik değerlendirmede açık riskler, yaklaşan sertifika tarihleri, tekrarlayan destek sorunları, kullanılmayan hesaplar, ayrıcalıklı erişimler ve sözleşme değişiklikleri ele alınabilir. Yıllık tatbikatta kesinti iletişimi, çevrim dışı çalışma, örnek veri dışa aktarma ve kurtarma kanıtı sınanmalıdır. Risk kabulü gerekiyorsa süre, iş gerekçesi, onaylayan kişi ve telafi edici kontrol yazılmalıdır. Böylece tedarikçi yönetimi dosyada kalan bir satın alma kontrolü değil, otelin iş sürekliliği ve veri yönetişiminin yaşayan parçası olur.

  • İş, teknik, KVKK ve sözleşme sahipleri ile gözden geçirme takvimi belirlendi.
  • SLA, olay, alt sağlayıcı, kanıt, yetki ve entegrasyon bulguları tek kayıtta izlendi.
  • Kesinti, veri dışa aktarma ve kurtarma senaryoları düzenli tatbik edildi.
  • Risk kabulleri süreli, gerekçeli, onaylı ve telafi edici kontrollü tutuldu.
Short answers

FAQ

What should a hotel examine first when selecting a PMS vendor?

İlk konu özellik listesi değil, otelin kritik iş süreçleri ve veri akışlarıdır. Rezervasyon, folyo, ödeme, oda durumu, kanal ve rapor gibi süreçlerde kesinti etkisi ve başarı ölçütleri belirlendikten sonra adaylar aynı gerçek senaryolarla karşılaştırılmalıdır.

Does a security certificate prove that a vendor is secure?

Tek başına kanıtlamaz. Sertifikanın hangi ürün, şirket, veri merkezi, dönem ve kontrolleri kapsadığı; istisnaları ve güncelliği incelenmelidir. MFA, erişim, log, yama, olay bildirimi ve alt sağlayıcılar için ayrıca somut kanıt istenmelidir.

How should data portability be defined in a PMS contract?

Dışa aktarılacak veri ve belgeler, açık dosya biçimi, alan sözlüğü, teslim süresi, maliyet, geçiş desteği, salt okunur erişim, silme süresi ve silme kanıtı yazılmalıdır. İmzadan önce örnek veri paketiyle aktarım ve finansal mutabakat provası yapılmalıdır.

Sources and updates

Operational recommendations should be adapted to each property. Information about PMS and channel operations was checked against the official sources below on September 30, 2026.