PMS değiştirirken veri taşıma: neler aktarılır, neler geride kalır?

PMS veri taşıma, otelin canlı kayıtlarının, gelecek rezervasyonların, ön ödemelerin, açık hesapların, kontenjanların, grup bloklarının ve fiyat planlarının eski sistemden yeniye planlı biçimde aktarılmasıdır; bir de neyin denetim için salt okunur kalacağına ve neyin silineceğine dair karardır. Provayı yapın, sayıları ve bakiyeleri mutabakata bağlayın, sonra geçin.

Geçişten iki hafta önce birisi sorar: yeni sistemdeki ön ödemeler bankadakiyle tutuyor mu? Odadaki kimsenin elinde o sayı yoktur. Yeterince erken sorulduğunda bu tek soru, tüm taşıma projesinin kendisidir. Bu yazı verilerinizi ayıracağınız kovaları, eşleştireceğiniz kodları, geçiş öncesi koşacağınız testleri ve imza atmadan önce yazılım firmasına sormanız gereken soruları verir.

PMS veri taşıma nedir, ne değildir?#

Tanımlı bir kayıt kümesinin yeni sisteme planlı aktarımı ve geride neyin kalacağına dair açık karardır. Eski veritabanının kopyalanması değildir.

PMS (otel yönetim sistemi; rezervasyonları, resepsiyonu, hesapları ve raporları tutan yazılım) çok farklı ömürlerde kayıt saklar. Bir rezervasyonun geleceği vardır. Kapanmış bir misafir hesabının geçmişi. Bir misafir profilinin ikisi de yoktur; ta ki biri ona bir amaç atayana kadar. Taşıma, seçme ve çevirmedir, yedekleme değil: yeni sistem odaları, fiyatları ve harcamaları farklı biçimde modeller, dolayısıyla her kayıt olduğu gibi bırakılmaz, yeni modelde yeniden ifade edilir. Arka plan için otel teknoloji altyapısındaki temel sistemlerin birbirine nasıl bağlandığına göz atabilirsiniz.

Her veri setini üç kovaya ayırın: taşınacak, salt okunur kalacak, geride bırakılacak. Bir kovaya koyamadığınız her şey, henüz vermediğiniz bir karardır. Her veri setine tek bir sahip verin: bakiyelerin, faturaların ve şehir hesabının sahibi mali işlerdir; blokların ve kontenjanların sahibi rezervasyon; fiyat planlarının sahibi gelir yönetimi; kişisel veriyle ilgili her kararın sahibi ise veri sorumlusu olarak otelin kendisidir.

Eski sistem geçiş gününde kapanmaz. Belirli bir süre için, kısıtlı erişimli ve yeni kayıt alınmayan salt okunur bir arşive dönüşür. Envanteri, yazılım firmalarıyla konuşmadan önce yazın: envanter hem kapsam belgesi olur, hem kabul testi, hem de daha sonra bir değişiklik talebine "hayır" diyebilmenizin gerekçesi. Envanterin rahatsız edici olacağını öngörün. Otelin elinde gerçekte ne olduğunu ilk kez biri listeliyor olacak.

Yeni PMS'ye hangi veriler taşınmalı?#

Geçiş tarihinden sonra hâlâ etkisi olan her şey: gelecek rezervasyonlar, ön ödemeler, açık hesaplar, kontenjanlar, grup blokları ve fiyat planları. Yalnızca geçmişi olan ne varsa yerinde kalır.

Gelecek rezervasyon demek, geçişten sonra varışı olan her rezervasyon demektir; her kanaldan ve misafirin elindeki onay numarasıyla birlikte. İlk sabah arayan misafir, kendisine verilen numaradan bulunabilmelidir. Ön ödemeler ve avanslar, rezervasyona bağlı bir borç kalemi olarak taşınır; asla varış tarihinde alınmış bir ödeme olarak girilmez. Bunları yeni ödeme gibi yeniden girmek, banka mutabakatını ve misafirin hesabını aynı anda bozar.

Açık hesaplar, bugüne kadarki harcamalarıyla gelir; böylece çıkış (check-out) hesabı yeniden başlatmak yerine sürdürür. Sıfır gelen ve sonra hesabına yeniden harcama işlenen bir hesap, mükerrer bir harcama demektir. Grup blokları ve kontenjanlar bırakma tarihleri, bloktan alınan oda sayıları ve sözleşme referansıyla gelir: bırakma tarihi olmadan gelen bir blok ya odaları sonsuza dek tutar ya da erken bırakır, ikisi de para kaybettirir. Fiyat planları içeriğiyle, iptal koşullarıyla, minimum konaklamayla ve muhasebeleştikleri pazar segmenti ve rezervasyon kaynağıyla gelir; muhasebe kodu olmayan bir fiyat planı, kimsenin okuyamadığı bir aylık rapor üretir. Şehir hesabı ve kurumsal alacaklar da açık bakiyeleri ve dayandıkları fatura referanslarıyla taşınır.

Taşınmayanlar: kapanmış dönemler, geçmiş misafir hesapları, kesilmiş faturalar ve eski günlük misafir listeleri. Bunlar kaybolmaz, arşivlenir; nedenini bir sonraki bölüm açıklar.

Sistemi hâlâ seçiyorsanız, bunlar aynı zamanda yazılım firmasına imzadan önce sorulacak sorulardır.

Eski kodlar yeniye nasıl eşlenir?#

Yazılı bir eşleştirme tablosu kurun: eski sistemdeki her oda tipi, fiyat kodu, pazar segmenti, rezervasyon kaynağı, satış noktası ve ödeme tipi, yeni sistemde adı konmuş bir karşılık ya da açık bir "emekliye ayrıldı" kararı alır.

İki sistem nadiren aynı taneli yapıdadır. Eski bir oda tipi yeni sistemde ikiye bölünebilir; iki eski fiyat kodu birleşebilir. Bölmeler güvenlidir; sessiz birleştirmeler, taşıdığınız raporlama geçmişini siler. Pazar segmenti ve rezervasyon kaynağı kodları her kanal ve üretim raporunu besler; gevşek eşlerseniz ilk ayın sayıları kimsenin izini süramayacağı biçimde yanlış çıkar. Vergi kodlarını, ödeme tiplerini ve satış noktası tanımlarını tahminle değil, mali müşavirle eşleyin: bunlar geçişten sonra bir harcamanın mali belgede nasıl görüneceğini belirler.

İleride kullanımı olmayan kodları, hepsini bir "çeşitli" kovasına doldurmak yerine emekliye ayırın. O kova, kimsenin temizlemediği ve her raporun miras aldığı kalıcı bir çekmece olur. Eşleştirme tablosunu geçişten sonra da saklayın; bu yılın raporunun neden geçen yılkine benzemediğini açıklayan belge odur. Eşlemeyi, bilinen bir dönemlik eski veriyi içinden geçirip toplamları eski sistemin aynı dönem raporuyla karşılaştırarak sınayın. Projenin tamamı için tek kural: yazıya geçirilmedikçe ve biri imzalamadıkça eşleme yoktur.

Örneğin, bir eşleştirme tablosu şöyle görünebilir:

Ne salt okunur kalır ve ne kadar süreyle?#

Kapanmış dönemler, kesilmiş faturalar, eski misafir hesapları ve günlük misafir listeleri, eski sistemde salt okunur arşiv olarak kalır; çünkü vergi ve ticaret mevzuatı otelden bunları saklamasını ve istendiğinde ibraz edebilmesini ister.

İki ayrı yükümlülük devreye girer. 213 sayılı Vergi Usul Kanunu (yeni sekmede açılır), konaklama yerlerinden oda numarasıyla birlikte müşterinin adını, soyadını ve oda ücretini gösteren günlük müşteri listesi düzenlenmesini (madde 240) ve defter tutanların defter ile belgelerini ilgili yılı izleyen takvim yılının başından itibaren beş yıl saklamasını (madde 253) şart koşar. 6102 sayılı Türk Ticaret Kanunu (yeni sekmede açılır) ise her tacirden ticari defterleri ve kayıtların dayandığı belgeleri on yıl saklamasını ister (madde 82). Süreler kayıt türüne göre farklıdır; otelinize uyanları mali müşavirinizle teyit edin.

Ticari kural yalnızca dosyayı saklamakla ilgili değildir. Belgeler görüntü ya da veri taşıyıcılarında tutulabilir; yeter ki okunur hâle getirildiklerinde asıllarıyla örtüşsünler, saklama süresi boyunca kayıtlara her an ulaşılabilsin ve uygun bir süre içinde okunabilir hâle getirilebilsinler. Çekmecedeki bir yedek bandı bu tanımı karşılamaz. Dolayısıyla eski sistem sorgulanabilir kalmalı ya da verisi, misafir adı, tarih veya oda numarasıyla aramanın hâlâ çalıştığı okunabilir ve dizinlenmiş bir biçime aktarılmalıdır.

Geçmeden önce arşivi sınayın: iki yıl önceki bir misafir hesabını ve kesilmiş bir faturayı seçin, eski sistemi yürüten kişiden yardım almadan bulun. Arşivi düzgün dondurun: yeni kayıt yok, adı belli salt okunur hesaplar, kimin neden bakabileceğini gösteren yazılı bir liste. Eski hesapları "her şey tek yerde olsun" diye yeni sisteme taşımayın; güncel raporları kirletir ve amacı olmayan bir sisteme kişisel veri ekler. Muhasebe ve e-belge sürekliliği ayrı bir konuşmadır: mali müşavirinizle ve e-belge entegratörünüzle, kapanış planında ele alınır; veri taşımada değil.

Hangi misafir profilleri taşınmalı?#

Yalnızca otelin belirtilmiş bir amaç için hâlâ ihtiyaç duyduğu ve tutmasına izin verilen kişisel veri taşınır. Gerisi istatistiğe özetlenir, amacı kalmayan silinir.

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), kişisel verilerin hukuka ve dürüstlük kurallarına uygun, doğru ve gerektiğinde güncel, belirli, açık ve meşru amaçlarla işlenmesini, amaca bağlı, sınırlı ve ölçülü tutulmasını ve mevzuatta öngörülen ya da amacın gerektirdiği süre kadar saklanmasını şart koşar (madde 4). İşlemeyi gerektiren sebepler ortadan kalktığında veri sorumlusu verileri kendiliğinden veya ilgili kişinin talebiyle siler, yok eder ya da anonim hâle getirir (madde 7). Taşıma, bu ilkelerin gerçekten sınandığı andır; çünkü taşıdığınız her kayıt, tutmayı seçtiğiniz bir kayıttır.

Gelir yönetiminin ve ön büronun eski geçmişten genellikle istediği şey toplamsaldır: pazar segmentine göre geceleme, aya göre ortalama fiyat, kaynağa göre tekrar oranı. Bu, adı olmadan özet istatistik olarak yolculuk edebilir ve bir profilin tutulduğu soruların çoğunu yanıtlar.

Kopyalamadan önce eski sistemin ne tuttuğunu inceleyin. Kişisel Verileri Koruma Kurulu, 06.11.2025 tarihli ve 2025/2120 sayılı İlke Kararı'nda (Resmî Gazete, 9 Aralık 2025, sayı 33102) misafirlerin ad, soyad ve T.C. kimlik numarasının kaydedilmesini ve kimlik belgesinin ibrazının istenmesini hukuka uygun bulmuş; belgenin fotokopisinin alınıp saklanmasını ise gereğinden fazla veri işleme saymıştır. Karara göre daha önce alınmış fotokopiler KVKK'nın 7. maddesine uygun olarak imha edilmelidir (Resmî Gazete, 9 Aralık 2025 (yeni sekmede açılır)). Eski sistemde taranmış kimlik belgeleri varsa, bu bir taşıma işi değil, silme işidir.

Silme ve anonimleştirme kayıt altına alınması gereken işlemlerdir; Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik (Resmî Gazete, 28 Ekim 2017) bu işlemlerin tamamının kayda geçmesini ve kayıtların en az üç yıl saklanmasını öngörür. Kişisel veri saklama ve imha politikası tutan veri sorumluları, politikada belirlenen ve hiçbir durumda altı ayı geçmeyen aralıklarla imha yapar. Otelinizin böyle bir politikaya ihtiyacı olup olmadığı yükümlülüklerinize bağlıdır; hukuk danışmanınızla teyit edin. Kurumun veri güvenliği rehberi de az erişilen arşiv verisinin daha güvenli ortamlarda tutulmasını ve güvenlik gereksinimlerinin yeni sistem tedarik kararının bir parçası olmasını önerir. İkisini de yazılım firması sorularına ekleyin. Bu yükümlülüklerin günlük yüzü için resepsiyonda misafir verisi taleplerinin nasıl yanıtlandığına bakın.

Veri taşınmadan önce nasıl temizlenir?#

Bir kopyada temizleyin, her birleştirmeyi yazıyla karara bağlayın ve neyi neden düşürdüğünüzün listesini tutun.

Yinelenen misafir profilleri en büyük tek temizliktir: aynı kişi, üç yazım, iki uyrukluk ve eski bir e-posta adresiyle. Hukuken elinizde varsa kararlı bir anahtar üzerinde, yoksa ad, doğum tarihi ve iletişim bilgisi üzerinde birleştirin ve her birleştirmeyi kayda geçirin. Kullanılmayan kodlar, iki yıldır kimsenin kullanmadığı fiyat kodları, tek bir kampanya için kurulmuş segmentler, kapanmış satış noktaları: bunları taşımak yerine emektiye ayırın; yoksa yeni sistem onları on yıl boyunca açılır menülerde sunmaya devam eder.

Bayat profiller, konaklaması, açık bakiyesi, rızası ve belirtilmiş amacı olmayanlar, bir önceki bölümdeki silme kararının konusudur; eşleştirme kararının değil. Yetim kayıtlar, rezervasyonsuz harcamalar, grupsuz bloklar, rezervasyonsuz depozitolar önce mali, sonra veri sorunudur; taşımadan sonra değil, önce mali müşavire gönderin. Test ve eğitim kayıtları asla geçmemelidir: ad örüntüsüyle ve tarihe göre bulunup kaynağında silinmelidir.

Eski sistem çalışmaya devam ederken temizliği bir hazırlık kopyasında yapın ki resepsiyon aksamasın. Kaynağın kendisini yalnızca eski sistem çoktan donmuşsa temizleyin. Düşürme listesini saklayın. Üçüncü ay birisi bir rezervasyonun neden eksik olduğunu sorduğunda cevap odur.

Taşımanın provası ve mutabakatı nasıl yapılır?#

En az bir tam deneme taşımasını test ortamına çalıştırın, sonra her fark açıklanana dek iki taraftaki sayıları ve bakiyeleri karşılaştırın.

Karşılaştırılacak sayılar: varış tarihine göre rezervasyonlar, aya göre geceleme, bloktan alınan oda sayısıyla grup blokları, bırakma tarihleriyle kontenjanlar, fiyat planları, açık hesaplar ve para birimine göre ön ödemeler. Karşılaştırılacak bakiyeler: açık hesaplar ve şehir hesabı kuruşu kuruşuna, ön ödemeler banka hesap özetiyle. Yakın olan bakiye, yanlış olan bakiyedir.

Her sayının imzalayan tek bir sahibi vardır. Bakiyeleri mali işler, blokları rezervasyon, fiyat planlarını gelir yönetimi imzalar. İmzasız sayı bir görüştür. Her farkı iki şeyden biri sayın: düzeltilecek bir eşleştirme hatası ya da hiç taşınmaması gereken bir kayıt. "Kabul edilebilir" diye üçüncü bir kategori yoktur.

Düzeltmelerden sonra provayı ikinci kez çalıştırın. İkinci koşu, sürecin şanslı değil, tekrarlanabilir olduğunu gösterendir. Provayı süre tutarak yapın: o süre, resepsiyonun eski sisteme yeni kayıt girişini ne zaman durduracağına karar verecek kapanış planının girdisidir. Gece yapılan son yükleme, dondurma penceresi ve geri dönüş kararı, sistem değiştirme gecesi için adım adım kapanış listesinin konusudur.

Şimdi ne yapmalı#

Bu hafta, bir sözleşme imzalamadan önce iki belgeyle başlayın: her kaydı sahibiyle birlikte taşınacak, salt okunur ya da geride bırakılacak kovasına yerleştiren bir veri envanteri ve eski kodlardan yenilere yazılı bir eşleştirme tablosu. Sistem değişiminin geri kalanı, prova, sayılar, bakiyeler ve gece, hangi kayıtların geleceği hangilerinin geçmişi olduğunu tam olarak bilmekten türer. Sistemi hâlâ seçiyorsanız, özellikleri sormadan önce yazılım firmasına taşıma ve mutabakat sürecini göstermesini isteyin.