Kategorijos
Naujausias dienoraštis
Viešbučio spynų integravimas su PMS: kaip viešbučių durų spynos susiejamos su PMS, OTA ir savarankiško registravimosi sistemomis
Šiuolaikinės viešbučių durų spynos nebėra atskiri techninės įrangos vienetai. Daugeliui viešbučių, apartamentų su paslaugomis ir savitarnos objektų tikroji išmaniosios spynos vertė priklauso nuo to, kaip gerai ji susisiekia su viešbučio turto valdymo sistema (PMS).
Tinkamai suprojektuota viešbučio spynos ir PMS integracija gali sujungti rezervacijas, kambarių priskyrimą, svečių kredencialus ir išsiregistravimą į vieną automatizuotą darbo eigą.
Užuot registratūros darbuotojams rankiniu būdu kuriant kiekvieną rakto kortelę ar prieigos kodą, viešbučio sistema gali automatiškai nurodyti užrakinimo sistemai:
kas turėtų turėti prieigą, į kurį kambarį jie gali patekti, kada prieiga turėtų prasidėti ir kada ji turėtų baigtis.
Tačiau PMS integracija gali veikti labai skirtingai, priklausomai nuo to, ar viešbutis naudoja RFID korteles, PIN kodus, mobiliuosius raktus, internetinę užrakinimo sistemą ar tradicinę neprisijungusią viešbučio spyną.
Šiame vadove paaiškinama, kaip veikia visa integracija.
PMS valdo svarbią viešbučio informaciją, tokią kaip:
Viešbučio užrakinimo sistema valdo:
PMS ir durų spynos integracija leidžia šioms dviem sistemoms keistis informacija, reikalinga svečių prieigai valdyti.
Supaprastinta darbo eiga atrodo taip:
Rezervacija → PMS → Durų užrakinimo sistema → Svečio kredencialas → Viešbučio kambarys
PMS išlieka atsakinga už svečio viešnagę, o durų užrakinimo sistema yra atsakinga už tos rezervacijos informacijos pavertimą fizine arba skaitmenine prieiga.
Vienas dažnas nesusipratimas yra tas, kad Booking.com, Expedia ar kita OTA tiesiogiai valdo viešbučio durų spyną.
Daugumoje viešbučių aplinkų darbo eiga yra labiau struktūrizuota.
| Sistema | Pagrindinis vaidmuo |
| OTA / Užsakymų platforma | Generuoja arba priima rezervaciją |
| PMS | Valdo informaciją apie svečius, kambarius ir viešnagę |
| Viešbučio spynų sistema | Kuria ir kontroliuoja prieigą prie kambarių |
| Svečių ryšių sistema | Siunčia prieigos informaciją svečiui |
Įprastas procesas gali būti:
Svečias užsako per OTA
↓
Rezervacija patenka į PMS
↓
Viešbutis priskiria svečiui kambarį
↓
PMS siunčia reikiamus rezervacijos duomenis į viešbučio spynų sistemą
↓
Spynų sistema sukuria RFID atpažinimo priemonę, PIN kodą arba mobilųjį raktą
↓
Svečias gauna arba pasiima atpažinimo priemonę
↓
Po išsiregistravimo atpažinimo priemonė tampa nebegaliojanti
Ši architektūra yra svarbi, nes PMS gali išlikti pagrindiniu viešbučio operatyvinės informacijos šaltiniu.
Ne kiekviena viešbučio spynų sistema jungiasi prie PMS taip pat.
Tai būdinga tradiciniams viešbučiams.
Įprasta darbo eiga yra:
PMS → Viešbučio spynų programinė įranga / sąsaja → Kortelių kodavimo įrenginys → RFID svečio kortelė
Svečiui užsiregistravus, PMS pateikia tokią informaciją kaip:
Kodavimo įrenginys įrašo šią informaciją į svečio kortelę.
Pati spyna gali likti neprisijungusi prie tinklo, nes prieigos leidimas saugomas RFID kortelėje.
Šis modelis ypač tinka viešbučiams su registratūra ir personalu.
Internetinės viešbučio spynos gali palaikyti labiau automatizuotą darbo eigą.
Užuot kodavus fizinę kortelę, PMS arba prijungta viešbučio platforma siunčia rezervacijos informaciją per viešbučio išmaniosios spynos API.
Tada spynų sistema gali sukurti:
Supaprastinta darbo eiga yra:
PMS → API → Išmaniųjų spynų platforma → Svečio kredencialai
Šis modelis ypač naudingas:
Daugeliui projektų reikalinga tiek tradicinė, tiek skaitmeninė prieiga.
Pavyzdžiui:
RFID kortelė + PIN kodas + mobilioji prieiga + mechaninis avarinis raktas
Viešbutis vis dar gali išduoti RFID korteles registratūroje, kartu leisdamas pasirinktiems svečiams gauti skaitmeninius kredencialus.
Hibridinė architektūra gali suteikti daugiau lankstumo, tačiau integracijos reikalavimai turi būti patvirtinti prieš pradedant projektą.
Profesionalus viešbučio durų spynos API neturėtų tiesiog pateikti „atrakinti duris“ komandos.
Integracija turi valdyti visą svečio kredencialų gyvavimo ciklą.
Tipiniai duomenys gali apimti:
| Duomenys | Kodėl tai svarbu |
|---|---|
| Rezervacijos ID | Identifikuoja užsakymą |
| Svečio vardas | Susieja prieigą su svečiu |
| Kambario numeris | Nustato autorizuotas duris |
| Įsiregistravimo laikas | Apibrėžia kredencialų aktyvavimą |
| Išsiregistravimo laikas | Apibrėžia kredencialų galiojimo pabaigą |
| Kredencialų tipas | RFID, PIN arba mobilusis raktas |
| Prieigos zonos | Svečio kambarys, liftas arba viešosios erdvės |
| Kredencialų būsena | Aktyvūs, pakeisti, atšaukti arba pasibaigusio galiojimo |
Priklausomai nuo sistemos, gali prireikti ir papildomų funkcijų.
Pavyzdžiui:
Štai kodėl viešbučių pirkėjai turėtų klausti daugiau nei:
„Ar teikiate API?“
Geresnis klausimas yra:
„Kokius viešbučio prieigos darbo procesus palaiko jūsų API?“
Integracijos vertė tampa ypač aiški viešbučio savarankiškos registracijos durų spynos projekte.
Įsivaizduokite, kad svečias atlieka rezervaciją internetu.
Užsakymas gali būti gautas iš:
PMS saugo:
Kai svečiui priskiriamas kambarys, viešbučio sistema gali suaktyvinti išmaniosios spynos API.
Tada gali būti sukurtas laikinas PIN kodas arba mobilusis kredencialas.
Priklausomai nuo viešbučio sistemos, svečias kredencialą gali gauti per:
Pavyzdžiui:
Kambarys: 502
Įsiregistravimas: 15:00
Išsiregistravimas: 11:00
Durų PIN kodo: 684921
Svečias atvyksta ir naudoja autorizuotą atpažinimo priemonę.
Po išsiregistravimo PIN kodas arba mobilioji atpažinimo priemonė tampa negaliojanti pagal sukonfigūruotą prieigos laikotarpį.
Šio tipo automatizavimas gali sumažinti pasikartojantį registratūros darbą, kartu užtikrinant vėlyvą atvykimą ir įsiregistravimą be darbuotojų.
Tai yra vienas iš svarbiausių integracijos klausimų, kuris dažnai būna nepastebėtas.
Tarkime, kad pradinė rezervacija yra:
Rugpjūčio 12 d. → rugpjūčio 15 d.
tačiau svečias nusprendžia likti iki rugpjūčio 17 d.
Tinkamai integruota sistema turėtų leisti naujai išsiregistravimo informacijai atnaujinti svečio prieigą.
Priklausomai nuo spynos architektūros:
Sistema gali nuotoliniu būdu pratęsti PIN kodo arba mobiliosios atpažinimo priemonės galiojimą.
Priklausomai nuo sistemos konfigūracijos, svečiui gali tekti atnaujinti arba iš naujo užkoduoti RFID kortelę registratūroje.
Štai kodėl viešbučiai turėtų suprasti, ar projektui reikia:
prieigos priemonių valdymo nuotoliniu būdu realiuoju laiku
ar tiesiog:
PMS palaikomo kortelių išdavimo registratūroje.
Kambario keitimas yra dar vienas svarbus PMS įvykis.
Jei svečias persikelia:
502 kambarys → 608 kambarys
sistema turėtų neleisti senajai atpažinimo priemonei toliau suteikti nereikalingos prieigos, kartu sukurdama prieigą naujam kambariui.
Internetinėse sistemose tai dažnai galima sutvarkyti skaitmeniniu būdu.
Neinternetinėse RFID sistemose gali prireikti iš naujo užkoduoti kortelę.
Todėl vertindami PMS išmaniosios spynos integraciją, paklauskite, ar ji palaiko:
ne tik pirminė registracija.
Oracle OPERA yra plačiai naudojama svetingumo industrijoje, todėl OPERA viešbučio durų spynų integracija yra dažnas reikalavimas viešbučių užraktų projektuose.
OPERA Cloud palaiko durų spynų sistemos integracijas, todėl kambario raktų operacijos gali būti susietos su viešbučio rezervacijomis ir registratūros darbo procesais.
Priklausomai nuo projekto ir sistemos konfigūracijos, durų spynų integracijos gali naudoti tradicines nuosavybės sąsajas arba modernius išeinančius REST pagrindu veikiančius ryšius.
REST pagrindu veikiančiai durų spynų integracijai spynų sistemos tiekėjas gali turėti pateikti tokią informaciją kaip:
Tikslus įdiegimas priklauso nuo OPERA versijos, viešbučio konfigūracijos ir naudojamos durų spynų sistemos.
Dėl šios priežasties pirkėjai neturėtų daryti prielaidos, kad teiginys:
„Palaiko OPERA“
automatiškai reiškia „plug-and-play“ suderinamumą.
Prieš diegimą patvirtinkite:
LOCSTAR viešbučių užraktų sistemos gali suteikti PMS sąsajos galimybę ir API/SDK palaikymą atitinkamiems projektams, įskaitant viešbučių projektus, kuriems reikalingos sąsajos su tokiomis sistemomis kaip OPERA/Fidelio. Galutinis suderinamumas turėtų būti patikrintas pagal PMS versiją ir projekto reikalavimus.
Šios dvi sąvokos dažnai painiojamos.
| Funkcija | RFID PMS integracija | Internetinė išmaniosios spynos API |
|---|---|---|
| Fizinė svečio kortelė | Paprastai taip | Pasirenkama |
| PIN / Mobilieji kredencialai | Paprastai riboti | Įprasta |
| Nuolatinis spynos ryšys | Nereikalingas | Paprastai reikalingas internetinėms funkcijoms |
| Nuotoliniai kredencialų pakeitimai | Ribotas | Palaikoma priklausomai nuo sistemos |
| Registratūros koduotuvas | Paprastai reikalingas | Gali būti nereikalingas |
| Savarankiška registracija | Ribotas | Puikiai tinka |
| Tradicinis viešbučio veiklos modelis | Puikus | Geras |
| Veikla be personalo | Mažiau tinkamas | Puikus |
Nė viena architektūra nėra automatiškai geresnė.
Teisingas pasirinkimas priklauso nuo viešbučio veiklos modelio.
Prieš pasirinkdami užraktų sistemą, paruoškite šią informaciją:
Taip pat apibrėžkite:
Kas sujungia sistemas?
Tai gali apimti:
Aiškus atsakomybės pasiskirstymas neleidžia projektams pasiekti diegimo etapo, prieš tai neišsiaiškinus, kad svarbūs integravimo darbai nebuvo atlikti.
Viešbučių projektuose nuolat pasitaiko keletas klaidų.
Fizinė spyna gali puikiai tikti durims, tačiau neatitikti programinės įrangos reikalavimų.
API dokumentacijos pateikimas ir užbaigtos PMS integracijos suteikimas nėra tas pats.
Sistema, kuri sukuria tik pradinį kredencialą, neapima viso viešbučio darbo eigos proceso.
Daugumoje profesionalių viešbučių aplinkų prieigos kontrolė turėtų atitikti viešbučio centrinę rezervavimo ir kambarių valdymo darbo eigą.
Dideliems viešbučių projektams atlikite bandomąjį testą, apimantį:
Rezervacija → Registracija → Rakto/PIN kodo sukūrimas → Kambario keitimas → Viešnagės pratęsimas → Išsiregistravimas
prieš diegiant šimtus spynų.
Taip. Profesionalios viešbučių užrakinimo sistemos gali integruotis su PMS platformomis per specialias sąsajas, API arba SDK, priklausomai nuoviešbučio durų spynų sistemos.
Taip. OPERA Cloud palaiko durų spynų sistemos sąsajas ir kambario rakto darbo eigas. Tikslus integravimo būdas priklauso nuo OPERA aplinkos ir spynų sistemos.
Paprastai rezervacija pirmiausia patenka į viešbučio PMS arba valdymo platformą. Tada PMS arba prijungta integravimo platforma inicijuoja spynų sistemą kredencialui sukurti.
Taip, palaikomos internetinės išmaniųjų spynų sistemos gali sukurti riboto galiojimo kredencialus, kurie tampa negaliojantys pagal sukonfigūruotą išsiregistravimo laiką.
Taip. PMS integracija neapsiriboja tik internetinėmis spynomis. Tradicinės RFID viešbučių sistemos gali sujungti PMS su kortelių kodavimo darbo eiga, kol pačios kambarių spynos lieka neprisijungusios prie tinklo.
Nebūtinai. Neprisijungusioms prie tinklo RFID sistemoms nereikia nuolatinio interneto ryšio kambario lygiu. Internetinių spynų architektūros turi skirtingus šliuzo, „Wi-Fi“ arba tinklo reikalavimus.
API yra techninis programinės įrangos komunikacijos metodas. PMS integracija yra užbaigta operacinė darbo eiga, sukurta naudojant API, SDK arba kitą sąsajos metodą.
Sėkminga viešbučio spynų ir PMS integracija – tai ne tik dviejų programinės įrangos dalių sujungimas.
Ji turėtų apimti visą svečių prieigos ciklą:
Rezervacija → Kambario priskyrimas → Prieigos duomenų sukūrimas → Svečio prieiga → Viešnagės pakeitimai → Išsiregistravimas → Prieigos duomenų galiojimo pabaiga
Tradiciniams RFID viešbučiams gali prireikti patikimo PMS palaikomo kortelių išdavimo, o savitarnos viešbučiams gali prireikti viešbučio išmaniųjų spynų API , kuris automatiškai sugeneruoja PIN kodus arba mobiliuosius prieigos duomenis.
Prieš pasirinkdami sistemą, patvirtinkite PMS, reikiamus darbo procesus, prieigos duomenų tipą, tinklo architektūrą ir techninę atsakomybę.
Atsiųskite LOCSTAR savo:
Mūsų komanda gali įvertinti, ar jūsų projektui reikalinga RFID PMS sąsaja, išmaniųjų spynų API, internetinis viešbučio spynų sprendimas ar pritaikyta integracija.
en
es
ar
lt
中文
