PMS raporları yetmediğinde: veri aktarımı, panolar ve iş zekâsı araçları

Otel iş zekâsı, birkaç farklı sistemdeki veriyi tek ve tutarlı bir sayı dizisine dönüştüren katmandır. Hazır PMS raporları tesisler, sistemler veya dönemler arasındaki soruları yanıtlayamadığında bu katmana ihtiyaç duyarsınız. Yol genellikle zamanlanmış veri aktarımı ve tek bir tablo modelinden panoya, oradan veri ambarına doğru ilerler ve her adım ortak kodlara ve ortak tanımlara dayanır.

Ay sonu gelir ve biri dört ayrı tabloyu, iki PMS çıktısını ve restoran için elle tutulan bir dosyayı açar. Toplamlar birbirini tutmaz ve odadaki hiç kimse hangisinin doğru olduğunu söyleyemez. Bu yazı o oda ile güvenilir bir sayı dizisi arasındaki adımları anlatır: hazır raporların sınırını nasıl fark edeceğinizi, zamanlanmış aktarımı tek bir tablo modeline nasıl kuracağınızı, bir pano aracının ne eklediğini, veri ambarının ne olduğunu ve tüm bu adımların altında ne olması gerektiğini. Yazının sonunda işletmenizin gerçekte hangi adıma ihtiyacı olduğunu ve para harcamadan önce neyi düzeltmeniz gerektiğini değerlendirebileceksiniz.

Hazır PMS raporlarını ne zaman aştığınızı nasıl anlarsınız?#

En sık sorduğunuz sorular, PMS'nin tek bir yerde tutmadığı verilere ihtiyaç duyduğunda hazır raporları aşmışsınız demektir: ikinci bir tesis, restoran sistemi, kanal yöneticisi ya da üç yıllık geçmiş.

Hazır raporlar tanımlı bir iş için kurulmuştur: gün sonu, kat hizmetleri listesi, şehir defteri, varış listesi. O iş için tekrarlanabilir ve doğrudurlar ve sınırları tam olarak budur. Yanlış değillerdir; tamamlanmışlardır.

Sınırın en belirgin işareti yeniden veri girişidir. Biri her hafta ya da her ay PMS rakamlarını bir tabloya kopyalar ve zamanla o kopya, sahibin gerçekte okuduğu sayı hâline gelir. İkinci işaret uyuşmazlıktır: iki kişi aynı gösterge için farklı değer üretir, genellikle biri diğerinin dışladığı bir segmenti dahil ettiği için. Üçüncü işaret kapsamdır: iki tesisi tek sayfada göremezsiniz ya da sistemin yalnızca içinde bulunulan dönem için tuttuğu geçen yılın detayına ihtiyaç duyarsınız.

Bir sonuca varmadan önce raporlama eksiği ile tanım eksiğini ayırın. İki rapor farklı RevPAR veriyorsa yeni bir araç bunu çözmez; yazılı bir tanım çözer. Formüllerin kendisi belirsizse başlangıç noktası RevPAR, ADR ve doluluk oranı nedir, nasıl hesaplanır? yazısıdır. Ayrıca günlük ihtiyaç ile analiz ihtiyacını da ayırın: genel müdürün sabah sayfası ile sahibin tesisler arası aylık eğilimi, farklı sahipleri olan farklı ürünlerdir; otel günlük raporu yazısında bu ayrımın nasıl kurulduğu anlatılır.

Tablo yolu meşru ve ucuzdur ama sessizce bozulur. Onu kuran kişi ayrıldığında hangi formülün yük taşıyıcı olduğunu kimse bilmez.

Adım 1: zamanlanmış veri aktarımı ve tek tablo modeli#

Zamanlanmış bir aktarım, aynı raporu, aynı saatte, aynı biçimde bir klasöre yazar; böylece tablo bir dosyadan okur, bir insan sayı kopyalamaz.

PMS'den sabit sütunlu, sabit tarih kurallı, örneğin gün sonu işleminin kapattığı iş günü esaslı ve gün sonu çalıştıktan sonraki bir teslim saatiyle kayıtlı bir rapor ya da çıktı isteyin. Amaç dosyanın kendiliğinden gelmesidir; kimse onu çekmeyi hatırlamak zorunda değildir.

Tek bir çalışma kitabı kullanın, çok değil. Kimsenin düzenlemediği bir ham veri sayfası, kodları okunabilir adlara çeviren bir eşleştirme sayfası ve yalnızca diğer ikisini okuyan bir rapor sayfası tutun. Tanımları da bir sayfaya yazın: neyin gece sayısına girdiği, hangi kesintilerin brüt geliri net gelire çevirdiği, hangi segmentlerin hangi gruba girdiği. Her dosyayı tarihleyin ve sürümleyin; yalnızca çalışma kitabını değil, çıktı dosyalarının kendilerini de saklayın ki geçmiş bir ay yeniden kurulabilsin.

Bilinen kırılma biçimlerine hazır olun: çıktıya bir sütun eklenmesi, bir segment kodunun yeniden adlandırılması, bir tesisin iş günü kesim saatini değiştirmesi, izinli olan bir kişi. Emek azdır ve kazanç gerçektir; çünkü bu alıştırma, herhangi bir araç alınmadan önce tanımlar konuşmasını erken yapmaya zorlar.

Adım 2: aktarımların üzerine bir pano aracı#

Pano aracı aynı çıktılara bağlanır ve sayıları grafikler ve filtreler olarak çizer; böylece bir yönetici tablo açmadan bakabilir.

Değişen yenileme ve erişimdir, anlam değil. Araç, çıktıdaki her eşleştirme hatasını devralır ve hatayı daha hızlı, daha çok kişiye gösterir. Aracın gerçekte ne okuduğunu kontrol edin: çıktı dosyalarını mı, bir veritabanını mı. Dosya klasörüne bakan bir araç, bir dosya eksik olduğunda bunu fark edecek bir insana ihtiyaç duyar.

Tek bir göstergeyi, hesaplamayı iki yerde yinelemeden, tesis bazında ve grup bazında göstermenin mümkün olup olmadığını sorun. Yetkiler bir varsayım değil, bir sorudur: grup aksi kararlaştırmadıkça bir tesisin sahibi başka bir sahibin sayılarını görmemelidir ve satır bazlı erişim bir gösterimle değil, gerçek bir hesapla sınanmalıdır. Mobil görünüm de önemlidir; dizüstü bilgisayar gerektiren bir grafik bir kez açılır, sonra terk edilir.

Kırıldığı yer: panolar çoğalır, her biri kendi tanımını taşır, yenilemenin sahibi yoktur ve tek bir toplantıdaki tek bir bayat sayı projenin güvenilirliğini bitirir. Yeterli olduğu yer: tüm veriniz hâlâ tek bir PMS'den ve tek bir çıktıdan geliyorsa, çıktılar üzerine kurulu bir pano bir ara basamak değil, makul bir varış noktasıdır. Yapay zekâ ile otel raporlama yönünde ilerlemek isterseniz de altta yatan aynı tanımlar geçerlidir.

Veri ambarı nedir, düz bir dille?#

Veri ambarı, PMS'nizden, restoran sisteminizden, kanal yöneticinizden ve muhasebeden veri kopyalayan, ortak tanımlara göre temizleyen ve geçmişi tutan ayrı bir veritabanıdır; böylece raporlama araçları beş yerden yerine tek yerden okur.

Bir kopyadır, canlı bir görünüm değil. Veri bir takvime göre yüklenir, gecelik yaygındır ve ambar hiçbir zaman resmî kayıt sistemi değildir, elle de düzenlenmez. Düz bir dille üç katmanı vardır: alındığı biçimiyle ham kopya, kodların eşleştirildiği ve yinelenen kayıtların ayıklandığı temiz katman ve yöneticinin gördüğü sayıları tutan raporlama katmanı.

Asıl kazanç geçmiştir. Ambar, kaynak sistemlerin üzerine yazdığını ya da attığını korur; çok yıllı eğilim sorularını olanaklı kılan da budur. İhtiyaç duyduğu şeyler: her tesis, oda tipi, fiyat kodu ve segment için kararlı bir anahtar; bir yükleme takvimi; yüklemenin gerçekten çalıştığını kontrol eden bir kişi; yazılı tanımlar. Maliyeti ise gerçek paradır ve gerçek bakımdır. Yerini hak ettiği durum, birkaç sistemin ve birkaç tesisin uyuşmak zorunda olmasıdır; tek PMS'li tek otel için değil.

Sahipler arası veri ayrımı bir tasarım kararıdır: her mülkiyet grubu için ayrı şemalar ya da ayrı ambarlar, denenerek doğrulanmış yetkilerle.

Her adımın ihtiyaç duyduğu: tutarlı kodlar, ortak tanımlar ve tek bir sorumlu#

Tablodan ambara çıkan her adım aynı üç şeye dayanır: aynı kod her yerde aynı şeyi ifade eder, her gösterge için tek bir yazılı tanım vardır ve yenilemeden tek bir adı konmuş kişi sorumludur.

Uyuşması gereken kodlar: pazar segmenti, fiyat kodu, gelir kodu, satış noktası, departman ve tesis. PMS bir şey söyler, kanal yöneticisi başka bir şey söylerse birleştirme başarısız olur ve toplam sessizce yanlış çıkar. Tanımlar tek sayfada toplanır: gece sayıları, doluluk oranının paydası ve müsait oda sayısına neyin girdiği, ADR, RevPAR, net ve brüt gelir ayrımı ve bir iptalin ne zaman sayılardan çıktığı.

Sorumlu, bir takvimi ve bir yedek planı olan adı konmuş kişidir, bir departman değil. Yenileme bozulduğunda o kişiye telefon edilir. Değişiklik yönetimi de en az bunun kadar önemlidir: yeni bir segment ya da satış noktası açıldığında eşleştirme tablosu aynı hafta, aynı sorumlu tarafından güncellenir. Mutabakat ise güvenlik ağıdır: her ay pano ya da ambar toplamı, PMS mizan ya da gün sonu toplamına eşit olmalıdır. Açıklanamayan bir fark bir yuvarlama notu değil, dur sinyalidir.

Grup raporlaması mülkiyete saygı duyar: her sahip kendi tesisini görür ve birleşik görünüm, bilinçli biçimde verilen ayrı bir yetkidir. Çok tesisli gruplardaki daha geniş yönetişim soruları için otel grubu yönetimi kontrol listesi yazısına bakabilirsiniz.

Bir raporlama aracı satın almadan önce kaynak sistemleri düzeltmek gerekir mi?#

Evet. Veriyi üreten sistemlerdeki kodları önce temizleyin; çünkü üstteki her katman onları eksiksiz kopyalar ve bir ambar hataları daha hızlı kopyalar.

Segment listesini denetleyin: kaç segment var, kaç gerçekten kullanılıyor, kaçı yinelenen ya da yanıtı gizleyen bir toplama kodu. Fiyat kodları ve gelir kodları için de aynısını yapın. Bir fiyat kodu rezervasyonun ne olduğunu anlatmalıdır, örneğin pansiyon tipi, kanal ya da paket; o gün onu öyle giren kişinin kim olduğunu değil. Satış noktalarını ve departmanları, restoran, bar, spa, minibar, çamaşırhane, okumak istediğiniz gelir satırlarına eşleyin ve kimsenin kullanmadıklarını silin.

Mali kayıtların silinmediğini, düzeltmelerin iptal ve ters kayıtla yapıldığını unutmayın; geçmiş veri her zaman düzeltmeler içerecektir. Raporlama katmanı bunları ortalayarak yok etmek yerine işlemek zorundadır. Kod listesine tek bir kişiye sahiplik verin; kod ekleme kuralı yazılı olsun ve bir gerekçe istesin.

Bir iş zekâsı sağlayıcısıyla anlaşmadan önce ne sormalısınız?#

Sayıların nasıl tanımlandığını, yenilemenin sahibinin kim olduğunu ve bir kaynak sistem değiştiğinde ne olacağını sorun; çünkü bu üç yanıt, projenin bir yıl sonra hâlâ güvenilir olup olmadığını belirler.

Şimdi ne yapmalı#

Araçları karşılaştırmadan önce iki sayfa yazın: raporladığınız gösterge tanımlarının bir sayfası ve sistemlerinizde bugün kullandığınız kodların bir listesi. Sonra en ucuz adımı bir ay çalıştırın, zamanlanmış bir aktarımı üç sayfalı tek bir çalışma kitabına, ve hangi soruları hâlâ yanıtlayamadığına bakın. Size bir pano mu yoksa bir ambar mı gerektiğini söyleyen, o kalan sorulardır; bir satıcı gösterimi değil.