Digitalne rešitve za hotelirstvo in gostinske verige

Kaj pomenijo digitalne rešitve za gostinstvo in hotelirstvo?#

Digitalne rešitve za gostinstvo in hotelirstvo so informacijski sistemi, ki povežejo rezervacije, blagajno, zaloge, kadre in komunikacijo z gostom v enoten pregled, namesto da vsak oddelek vodi svoje razpredelnice in ločene programe. Za hotelsko ali gostinsko verigo to pomeni, da vodstvo iz enega mesta vidi zasedenost sob, obrat v restavraciji, stanje zalog in delo osebja na vseh lokacijah, ne glede na to, koliko enot ima veriga in kje se nahajajo.

Pod ta pojem spadajo razvoj programske opreme in informacijskih sistemov, spletne in mobilne aplikacije, portali ter SaaS platforme, API-integracije med obstoječimi sistemi, avtomatizacija poslovnih procesov in poročanja ter digitalizacija oziroma modernizacija sistemov, ki jih je veriga uvedla pred leti. Gre za širok nabor gradnikov, ki se v posamezni verigi sestavijo glede na to, kateri procesi so največja ovira: rezervacije, nabava, komunikacija z gostom ali poročanje vodstvu.

Del teh rešitev je tudi AI za obdelavo dokumentov, semantično iskanje in agente, ki pomagajo pri ponavljajočih se opravilih, ter UX/UI za spletne strani, rezervacijske obrazce in znamčenje verige. Katera kombinacija je smiselna za posamezno verigo, je odvisno od tega, koliko lokacij ima, kako enotno že deluje in kje se izgublja največ časa – pri usklajevanju zalog med enotami, pri ročnem vnašanju podatkov v več sistemov ali pri poročanju lastnikom in upravnemu odboru.

Kateri sistemi se povezujejo v gostinski ali hotelski verigi#

Preden se digitalizacija začne, je treba ugotoviti, kateri obstoječi sistemi že delujejo in kateri podatki se med njimi sploh ne izmenjujejo. V večji hotelski ali gostinski verigi to običajno pomeni sistem za rezervacije in upravljanje nastanitev, blagajniški oziroma POS sistem v restavraciji ali baru, ERP za nabavo in zaloge, CRM za program zvestobe ter sistem za dokumente in pogodbe. Ko ti sistemi med sabo ne govorijo, osebje podatke prepisuje ročno, kar podaljšuje čas dela in povečuje tveganje napak.

Podjetja v gostinstvu in hotelirstvu pogosto že uporabljajo enega od uveljavljenih ERP ali CRM sistemov, na primer Pantheon, Business Central ali SAP, poleg ločenega rezervacijskega in blagajniškega programa. Težava običajno ni v tem, da bi bil posamezen sistem slab, temveč v tem, da si med sabo ne izmenjujejo podatkov samodejno, zato vodstvo poroča iz več virov hkrati, finance pa težko uskladijo prihodke po posameznih lokacijah verige. Pri načrtovanju povezave je zato smiselno najprej našteti sisteme, ki naj bi si med sabo izmenjevali podatke.

Šele ko je ta seznam pripravljen, je mogoče presoditi, ali gre za povezovanje obstoječih sistemov prek API-jev, za zamenjavo enega od njih ali za nadgradnjo tistega, ki ga veriga želi obdržati. Odločitev vpliva na to, koliko podatkov je treba preseliti, kako dolgo lahko posamezna enota deluje brez prekinitve in kdo v verigi prevzame odgovornost za podatke med selitvijo, zlasti če veriga med prehodom ne želi zapreti nobene od svojih enot.

• sistem za rezervacije in upravljanje nastanitev
• blagajniški oziroma POS sistem v gostinskem delu
• ERP za nabavo, zaloge in finance
• CRM za program zvestobe in komunikacijo z gostom
• sistem za dokumente in pogodbe (DMS/ECM)
• sistemi dostopa, varnosti in plačilni terminali na lokaciji
• orodja za poročanje in analitiko po lokacijah

Kako Epix pristopi k digitalizaciji hotelske ali gostinske verige?#

Epix projekt prevzame v celoti ali po posameznih sklopih, pri čemer se za večje projekte določi projektni vodja, odgovornosti posameznih ekip, roki ter način komunikacije in poročanja naročniku. Veriga se tako že na začetku dogovori, kdo odloča o spremembah obsega, kako pogosto poteka poročanje o napredku in na kakšen način se potrjujejo posamezne faze, preden se delo nadaljuje na naslednjem sklopu.

Kadar hotelska ali gostinska veriga že ima delno zgrajen ali nedokončan sistem, ga je mogoče prevzeti po pregledu izvorne kode, arhitekture, infrastrukture in obstoječih podatkov. To je pogosto hitrejša pot kot gradnja znova, vendar zahteva, da naročnik pred začetkom pregleda zagotovi dostope, dokumentacijo in gesla, saj se brez njih obseg pregleda in ocena tveganja podaljšata.

Razvojno, testno in produkcijsko okolje so pri delu ločena, v testnem okolju pa se ne uporabljajo pravi osebni podatki gostov ali zaposlenih. Vsaka sprememba gre skozi pregled in testiranje, preden se objavi v produkcijsko okolje, kar je pri verigi s več lokacijami pomembno, saj napaka na enem mestu ne sme vplivati na delovanje blagajn ali rezervacij na drugih enotah.

Izvorna koda in podatki so po dogovoru last naročnika, dokumentacija, dostopi in gesla pa so del primopredaje ob zaključku projekta ali posameznega sklopa. Za verigo to pomeni, da ni odvisna od enega izvajalca za vso prihodnost sistema, temveč lahko nadaljnji razvoj, vzdrževanje ali selitev k drugemu partnerju izvede na podlagi popolne dokumentacije.

Upravljanje več lokacij: rezervacije, zaloge in osebje na enem mestu#

Veriga hotelov, restavracij ali drugih gostinskih enot potrebuje pregled, ki ni vezan na eno lokacijo, temveč prikaže stanje vseh enot hkrati – od zasedenosti do zalog in razporeda osebja. Modularna platforma Smart Venue Platform je zasnovana prav za upravljanje fizičnih lokacij in že podpira delovanje na več lokacijah, trenutno pa je v produkciji na eni lokaciji, v igralnici v Novem mestu.

Platforma združuje registracijo gostov prek QR kode, spremljanje obiska, rezervacije, programe članstva, upravljanje dobroimetja, delo z zaposlenimi, nadzor zaloge ter administracijo in analitiko. Posamezna hotelska ali gostinska veriga lahko iz teh modulov izbere tiste, ki rešujejo njeno največjo težavo, na primer usklajevanje zalog med enotami ali enoten program zvestobe, ne da bi morala naenkrat zamenjati vse obstoječe sisteme. Spodaj so moduli, ki jih platforma že vključuje:

Ker je platforma modularna, se posamezni modul lahko uvede najprej na eni lokaciji in šele po preverjanju v praksi razširi na druge enote verige. Tak pristop zmanjša tveganje, da bi se napaka v enem modulu razširila na vse restavracije ali hotele hkrati, in daje vodstvu konkreten dokaz delovanja, preden se odloči za širitev na preostale lokacije.

Podobno logiko upravljanja na več lokacijah uporablja tudi lasten SaaS produkt BeatLogic.ai, namenjen centralnemu upravljanju glasbe in promocijskih vsebin v gostinskih in drugih prostorih. Omogoča razporejanje vsebin, oddaljeno administracijo in analitiko za vse enote verige iz enega mesta; uporablja se v realnih okoljih, imen posameznih uporabnikov pa ne razkrivamo.

• registracija gostov prek QR kode
• spremljanje obiska po lokacijah
• rezervacije in upravljanje razpoložljivosti
• programi članstva in zvestobe
• upravljanje dobroimetja in predplačil
• delo z zaposlenimi in nadzor zaloge
• administracija in analitika po enotah

Avtomatizacija poslovnih procesov in poročanja v gostinski verigi#

Avtomatizacija v hotelski ali gostinski verigi najpogosteje pomeni, da se podatki med rezervacijskim, blagajniškim in nabavnim sistemom izmenjujejo samodejno, namesto da jih osebje vsak dan prepisuje ročno v poročila za vodstvo. To zmanjša število ročnih korakov pri zapiranju dnevne blagajne, usklajevanju zalog med enotami in pripravi poročil za lastnike ali upravni odbor, kar je pri verigi z več lokacijami še bolj izrazito kot pri eni enoti.

Avtomatizirani delovni tokovi in obvestila pridejo v poštev tudi pri odobritvah naročil za posamezno enoto, pri sledenju pogodbam z dobavitelji ali pri opozarjanju, ko zaloga v eni od restavracij pade pod dogovorjeno mejo. Pri tem je treba vnaprej določiti, kdo v verigi odobri izjeme in kaj se zgodi, če sistem opozorila ne zazna pravilno ali ga preveč pogosto sproža.

Kadar veriga preide s starejšega sistema na novega, je del avtomatizacije tudi migracija podatkov – prenos zgodovine rezervacij, kartotek gostov in zalog v nov sistem brez izgube ali podvajanja zapisov. Obseg migracije je odvisen od tega, koliko let podatkov veriga želi obdržati in v kakšnem stanju so ti podatki v starem sistemu, saj neurejeni podatki pogosto podaljšajo trajanje selitve.

AI v hotelirstvu in gostinstvu: agenti, dokumenti in analitika#

AI v gostinski ali hotelski verigi se najpogosteje uporablja za obdelavo dokumentov, semantično iskanje po internih gradivih in agente, ki prevzamejo ponavljajoča se opravila, na primer razvrščanje računov dobaviteljev ali povzemanje zahtevkov gostov. Namen ni nadomestiti osebje, temveč razbremeniti ga pri delu, ki je predvidljivo in časovno potratno, tako da se osebje lahko posveti gostu.

RAG sistemi in ekstrakcija podatkov pridejo v poštev, kadar ima veriga veliko internih dokumentov – standarde dela, pogodbe z dobavitelji, navodila za posamezne enote – po katerih bi osebje rado iskalo z enim vprašanjem, namesto da brska po mapah. Natančnost takega sistema je odvisna od tega, kako urejeni so dokumenti, preden se vanje vgradi AI, saj razpršeni in zastareli dokumenti zmanjšajo zanesljivost odgovorov.

Decision-support rešitve in napovedna analitika lahko vodstvu pomagajo pri načrtovanju zasedenosti ali naročil, vendar je treba pred uvedbo določiti, kateri podatki so na voljo za učenje modela, kako natančen mora biti rezultat in katere odločitve lahko sistem predlaga, katere pa mora vedno potrditi človek. Brez teh odločitev AI projekt v verigi hitro ostane na ravni poskusa.

Mobilne aplikacije in izkušnja gostov na več lokacijah#

Mobilne aplikacije v hotelski ali gostinski verigi služijo dvema skupinama: osebju na terenu in gostom samim. Za osebje so pomembne naprave, ki delujejo tudi brez stalne povezave – offline-first aplikacije za popis zalog, vzdrževanje ali delo na recepciji, ki podatke sinhronizirajo, ko je povezava spet na voljo, tako da delo ne obstane ob slabšem signalu.

Za goste so pomembne aplikacije in POS rešitve, povezane s plačilnim sistemom, ter morebitne Bluetooth in strojne integracije, na primer pri dostopu do sobe ali plačilnem terminalu na recepciji. Katera funkcija ima smisel za posamezno verigo, je odvisno od tega, ali gre za hotel, restavracijo ali kombinacijo obojega, in od tega, koliko osebja je na voljo za podporo takih rešitev.

Enotna mobilna izkušnja med lokacijami je pomembna tudi zato, ker gost, ki obišče eno enoto verige, pričakuje enako raven storitve v drugi. To pomeni, da morajo biti podatki o gostu, njegovih rezervacijah in morebitnem programu zvestobe na voljo ne glede na to, v kateri enoti verige se gost nahaja, sicer veriga izgubi prednost enotne znamke.

Varnost podatkov in skladnost pri digitalizaciji gostinske verige#

Hotelska ali gostinska veriga obdeluje osebne podatke gostov, plačilne podatke in podatke o zaposlenih na več lokacijah hkrati, zato je varnost treba urediti pred uvedbo sistema, ne šele po njej. To pomeni ločena razvojna, testna in produkcijska okolja ter pravilo, da se v testnem okolju ne uporabljajo pravi osebni podatki gostov ali osebja.

Vsaka sprememba gre pred objavo skozi pregled in testiranje, kar zmanjša tveganje, da bi napaka v enem delu sistema ogrozila podatke na vseh lokacijah verige hkrati. Skladnost z GDPR in drugimi varnostnimi zahtevami za regulirane sisteme je del tega, kako se sistem od začetka načrtuje, ne dodatek, ki se vgradi na koncu projekta.

Znotraj Epixove specialistične partnerske mreže so na voljo profili za varnostno arhitekturo, penetracijsko testiranje, upravljanje dostopa (IAM) in odziv na incidente, poleg standardov ISO 9001, ISO 20000/20001, ISO 27001 in ISO 27701, prisotnih v delivery strukturi mreže. Za verigo to pomeni, da je mogoče sestaviti projektno ekipo z ustreznim varnostnim znanjem, kadar to zahteva panoga ali regulator.

Katere od navedenih praks so za posamezno verigo nujne in katere zadostujejo v manjšem obsegu, je odvisno od tega, koliko lokacij ima, v katerih državah poslujejo in kakšne zahteve postavljajo njeni plačilni partnerji ali regulator. Veriga, ki posluje v več državah, praviloma potrebuje strožji nadzor dostopa in jasnejšo revizijsko sled kot posamezna lokalna enota.

• ločena razvojna, testna in produkcijska okolja
• brez pravih osebnih podatkov v testnem okolju
• pregled in testiranje vsake spremembe pred objavo
• upravljanje dostopa (IAM) in nadzor pravic
• skladnost z GDPR in varnostnimi zahtevami za regulirane sisteme
• izvorna koda in podatki v lasti naročnika

Vzdrževanje in podpora po uvedbi: kaj pomenijo SLA razredi#

Po uvedbi sistema v hotelski ali gostinski verigi se vprašanje preseli od gradnje k vzdrževanju: kdo odpravi napako, če blagajna v eni od enot odpove ob prazniku, in v kakšnem vrstnem redu se obravnavajo zahteve iz več enot hkrati. Zato se podpora razdeli v razrede glede na nujnost, kot jih določa pogodba o podpori:

• razred 1 – izpad: sistem ali ključni del ne deluje, obravnava ima najvišjo prednost, odzivni čas je dogovorjen v pogodbi o podpori
• razred 2 – motnja: sistem deluje, posamezna funkcija ne, obravnava poteka po prednosti, dogovorjeni v pogodbi
• razred 3 – napaka: manjša napaka brez vpliva na poslovanje, uvrsti se v naslednjo objavo
• razred 4 – zahteva: sprememba ali nadgradnja, obseg se oceni in termin uskladi z naročnikom

Od česa je odvisna cena digitalne rešitve za hotelirstvo in gostinstvo?#

Cena digitalne rešitve za hotelirstvo in gostinstvo ni fiksna številka, temveč se določi po pregledu obsega funkcionalnosti, števila lokacij in sistemov, ki jih je treba povezati; zato cen in cenovnih razponov ne navajamo vnaprej, temveč pojasnimo, kaj nanjo vpliva.

Pred oceno obsega predlagamo krajšo analizo, ki projekt razčleni na sklope, tako da je vsak sklop – na primer povezava rezervacijskega sistema, migracija podatkov ali mobilna aplikacija za osebje – ocenljiv in izvedljiv ločeno od preostalih. Veriga lahko na podlagi te razčlenitve presodi, katere sklope izvede takoj in katere prestavi na kasnejšo fazo.

Na obseg vpliva tudi to, ali veriga posluje na eni lokaciji ali na več, v eni državi ali v več državah, saj vsaka dodatna lokacija ali jurisdikcija prinese svoje zahteve glede davkov, jezika ali varnostnih standardov. Te razlike je treba upoštevati že pri načrtovanju arhitekture, ne šele, ko se veriga odloči za širitev na nove trge.

• obseg funkcionalnosti in število uporabniških vlog
• koliko obstoječih sistemov je treba povezati in kakšni so njihovi API-ji
• ali gre za nov sistem ali za prevzem in nadgradnjo obstoječega
• količina in stanje podatkov, ki jih je treba prenesti
• zahteve glede varnosti, revizijske sledi in skladnosti
• ali je potreben mobilni del in za katere platforme
• raven podpore po uvedbi in dogovorjeni odzivni časi