Kaip sutraukti hospitaliteto operacijas be skausmingos migracijos

Kiekvienas hospitaliteto operatorius žino, kad jo technologijų stekas – netvarka. Daugelis taip pat žino, kad tvarkyti skamba kaip košmaras.

Baimė suprantama. Klientų duomenys išsimėtę per daugybę platformų. Komanda išmokusi dabartinius įrankius. Rezervacijos eina, užsakymai priimami, narystės tvarkomos, net jei sistemos tarpusavyje nekalba. Idėja viską išrauti ir pakeisti kelia vaizdą apie prarastus duomenis, savaites prastovos, sutrikusią komandą ir piktus klientus.

Todėl daugelis nieko nedaro. Lipdo apėjimus, prideda integraciją, samdo žmogų lentelei, kuri jungia dvi sistemas, kurios nenori sinchronizuotis. Netvarka auga, bet bent jau pažįstama.

Ironija ta, kad kuo ilgiau laukiate, tuo sunkesnė galiausiai migracija. Daugiau duomenų daugiau vietų. Daugiau įpročių prie sulūžusių procesų. Daugiau klientų pripranta prie patirties, kurią žinote, kad galėtų būti geresnė.

Bet esmė tokia: konsolidacija neturi būti skausminga. Siaubo istorijos, kurios laiko prie senų sistemų, beveik visada – blogas planavimas, netinkamas technologijų partneris ar „viskas iš karto“ požiūris, bandantis pakeisti viską per vieną savaitgalį.

Kodėl dauguma migracijų klumpa

Įprastas platformos keitimas seka šabloną, beveik skirtą nepasisekti. Verslas išsirenka naują sistemą, nustato „go-live“ datą ir bando per vieną savaitgalį perkelti viską. Komanda gauna dieną mokymų. Duomenys iš senų sistemų iškeliauja į naują per naktį. Pirmadienį visi sukryžioja pirštus.

Tai nepavyksta dėl trijų priežasčių.

Pirmiausia migracija laikoma techniniu įvykiu, o ne operaciniu perėjimu. Vieną programą pakeisti kita – iš programinės pusės paprasta. Sunku užtikrinti, kad žmonės, kurie kasdien dirba su sistema, galėtų dirbti be trikdžių. Vienas kirpimas neleidžia komandai įgyti pasitikėjimo prieš spaudimą.

Antra, nuvertinama duomenų konsolidacijos sudėtingumas. Hospitalitete susikaupia milžiniški klientų, transakcijų ir operacijų kiekiai skirtingose sistemose. Kiekviena saugo kitaip. Įrašai dubliuojasi, formatai nesutampa, identifikatoriai skiriasi. Sulieti tai į švarią bazę – atskiras projektas, o skubant gaunate duomenų praradimą, sulaužytas istorijas ir ataskaitų spragas, kurias narplote mėnesiais.

Trečia, laikoma, kad visos verslo dalys keičiasi tuo pačiu tempu. Front desk, apdorojantis šimtus check-in per dieną, turi kitus poreikius ir rizikos toleranciją nei renginių komanda su keliais užklausimų laiškais per savaitę. Versti abi vienu metu priimti naują sistemą – blogai abiems.

Geresnis kelias: etapinė konsolidacija

Sėkmingiausios hospitaliteto migracijos eina etapais: nauja platforma įvedama po gabalą – viena funkcija ar viena vieta – ir kiekvienas etapas remiasi ankstesnio stabilumu.

Tai ne lėtumas dėl lėtumo. Etapinis būdas dažnai greitesnis iš viso, nes išvengiama katastrofų ir atšaukimų, kurie sugriauna „vieno didelio kirpimo“ migracijas. Kiekvienas etapas pakankamai mažas, kad nekeltų dienos operacijų chaoso, ir duoda greitą naudą, kuri stiprina pasitikėjimą kitam žingsniui.

Pirmas etapas – visada duomenys. Prieš keičiant operacinę sistemą reikia sutraukti esamus klientų įrašus, užsakymų istoriją ir transakcijas į vieną švarią bazę. Tai dubliatų suderinimas, formatų suvienodinimas ir vieningų profilių sudėjimas iš fragmentų. Gerai padarytas etapas jau duoda vertę: komanda pirmą kartą mato pilną klientų vaizdą.

Antras etapas – didžiausios įtakos, mažiausios rizikos operacija. Dažniausiai – prekybos taškas (POS). POS turi aiškius, kartojamus procesus, kuriuos greitai išmoksta personalas, o generuojami duomenys iškart naudingi ataskaitoms ir įžvalgoms. Naujo POS paleidimas pirma vienoje vietoje leidžia patikslinti sąranką, pagauti kraštinius atvejus ir užauginti vidinę patirtį prieš plėtrą.

Vėlesni etapai plečiasi: registracijos, rezervacijų platformos, renginių valdymas, narysčių įrankiai, PMS – kiekvienas savo laiku, pagal operacinį prioritetą ir komandos pasirengimą. Kadangi viskas jungiasi prie tos pačios platformos, daugiasistemės integracijų košmaras tiesiog nebereikalingas. Kiekvienas naujas modulis nuo pirmos dienos dalijasi tais pačiais duomenimis, profiliais ir ataskaitų pagrindu.

Ko ieškoti konsolidacijos partnere

Ne kiekviena platforma skirta tokiai etapinei migracijai. Daug tiekėjų siūlo modulių rinkinį, kuris techniškai vienodu prekės ženklu, bet dažnai sukurtas kaip atskiri produktai, neretai per įsigijimus. Po gaubtu vis dar silosai su priklijuotomis integracijomis – ir migracija tik pakeičia vieną problemų rinkinį kitu.

Platforma turėtų atitikti kelis kriterijus.

Ji turėtų būti tikrai vieninga: nuo POS iki PMS, CRM ir rezervacijų – viena duomenų bazė ir vienas duomenų modelis. Jei tiekėjas vadina produktą „ekosistema“ integruotų įrankių – tai įspėjimas.

Ji turėtų natyviai palaikyti kelių juridinių asmenų operacijas. Hospitalitetė dažnai veikia per kelis subjektus, ir platforma turi mokėti skirstyti mokėjimus, sąskaitas ir ataskaitas subjekto lygmeniu be rankinių apėjimų.

Ji turėtų būti nepriklausoma nuo įrenginio. Komanda naudoja tą aparatūrą, kuri tinka vaidmeniui: fiksuotas POS terminalas, planšetė salėje ar telefonas registratūroje.

Ir svarbu: konfigūruojama pagal jūsų procesus, o ne verčiant visus prie standartinės logikos. Viduryje perėjimo komandai blogiausia vienu metu mokytis naujos sistemos ir naujo darbo būdo.

Kaip Tiquo tvarko konsolidaciją

Tiquo projektuotas būtent tam. Viena platforma: POS, rezervacijos, bilietai, narystės, registracijos, svečių valdymas, CRM, renginių užklausos, viešbučio PMS, mokėjimai, ataskaitos. Visos funkcijos dalijasi ta pačia baze, tais pačiais profiliais ir realaus laiko varikliu.

Migracija į Tiquo seka aprašytą etapų seką. Pradedama išsamiu duomenų importu: klientų įrašai, užsakymų istorija ir transakcijos iš visų esamų sistemų sueina į vieną vietą. Tiquo duomenų variklis tvarko deduplikaciją, formatų suvienodinimą ir tapatybės suderinimą – tai, ką rankomis daryti ypač sunku.

Toliau kiekviena operacinė funkcija diegiama eilėje. Lanksti konfigūracija leidžia Tiquo aptinti tai, kaip jūs jau dirbate, o ne primesti standartinį procesą nuo nulio. Restorano komanda naudojanti POS neturi mokytis viešbučio PMS, o renginių komanda – sporto klubo rezervacijų. Kiekvienas liečia savo dalį, o po gaubtu viskas jungiasi.

Prieiga iš įvairių įrenginių reiškia, kad perėjime nebūtinai keičiate aparatūrą. Tiquo veikia naršyklėse, „iPhone“, „iPad“, „Android“ ir dedikuotoje POS be funkcijų apkarpymo. Jei vietoje jau yra planšetės – jos gali likti.

O kad protingi kelių subjektų mokėjimai įtaisyti į platformą, finansinis konsolidavimas vyksta automatiškai. Kiekviena transakcija pati išsiskaido teisingam juridiniam asmeniui su momentine sąskaita – ir dingsta kryžminiai vidiniai sąskaitų rašymai bei suderinimo našta, kuri dažnai išgyvena net ir po operacinės migracijos.

Kainuoja ir laukimas

Kiekvienas mėnuo ant fragmentuoto steko neša kaupiamąsias sąnaudas, retai matomas balanse. Laikas rankiniams apėjimams. Klientų duomenys, kurie skirtingose sistemose vis labiau išsiskiria. Kryžminio pardavimo galimybės nematomos, nes nė viena sistema nemato viso kelio. Ataskaitos, kuriomis vadovybė negali pasitikėti be savaitės rankinio tikrinimo.

Šios sąnaudos nemažėja. Jos auga. O migracija, kuri šiandien atrodo baugi, po metų bus dar baugesnė: daugiau duomenų, daugiau žmonių perkvalifikuoti, daugiau senų įpročių atrišti.

Klausimas ne ar konsoliduoti. O ar dabar, kol apimtis dar valdoma, ar vėliau, kai bus sunkiau, lėčiau ir brangiau.