PMS (Property Management System) نرمافزاری است که عملیات یک اقامتگاه را حول رزرو یکپارچه میکند: چه کسی، کدام واحد، کِی، با چه پرداختی، و بعد از آن چه اتفاقی باید بیفتد. تقویم فقط «اشغال» را نشان میدهد، اکسل هر چیزی را نگه میدارد ولی هیچ قاعدهای را اعمال نمیکند، و چنل منیجر فقط موجودی و نرخ را بین پلتفرمها جابهجا میکند. PMS لایهای است که قواعد رزرو، مهمان، پول و دسترسی را در یک جا نگه میدارد و بقیهی ابزارها به آن وصل میشوند.
انتخاب درست یعنی ابتدا مشخص کنید مشکل شما کدام است (تداخل رزرو؟ حسابوکتاب شرکا؟ تیم چندنفره؟ چند مجتمع؟) و بعد نرمافزاری بخرید که همان را حل کند، نه نرمافزاری که فهرست ویژگیهایش طولانیتر است. این مقاله معیارها، چکلیست تست و خطاهای رایج را میگوید و در انتها صریح مینویسد شاهکلید کدام بخشها را دارد و کدام را ندارد. نقشهی بزرگتر ابزارها در اتوماسیون اقامتگاه آمده است.
PMS چیست و چه فرقی با تقویم، اکسل و چنل منیجر دارد؟
در صنعت هتلداری، PMS را سیستمی جامع میدانند که عملیات پذیرش، فروش، برنامهریزی و گزارش را هماهنگ میکند. مدخل ویکیپدیا (که خودش میگوید به منبع بیشتر نیاز دارد، پس آن را مرور کلی بگیرید) کارکردهای معمولش را اینطور میشمارد: ثبت رزرو و مشخصات مهمان، ثبت هزینهها و صورتحساب، گزارشها، و اتصال به ابزارهای دیگر مثل چنل منیجر، موتور رزرو، سیستم قفل و درگاه پرداخت. نسخههای ابری امروزی گاهی چنل منیجر و موتور رزرو را هم داخل خودشان دارند.
ابزار | چه چیزی را نگه میدارد | چه چیزی را اعمال میکند | کجا کم میآورد |
|---|---|---|---|
تقویم (گوشی، دفترچه) | بازههای اشغال | هیچ | پرداخت، مهمان، چندنفرهشدن |
اکسل / صفحهگسترده | هر ستونی که بسازید | هیچ (مگر فرمول بنویسید) | همزمانی چند ویرایشگر، کنترل دسترسی، بررسی تداخل (مقایسهی دقیق) |
چنل منیجر | موجودی و نرخ بین پلتفرمها | همگامسازی | پرداخت، مهمان و مالی را ندارد (چنل منیجر و iCal) |
PMS | رزرو، مهمان، پرداخت، گزارش، کاربران | قواعد (تداخل، دسترسی، وضعیت) | به کیفیت ورودی شما و به اتصالها وابسته است |
موتور رزرو | تقویم زندهی قابلنمایش به مهمان | رزرو و پرداخت آنلاین | معمولاً بخشی از PMS یا جدا (موتور رزرو) |
نتیجهی عملی: «PMS» یک برچسب است و نه یک مجموعهی ثابت ویژگی. نرمافزاری که فقط رزرو و پرداخت دارد هم کاری شبیه PMS میکند، و نرمافزاری که چنل منیجر و موتور رزرو و قیمتگذاری هم دارد، همان را گستردهتر ساخته است. مهم این است که ماژولهای مورد نیاز شما باشند.
ماژولهای اصلی؛ از لازم تا لوکس
برای میزبان کوتاهمدت، ماژولها را به سه دسته بشکنید.
هسته (بدون آن PMS نیست)
رزرو و تقویم. ثبت رزرو با تاریخ ورود و خروج، وضعیت (در انتظار، تأییدشده، در حال اقامت، لغو)، بررسی همپوشانی، نمای چندواحدی. اگر تقویم هنگام ثبت مانع تداخل نمیشود، هنوز دفترچه است (جلوگیری از رزرو تکراری).
مهمان. مشخصات، سابقهی اقامت، یادداشت و سابقهی رفتار. اگر لیست سیاه یا ثبت مدارک لازم دارید، اینجا باید جا داشته باشد (ثبت مهمان).
پرداخت و مالی. ثبت مبلغ کل، بیعانه، مانده و روش پرداخت. اگر پرداخت چندمرحلهای ثبت نشود، حساب هر رزرو بیرون سیستم میماند.
کاربران و دسترسی. چه کسی چه چیزی را ببیند و تغییر دهد. با دو نفر مهم نیست، با پنج نفر و چند ساختمان مهمترین قابلیت امنیتی است (نقشها و دسترسیها).
گزارش. اشغال، درآمد و هزینه به تفکیک واحد، ساختمان و بازهی زمانی.
لایهی دوم (وقتی کار بزرگ شد)
چنل منیجر و موتور رزرو (اگر نرمافزار خودش ندارد، اتصال آن).
ارتباط با مهمان (قالب پیام، یادآوری).
عملیات خانهداری و نگهداری: وظایف نظافت و تعمیر، وضعیت واحد. این ماژول در همهی نرمافزارها نیست؛ اگر نظافت را درون نرمافزار میخواهید باید صراحتاً بپرسید.
سهم شرکا و تسویه، بهخصوص در مجتمعهای مشارکتی (تسویهی شرکا).
اتصال به قفل، حسگر و حسابداری.
لوکس (قبل از نیاز نخرید)
قیمتگذاری خودکار، داشبورد پیشبینی، اپ مهمان، اتصال به دهها سرویس. مقالهی اتوماسیون هم میگوید ترتیب خرید مهم است: ابتدا ثبت درست تقویم و مالی، بعد بقیه. نرمافزار رزرو بدون ثبت مالی منظم سود واقعی را نشان نمیدهد (سود واقعی).
معیارهای انتخاب؛ از «چه میخواهم» به «چه میخرم»
منابع صنعتی فهرستهای مشابهی دارند. برای نمونه، یک برگهی ارزیابی PMS که شرکت StayNTouch (فروشندهی PMS هتلی) در ۲۰۱۷ در Hospitality Net منتشر کرد، محورهای زیر را برای مقایسهی فروشندهها میشمرد: هزینهی سالانه، پیادهسازی، دسترسی از موبایل، اتصالها، گزارش، سهولت استفاده، خودکارسازی، امنیت و مقیاسپذیری، و پشتیبانی. این منبع فروشنده است و وزنهایی نمیدهد (نسخهی کامل برگه را من ندیدم)، پس فهرستش را الگو بگیرید نه استاندارد. معیارهای زیر ترکیب آن فهرست با منطق مخصوص اقامتگاههای کوتاهمدت است.
۱. تعداد واحد و ساختار
یک واحد: ممکن است تقویم منظم و دفتر پرداخت کافی باشد؛ نرمافزار وقتی ارزش دارد که چند نفر دخیل باشند یا رزرو از چند کانال بیاید.
چند واحد در یک مجتمع: نمای یکجا برای همهی واحدها، رنگ و نام یکتا برای هر واحد، امکان جابهجایی مهمان بین واحدها (رزرو چندواحدی).
چند مجتمع: مفهوم «ساختمان» یا «شعبه»، گزارش جدا و مجموع، و دسترسی محدود به یک ساختمان برای مدیر هر شعبه (مقیاسپذیری). تست پرسشی: «میتوانم یک مدیر را فقط به ساختمان الف دسترسی بدهم و گزارش مالی ساختمان ب را نبیند؟»
۲. دسترسیها و سابقهی تغییرات
بپرسید نقشها سفارشیاند یا فقط «ادمین و کاربر»؟ آیا هر تغییر (ویرایش، لغو، حذف) با نام کاربر ثبت میشود؟ این دو قابلیت وقتی تیم بزرگتر از دو نفر میشود جایگزین اعتماد کورکورانه است.
۳. گزارش مالی که قابلاتکا باشد
نمونهی خوب: گزارش را بشود به ساختمان، واحد، منبع رزرو و بازه تفکیک کرد؛ هزینهها دستهبندی داشته باشند؛ و تعریف «درآمد» روشن باشد (آیا درآمد به شبهای اقامت نسبت داده میشود یا به تاریخ واریز؟). نرمافزاری که این تعریف را مبهم میگذارد، گزارشش با دفتر شما هرگز نمیخواند.
۴. کانالها و اتصالها
اگر در بیش از دو کانال هستید و رزرو فوری فعال دارید، اتصال چنل منیجر جزو معیار است؛ اگر نه، شاید لازم نباشد. برای پلتفرمهای ایرانی منبع رسمیای که اتصال هر نرمافزار را تأیید کند پیدا نکردم؛ پس از فروشنده فهرست پلتفرمهای دارای اتصال را مکتوب بخواهید و آن را در نسخهی آزمایشی خودتان امتحان کنید (چنل منیجر و iCal).
۵. خروج داده
مهمترین و کمپرسیدهترین معیار. منابع مهاجرت PMS (مثلاً راهنمای Redawning، SmartOrder و وبلاگ Roommaster، همه فروشنده یا مرتبط با فروشنده) روی چند نکته همنظرند: خروجی کامل رزروهای آینده مهمترین قلم است، خروجی ممکن است ناقص یا در فرمتی باشد که سیستم جدید نمیخواند، و پنجرهی خروجی با پایان لایسنس بسته میشود. یک منبع میگوید برخی فروشندهها داده را ۳۰ تا ۹۰ روز پس از لغو حذف میکنند؛ این ادعای یک منبع است، پس عدد را قطعی نگیرید، ولی منطقش را بگیرید: قبل از پرداخت اولین اشتراک بپرسید «خروجی کامل رزروها، مهمانها و پرداختها به چه فرمتی و با چه محدودیتی داده میشود؟» و در نسخهی آزمایشی خودتان یک بار آن را بگیرید.
۶. پشتیبانی
در دسترس بودن، زبان، ساعت کاری و نحوهی ثبت درخواست. اگر یک بار در نسخهی آزمایشی سؤال بپرسید و پاسخ سه روز طول بکشد، همان پیشگویی ماههای بعد است.
۷. پشتیبانگیری و امنیت داده
بپرسید: داده کجا نگهداری میشود؟ هر چند وقت نسخهی پشتیبان گرفته میشود؟ آیا میتوانم خودم خروجی بگیرم؟ منبع رسمی ایرانیای که الزام نگهداری دادهی مهمان در نرمافزار را روشن کند پیدا نکردم؛ رویهی محتاطانه این است که فقط دادهی لازم ثبت شود و دسترسی افراد خروجی از تیم همان روز بسته شود.
۸. قیمت و ساختار آن
ساختار را بپرسید، نه فقط عدد را: ثابت ماهانه یا به ازای واحد یا به ازای رزرو؟ آیا افزودن کاربر یا ساختمان هزینهی جدا دارد؟ هزینهی راهاندازی و انتقال داده؟ من قیمت بازار ایران را برای این نرمافزارها از منبع رسمی تأییدشدهای نیافتم و عددی نمیآورم.
هزینهی واقعی یک PMS چقدر است؟
یک منبع خدماتهتلی میگوید هزینهی PMS فقط اشتراک ماهانه نیست؛ فهرست کاملش را باید خودتان بسازید:
هزینهی سالانهی واقعی = اشتراک + راهاندازی و انتقال داده + هزینهی اتصالها (چنل منیجر و غیره) + زمان آموزش + هزینهی خطاهای ورود داده
فرض کنید (عددها گرد و صرفاً نمونه) نرمافزار ماهی ۱ میلیون تومان است، یعنی سالی ۱۲ میلیون. اگر راهاندازی و انتقال داده ۳ میلیون هزینه یا ۱۰ ساعت وقت شما باشد و هر ساعت وقتتان ۲۰۰ هزار تومان ارزش داشته باشد (۲ میلیون)، سال اول نزدیک ۱۷ میلیون خرج است، نه ۱۲. در مقابل، اگر نرمافزار ماهی ۸ ساعت وقت ثبت دستی و تطبیق را کم کند، یعنی ۱۲۰ ساعت در سال یا حدود ۲۴ میلیون با همان ارزش ساعت، سرمایهگذاری روی کاغذ توجیه میشود. اگر این صرفهجویی واقعی نبود، نرمافزار گران است. چارچوب پایهی سود در سود واقعی اقامتگاه و هزینههای کمتر دیدهشده در هزینههای پنهان آمده است.
هزینهی مهاجرت از اکسل یا نرمافزار قبلی
مهاجرت دو بخش دارد: داده و عادت.
داده. منابع مهاجرت میگویند خروجی را باید به دستههای جدا بشکنید: رزروهای آینده، مشخصات مهمانها، پرداختها و ماندهها، پیکربندی واحدها و نرخها، و گزارشهای تاریخی. قواعد مثل شرایط لغو و نرخ فصلی معمولاً خودکار منتقل نمیشوند و باید دستی بازنویسی شوند. دو توصیهی تکراری که منطقی است: یک مهاجرت آزمایشی با زیرمجموعهی کوچک انجام دهید و درستی نگاشت را بررسی کنید؛ و تغییر نرخ را در روزهای انتقال متوقف کنید.
عادت. مهمتر از داده، این است که تیم از کی به بعد فقط در نرمافزار ثبت میکند. چند هفتهی همزمانکاری با اکسل رایج است، ولی فقط با یک «منبع حقیقت» که تاریخ آغازش مشخص باشد؛ وگرنه همان رزرو تکراری از راه دیگری برمیگردد.
زمانبندی
نقطهی صفر را در فصلی کمتقاضا بگذارید. اگر یک مهمان هماکنون در واحد است و نرخش در سیستم قدیمی ثبت شده، آن رزرو را در سیستم تازه با دقت دستی وارد کنید و بعد با تقویم قدیمی مقابله کنید.
چکلیست ارزیابی و تست آزمایشی
نسخهی آزمایشی را با سناریو تست کنید، نه با گشتوگذار. این سناریوها را با دادهی واقعی خودتان اجرا کنید:
تداخل. یک رزرو برای واحد X از روز ۸ تا ۱۰ ثبت کنید و بعد رزرو دوم از ۹ تا ۱۱ همان واحد؛ باید هشدار بدهد. بعد رزرو ۱۰ تا ۱۲؛ نباید هشدار بدهد.
ویرایش. تاریخ خروج را یک شب تمدید کنید روی روزی که رزرو بعدی دارد؛ باید تداخل را بگیرد.
جابهجایی. مهمان را به واحد دیگری ببرید؛ بررسی تداخل روی واحد جدید انجام میشود؟
پرداخت چندمرحلهای. بیعانه را ثبت کنید، بعد مانده را؛ مانده درست حساب میشود؟
لغو. رزرو را با جریمه لغو کنید؛ گزارش مالی چه میکند؟
دسترسی. یک کاربر محدود بسازید و ببینید چه چیزی را میبیند.
سابقهی تغییر. از اتفاقی که افتاد، اسم کاربر و زمان ثبت شده؟
گزارش. درآمد و هزینهی یک ماه گذشتهی خودتان را وارد و گزارش بگیرید؛ با دفترتان یکی است؟
خروجی. کل دادهی آزمایشی را در فایل خروجی بگیرید و باز کنید.
موبایل. تمام موارد بالا را روی گوشی انجام دهید، چون پذیرش اغلب با گوشی کار میکند.
قطع. اگر اینترنت قطع شد چه میبینید؟ (رفتار آفلاین برنامههای تحت وب فرق دارد.)
بعد از تست، برای هر مورد «قبول، شرطی، رد» بنویسید و هر مورد رد را از فروشنده مکتوب پیگیری کنید.
خطاهای رایج انتخاب
خرید برای ویژگی، نه برای مشکل. فهرست ویژگیها را کنار هم میگذارید و بلندترینش را میخرید، ولی مشکل اول شما حساب شرکا بود و آن ماژول نیست.
نخریدن، چون «بعداً میخرم». هر ماه تأخیر یعنی دادهی بیشتری که باید منتقل شود.
ورود همهی دادهی گذشته. رزروهای آینده و حساب باز را وارد کنید؛ سالها دادهی قدیمی لازم نیست همهاش بیاید.
بیتوجهی به خروج داده. قفل شدن در یک فروشنده با افزایش داده بدتر میشود.
انتخاب بدون آزمایش با دادهی واقعی. نمایش (دمو) را فروشنده مدیریت میکند؛ نسخهی آزمایشی شما نه.
همهی تیم را با یک دسترسی کامل کار دادن. با اولین ویرایش اشتباه میفهمید.
نداشتن مسئول سیستم. یک نفر باید نرمافزار را «صاحب» باشد: کاربران، تنظیمات، پشتیبان و آموزش.
فرض اینکه نرمافزار قواعد را جایگزین میکند. اگر قاعدهی کاری (کی رزرو تأیید میشود، چه بیعانهای) روی کاغذ نیست، نرمافزار فقط بینظمی را سریعتر میکند (رویههای استاندارد).
شاهکلید در این چارچوب
بر اساس کد شاهکلید، اینها را دارد:
رزرو و تقویم: ثبت رزرو، ثبت سریع، بررسی همپوشانی هنگام ثبت و ویرایش، تقویم چندواحدی با نمای ساختمان، خروجی تقویم بهصورت تصویر و Excel، روزهای خاص و نرخ روزانه.
مهمان: کارت مهمان، لیست سیاه و استعلام آن هنگام ثبت رزرو.
پول (مدیریت مالی کامل): پرداختهای چندمرحلهای هر رزرو، روشهای پرداخت، کارتهای واریز، درآمد شبانه با گزارش و نمودار، هزینهها با دستهبندی و هزینهی مشترک، بدهی و اقساط با یادآوری، سهامداران، دورهی تسویه، دفتر حساب هر شریک و صندوق ساختمان. «منبع رزرو» هم قابل تعریف است.
تیم: نقشها و دسترسی (روی منابعی مثل رزرو، واحد، پرداخت، هزینه، گزارش و تنظیمات)، گزارش فعالیتها، مرخصیها، اعلان.
ساختار: چند ساختمان با واحدهای هر کدام.
عملیات: خانهداری و نظافت با کار خودکار از روی رزرو و نگهداری و تعمیرات با یادآوری.
قیمت و مهمان: «دیدهبان نرخ» برای قیمت پیشنهادی هر شب با دلیل و تحلیل بازار، و «راهنمای دیجیتال مسافر» با لینک و QR و پیامک خودکار لینک اقامت به مهمان (توضیح در دیدهبان نرخ و راهنمای دیجیتال مسافر).
و اینها را ندارد (در کد پیدا نشد): چنل منیجر یا iCal، موتور رزرو و درگاه پرداخت، اتصال به نرمافزار حسابداری، صدور صورتحساب رسمی یا اتصال به سامانهی مالیاتی (رسید رزرو وجود دارد)، و اتصال به قفل. از اطلاعات هر سازمان هر شب نسخهی پشتیبان گرفته میشود و خروجی کامل اطلاعات سازمان را از طریق پشتیبانی شاهکلید میتوانید بگیرید؛ گزارشهای مالی، هزینهها، بدهیها، نگهداری و تقویم هم خودشان خروجی Excel دارند. پس شاهکلید برای میزبانی مناسب است که مسئلهاش رزرو، حساب و تیم است و همگامسازی پلتفرم را بیرون از نرمافزار انجام میدهد؛ برای کسی که مسئلهی اصلیاش اتصال خودکار کانالهاست، گزینهی کامل نیست.
سؤالهای پرتکرار
برای یک واحد هم PMS لازم است؟
نه همیشه. اگر رزرو کم و یک کانال است، تقویم منظم و دفتر پرداخت کافی است. وقتی چند نفر روی تقویم کار میکنند، پول چندمرحلهای است یا سود هر واحد را جدا میخواهید، نرمافزار ارزش پیدا میکند.
PMS و چنل منیجر یکی هستند؟
نه. چنل منیجر فقط موجودی و نرخ را بین پلتفرمها هماهنگ میکند. PMS رزرو، مهمان، پرداخت و گزارش را نگه میدارد. بسیاری از PMSها چنل منیجر را هم دارند یا به یکی وصل میشوند، ولی این دو کار متفاوتند.
قبل از امضای قرارداد چه چیزی را حتماً مکتوب بگیرم؟
فرمت و محدودیت خروجی داده، مدت نگهداری داده بعد از لغو، فهرست پلتفرمهای دارای اتصال رسمی، ساختار قیمت (هزینهی کاربر یا ساختمان اضافه)، و ساعت و کانال پشتیبانی. بقیه را میشود در آزمایش دید.
نسخهی آزمایشی چند روز کافی است؟
عدد قطعی منبعداری نیافتم. معیار زمان نیست، پوشش سناریوهاست: تا همهی ۱۱ مورد بالا را با دادهی واقعی خودتان نگذراندهاید، تصمیم نگیرید. اگر فروشنده مهلت کوتاه میدهد، اول موارد خروج داده، دسترسی و گزارش مالی را تست کنید.
اگر بعداً نرمافزار را عوض کردم، دادهام از دست میرود؟
اگر خروجی کامل گرفتهاید، نه. اگر فقط به نمایشهای داخل برنامه تکیه کردهاید و فروشنده خروجی نمیدهد، ممکن است بخشی از داده را از دست بدهید. به همین خاطر گرفتن خروجی نمونه در همان نسخهی آزمایشی یک گام اجباری است.
مطالب مرتبط
اتوماسیون اقامتگاه؛ ابزارها و مرز انسان — نقشهی ابزارهای فناوری برای میزبان (PMS، کانالمنیجر، پیام خودکار، قیمتگذاری، قفل و حسگر)، معیار تصمیم برای…
کاهش مصرف انرژی اقامتگاه — واحد خالی را گرم یا سرد نگه نداشتن بزرگترین اهرم صرفهجویی است، ولی دو خطر دارد: یخزدگی لوله و مهمانی که دما را…
API و وبهوک در مدیریت اقامتگاه — API، وبهوک و ابزارهای بدونکد چه فرقی دارند، کدام سناریوهای اقامتگاه ارزش اتصال دارند، امنیت کلید و وبهوک چطور…
منابع
Property management system — Wikipedia (مرور کلی؛ خودش نیازمند منبع بیشتر است)
PMS Software Evaluation Scorecard — Hospitality Net / StayNTouch, 2017
How to migrate property management system without losing bookings — Redawning
Hotel PMS Data Export: what you need before leaving your old system — SmartOrder
How to migrate from Mews without losing a single booking — Roommaster
نظرها