Az RM ökoszisztéma — PMS, CHM, RMS, BI

Az eddigi 14 leckében sokszor érintettük a hotel technikai rendszereit — a PMS-t, a Channel Managert, a pricing engine-t, a riport-eszközöket. Most ezeket egy ábrába rakjuk össze, mert a revenue manager nem dolgozhat a stack ismerete nélkül.

A modern hotel egy 4 rendszerből álló ökoszisztémát üzemeltet, ahol minden rendszer egy konkrét célt szolgál, és a rendszerek adatot cserélnek egymással valós időben. Egy hiányzó vagy gyengén integrált rendszer drámaian csökkenti az RM-munka hatékonyságát — a rosszul beállított Channel Manager double-bookingot okoz, a hiányzó RMS reaktív (nem proaktív) árazáshoz vezet, egy gyenge BI-rendszer pedig láthatatlanná teszi az olyan kérdéseket, mint „melyik szegmens csúszik el novemberre?”.

Ennek a leckének az a célja, hogy ismerd a stack négy rétegét, lásd, hogyan dolgoznak együtt, és érts az integrációs pontokon — mert egy RM mindenhol ezeken keresztül operál.

A négy réteg

A modern hotel-stack négy rétege:

A négy réteg egy folytonos adat-keringés: a PMS gyűjti az adatot a foglalásokról, a CHM szétküldi az árakat a csatornákra (és vissza-szinkronizálja a beérkező foglalásokat), az RMS elemzi az adatot és javasol árazást, a BI vizualizálja az egész képet az emberi RM számára.

Most nézzük végig egyenként.

1. PMS (Property Management System)

A PMS a hotel „központi adatbázisa”. Minden, ami történik a hotelben, valamilyen módon a PMS-be rögzül:

• Egy vendég foglal → PMS-be kerül.
• A recepciós check-ineli → PMS frissül.
• A vendég számlát kap a reggeli után → PMS-be folio-bejegyzés.
• A check-out megtörténik → PMS lezárja a foglalást, felszabadítja a szobát.
• Egy szoba „out of order” lesz (felújítás, meghibásodás) → PMS jelzi.

Tipikus PMS-rendszerek a piacon:

• Sabeeapp — magyar fejlesztés, magyar és nemzetközi piacon. Hotel Peaqplus City ezt használja.
• Mews — európai felhős, modern, gyors felhasználói felület. Sok független boutique hotel választja.
• Fidelio (ma Oracle Hospitality OPERA, felhős verziója az Opera Cloud) — a klasszikus enterprise rendszer, a nagy nemzetközi márkák PMS-e.
• Previo — közép-európai (cseh eredet), kis és közepes hotelek számára.
• Hostware — magyar fejlesztés, közép-európai jelenléttel.

A PMS-választás stratégiai döntés egy hotel életében — 5-10 évre szól, mert a migráció másik rendszerre drága és kockázatos. A PMS-ből minden más rendszer adatot kér be, így a PMS-nek nyitottnak kell lennie (API, integrációs interfészek).

Egy RM-perspektívából a PMS a forrás-igazság: itt rögzül a tényleges (actual) foglaltság, ADR, RevPAR. Minden más rendszer ezt másolja és értelmezi.

2. Channel Manager (CHM)

A Channel Manager a hotel és a külső disztribúciós csatornák közötti tolmács. A 6. leckében (Csatornák) láttuk, hogy egy hotel 8-15 csatornán keresztül adja el a szobáit — Booking, Expedia, Hotels.com, Agoda, GDS-ek, saját web, metasearch, B2B-disztribútorok, stb.

Egy CHM nélkül a hotelnek manuálisan kellene minden csatornán külön-külön beállítania az árakat és az elérhetőséget. Ez napi 2-3 órás munka lenne, és emberi hiba-forrás — a double-booking gyakori jelenség egy gyenge integráción.

A CHM-mel: a hotel egy helyen állít árat (a PMS-ben vagy az RMS-ben), és a CHM valós időben szétküldi mindegyik csatornára. Egy érkező foglalás pedig azonnal visszaszinkronizálódik a PMS-be, így a többi csatornán automatikusan csökken az elérhetőség.

Tipikus CHM-rendszerek:

• D-Edge — vezető európai CHM, sok hotel használja. Erős OTA-integráció + booking engine + GDS.
• Cubilis — belga eredetű, közép-európai jelenlét.
• SiteMinder — ausztrál eredetű, globális, sok független hotelnél.
• RateGain — indiai eredetű, gyakran nagyobb chain-eknél.
• Bookassist — ír eredetű, európai pozícióban.

Hotel Peaqplus City D-Edge-et használ, mert a PMS-ével (Sabeeapp) jól integrálódik, és minden OTA-csatornájára azonnali szinkron-támogatást nyújt.

A CHM-nél a hibák egy klasszikus forrása az integrációs hibák — az OTA-mapping (melyik rate plan + melyik szobakategória felel meg a Booking.com-on), a restrictions szétküldése, a foglalás-szinkronizálás. Egy érett RM-szervezetben a CHM havi audit alá kerül — a mapping-hibák miatt különben elcsúsznak az árak.

3. RMS (Revenue Management System)

Az RMS az „agy” — az árazási, forecast- és restrikciós döntéseket támogató rendszer. Itt áll a kérdés: „mi legyen holnap a BAR?”, „melyik napon kell MLOS-t bevezetni?”, „a transient szegmens pickup-ja melyik dátumra lassul?”

A klasszikus PMS és CHM nem foglalkozik árazási döntésekkel — ők csak az adatot mozgatják. Az RMS az, ami elemzi az adatot és javaslatokat ad az RM-nek.

A Peaqplus ebbe a kategóriába tartozik. Pár konkrét funkció, ami egy RMS-t alkot:

Pickup-elemzés

A 16. leckében (Pickup és booking pace) részletesen átvesszük. A Peaqplus napi szintű pickup-tablót mutat: minden dátumra a jelenlegi foglaltság, a tavalyi same-point, a budget-cél, a várt végeredmény. A pickup-tabló az RM napi morning-routine központi eleme.

Same Point analízis

A 18. leckében (Same point analysis) mélyebben átvesszük. A Peaqplus a same-point-ot beépítve mutatja a pickup-elemzés mellett: nem absztrakt YoY-összehasonlítás, hanem azonos foglalási ablakon (pl. „30 nappal a check-in előtt”). Ez drámaian jobb értelmezési keret.

Forecast modul

A 19-20. és 38. leckében (Forecasting) átvesszük. A Peaqplus napi szintű forecastot generál a következő 30-90 napra, és hibrid logikát használ: pickup-trend + booking curve + manuális korrekciók (events, holiday shift).

Smart Forecast Enhanced

Egy haladó funkció, amit az 55. leckében (Smart Forecast Enhanced) az expert szinten veszünk át. Lényege: AI-erősített, többrétegű forecast 60-90 napos horizonton — statisztikai modell + LLM által becsült anomália-jelek + manuális korrekciók.

DCAL (Day-Class-Arrival-Length)

A 33-34. leckében (DCAL) átvesszük. Egy mátrix-szerű árazási megközelítés, ahol az ár nem egy szám, hanem egy mátrix az érkezési nap, a szobakategória és a tartózkodási hossz függvényében.

Pricing Engine

A 35-36. és az 56. leckében (Dinamikus árazás és ML-alapú ajánlás) átvesszük. A Peaqplus szabály-alapú és ML-alapú árajánlatokat generál — az RM felülvizsgálja és dokumentálja a döntést.

Insight Engine

Az 52-53. leckében (Insight Engine, AI-narratíva) átvesszük. AI-elemzés, amely természetes nyelven mond el összefoglaló-szerű elemzéseket: „A city break szegmens pickup-ja 18%-kal elmarad a budgettől, elsősorban a corporate utazások mérséklődése miatt…”. Az RM 5 mondatban kapja meg azt, amit 100 grafikonon olvasna ki.

Egy RMS funkció-listája egyetlen leckében nem fér ki — ezek a fő modulok, és a haladó/expert szintű leckékben mindegyikre visszatérünk.

A kulcsüzenet: az RMS az egyetlen rendszer, amely önállóan gondolkodik — a többi (PMS, CHM, BI) csak mozgatja és megjeleníti az adatot. Az RMS döntés-előkészítő, és egy modern hotelben a revenue manager munkájának 50-70%-át támogatja.

4. BI (Business Intelligence)

A BI a megjelenítés és elemzés rétege — a riportok, dashboardok, ad-hoc lekérdezések, vezetői összefoglalók. Egy BI-eszköz az összes rendszerből olvas (PMS, CHM, RMS), és vizualizálja az adatot.

A klasszikus BI-megközelítés egy webes dashboard egy hotel-szerkezetű „data warehouse” felett. Itt vannak:

• A morning report — tegnap, hónap, év — összegzett mutatók.
• A pace-riportok — a következő 30-90 nap foglaltság-pickup pályája.
• A szegmens-bontás — havi, dátum-szintű, csatornánkénti.
• A F&B és spa-bevétel — a TRevPAR-hoz szükséges adatok.
• A compset-elemzés — saját pozíció vs. piaci átlag.
• Az ad-hoc kérdések — „melyik corporate-szerződés esett ki az utolsó 6 hónapban?”

Egy modern RM-szervezetben a BI a napi rutin központi felülete. Ha a PMS, a CHM és az RMS mind a „működés”, a BI a megértés.

A BI-eszközöknek nincs egyetlen domináns piaci megoldása — egy közepes hotel gyakran Excel + saját SQL-lekérdezések szintjén dolgozik, egy nagyobb hotel-csoport pedig enterprise-szintű webes BI-platformot üzemeltet.

Az adatfolyam

A négy réteg adatcseréje egy folyamatos kör:

1. Foglalási folyamat: vendég foglal egy OTA-n → CHM fogadja → PMS rögzíti.
2. Ár-frissítési folyamat: az RM dönt egy új BAR-ról az RMS-ben → PMS-be megy az új ár → CHM szétküldi az összes csatornára.
3. Forecast-frissítés: napi PMS-export → RMS feldolgozza → új forecast generálódik → BI megjeleníti.
4. Riport-megjelenítés: a BI olvas a PMS-ből + RMS-ből + CHM-ből → a dashboardon megjelenik az RM-nek.

A négy réteg között integrációs pontok vannak — API-k, fájl-export-import, valós idejű webhookok. Egy gyenge integráció csorbítja a rendszer egészét:

• Ha a PMS → CHM integráció lassú (pl. 30 perces frissítés), a hotel double-bookingot kockáztat.
• Ha az RMS → PMS integráció nem valós idejű, az RMS által javasolt ár 24 órás késéssel érkezik a csatornákra.
• Ha a BI nem olvas mindenhonnan, a riportokban lyukak vannak.

Egy érett RM-szervezet havi integráció-audit alá veszi a stacket: minden adat-mozgási pont működik-e, vannak-e elcsúszások, milyen hibák jelentkeznek.

Mit kell egy kezdő RM-nek érteni a stackből

Egy kezdő revenue manager nem üzemelteti a stacket — de érti és dolgozik vele. A minimumok:

1. Tudja, melyik adat melyik rendszerből származik — egy diszkrepancia esetén tudja, hol kell keresni.
2. Érti az adat-frissítések frekvenciáját — egy PMS-export, ami este 22-kor fut, nem fogja másnap reggel mutatni a 23:00-kor érkezett foglalásokat.
3. Felismeri az integrációs hibákat — ha a Booking.com-on 110 EUR áll, de a saját rendszerben 95, a CHM-mapping valószínűleg hibás.
4. Tudja, mit kérhet a stacktől, és mit nem — pl. egy klasszikus PMS-ből nem feltétlenül tud szegmens-szintű ALOS-t kihúzni; ez RMS- vagy BI-funkció.
5. Tudja, hova kell jelezni, ha valami nem működik — ha a sales-team látja, hogy nem szinkronizál a member rate, akkor az IT-nek vagy a PMS-vendornak kell ránéznie.

Ezek alapszintű készségek. A 16-32. leckében (középhaladó szint) ezekre mélyebben építünk: ott már a riport-olvasás, a pace-elemzés és a channel-elemzés szintjén dolgozunk a stackkel.

Visszatekintés a teljes kezdő szintre

Ez volt a kezdő szint utolsó leckéje. 15 leckén keresztül felépítettük az RM-szakma alapját:

• 1. Mi az RM és miért fontos
• 2. Perishable inventory mint a szakma gyökere
• 3–4. A három alap-KPI + TRevPAR
• 5. Optimális mix vs. 100% foglaltság
• 6–7. Csatornák, disztribúció, rate parity
• 8. Szegmensek és piacok
• 9–10. Szezonalitás és foglalási ablak
• 11. Length of stay és ALOS
• 12. Egy RM napja
• 13–14. Rate-struktúra és compset
• 15. A technikai stack

Ezek az építőkockák — mindegyik egy fogalmi területet érint. A középhaladó szinten (16-32. lecke) a fókuszt a mérés- és elemzés-eszközök felé toljuk: hogyan olvasunk pickup-ot és pace-t, hogyan elemezzük a channel-mixet, hogyan készül egy forecast, hogyan vezetünk revenue meetinget. Mélyebb mérés, érettebb döntés.

A haladó szinten (33-50. lecke) a stratégia és módszer jön: dinamikus árazás, DCAL, group displacement, length of stay restrictions, revenue meeting vezetése.

Az expert szinten (51-67. lecke) az adatvezérelt és AI-támogatott RM kerül a középpontba: Insight Engine, AI-narratíva, Smart Forecast Enhanced, ML-alapú pricing engine.

Ezzel a térképpel a fejedben mehetünk tovább. Köszönöm, hogy idáig kitartottál — most jön a mélység.

Kulcsüzenetek

• A modern hotel 4 rétegű stacken dolgozik: PMS (központi nyilvántartás), CHM (csatorna-tolmács), RMS (döntéstámogatás), BI (megjelenítés).
• A négy réteg valós idejű adatcserével dolgozik együtt — gyenge integráció = double-booking, késő ár-frissítés, hiányos riport.
• A PMS a forrás-igazság — minden más rendszer ide kér be adatot.
• Az RMS az egyetlen rendszer, amely önállóan gondolkodik — a többi mozgatja és megjeleníti az adatot. Ez a Peaqplus kategóriája.
• Egy kezdő RM nem üzemelteti a stacket, de érti és dolgozik vele — a minimumok: adat-forrás-ismeret, frissítési frekvencia, integrációs hiba-felismerés.