Kuidas koondada majutus- ja toitlustustööd ilma migreerimisõuduseta

Iga majutuse ja toitlustuse tegija teab, et tarkvarastakk on sassis. Enamik teab ka, et korrastamine kõlab õudusena.

Hirm on mõistetav. Sul on aastate kaupa kliendiandmeid hajutatud kümnetes platvormides. Meeskond on õppinud olemasolevaid tööriistu. Broneeringud tulevad, tellimused võetakse, liikmelisust hallatakse — isegi kui need süsteemid omavahel ei räägi. Kõik välja kiskumine ja asendamine toob ette kujutluse kadunud andmetest, nädalate seisakust, segaduses personalist ja pahuratest klientidest.

Nii et enamik ei tee midagi. Lisatakse veel üks lahendus, veel üks integratsioon, palgatakse keegi, kes hoiab tabelit, mis ühendab kaks süsteemi, mis keelduvad sünkroonimast. Sassis jääb, aga vähemalt on see tuttav sassis.

Iroonia on see, et mida kauem ootad, seda raskem hilisem kolimine on. Andmeid koguneb juurde. Personal õpib katkiste voogude järgi. Kliendid harjuvad killustatud kogemusega, mida sa tead, et saaks paremaks.

Aga asi on selles: koondamine ei pea valus olema. Õuduslood, mis hoiavad legacy peal, tulenevad peaaegu alati halvast planeerimisest, valest tehnoloogiapartnerist või kõik-korraga lähenemisest.

Miks enamik kolimisi läheb untsu

Traditsiooniline platvormivahetus järgneb peaaegu ebaõnnestumisele mõeldud mustrile. Valitakse uus süsteem, määratakse „go-live“ kuupäev ja üritatakse kõik ühe nädalavahetusega ümber lülitada. Personal saab ühe päeva koolitust. Andmed eksporditakse vanast ja imporditakse uude öises tummuses. Esmaspäeva hommikul ristitakse sõrmed.

See ebaõnnestub kolmel põhjusel.

Esiteks käsitletakse kolimist tehnilise sündmusena, mitte operatiivse üleminekuna. Ühe süsteemi teise vastu vahetamine on tarkvara vaates suhteliselt sirge. Raske on tagada, et inimesed, kes süsteemi iga päev kasutavad, saaksid tööd teha katkestusteta. Üks lõikehetk annab personalile null aega enne surve all esinemist.

Teiseks alahinnatakse andmete koondamise keerukust. Majutusettevõtted koguvad kliente, tehinguid ja operatiiviandmeid paljudesse süsteemidesse. Iga süsteem hoiab teisiti. Kirjed dubleeruvad, vormingud on erinevad, identifikaatorid ei klapi. Puhta ühtse andmebaasi kokkuõmblemine on omaette projekt; kiirustades kaotatakse andmeid, lõhutakse kliendiajalugu ja tekivad aruandelüüned, mille lahendamine võtab kuusid.

Kolmandaks eeldatakse, et kogu äri neelab muutuse sama tempoga. Vastuvõtt, kes teeb päevas sadu sissekandeid, ja ürituste meeskond, kellel on nädalas mõni päring, pole sama riskiprofiiliga. Mõlema samaaegne sundümberminek ei teeni kumbagi.

Parem lähenemine: faasitud koondamine

Edukamad majutuskolimised järgnevad faasilisele mudelile: uus platvorm tuleb samm-sammult, ühe funktsiooni või ühe koha kaupa, iga faas ehitab eelmise stabiilsusele.

See pole aegluse pärast aeglane. Faasid on kokku võttes tihti kiiremad, sest välditakse katastroofilisi ebaõnnestumisi ja tagasipöördeid. Iga faas on piisavalt väike, et igapäevategevust ei lõhu, ja annab kohe väärtust, mis loob hoogu ja usaldust järgmise jaoks.

Esimene faas on alati andmed. Enne operatiivseid muudatusi koondatakse olemasolevad kliendikirjed, tellimuste ajalood ja tehingud ühte puhtasse andmebaasi. Dubleerimised lepitakse, vormingud ühtlustatakse, ühtsed profiilid ehitatakse killustatud legacy andmetest. Hästi tehtuna annab see faas juba väärtust — meeskonnal on esimest korda täielik klientpilt.

Teine faas sihib suurima mõju ja väikseima riski operatsiooni. Enamasti on see kassa (POS). POS-i voog on selge, personal õpib kiiresti, andmed annavad kohe aruandeid ja ülevaateid. Uue POS-i rullimine ühest kohast alustades võimaldab seadistust lihvida, äärmusjuhtumeid leida ja sisemist ekspertiisi kasvatada enne laienemist.

Järgmised faasid laienevad. Sissekanded, broneeringud, üritused, liikmelisus, kinnisvara haldus — igaühel oma faas, ajastus sõltub prioriteedist ja meeskonna valmidusest. Kuna kõik ühendub sama platvormi külge, ei ole mitme süsteemi integratsioonilõksu. Iga uus moodul jagab algusest peale samu andmeid, profiile ja aruandlust.

Mida otsida koondamispartnerilt

Iga platvorm ei toeta sellist faasitud kolimist. Paljud pakkujad müüvad moodulite kogu, mis tehniliselt kannab sama brändi, aga on ehitatud eraldi toodetena, tihti omanduste kaudu. Põhjas on ikka silod ja külgeõmmeldud integratsioonid — kolides vahetad ühe probleemkomplekti teise vastu.

Valitud platvorm peaks vastama mitmele tingimusele.

Ta peaks olema päriselt ühtne: iga funktsioon, POS-ist PMS-i ja CRM-ini, töötab ühel andmebaasil ja ühel andmemudelil. Kui müüja kirjeldab toodet „ökosüsteemina“ integreeritud tööriistadest, on see hoiatusmärk.

Ta peaks toetama mitme üksuse operatsiooni natiivselt. Majutusettevõtted töötavad sageli mitme juriidilise üksuse kaudu; platvorm peab maksete jagamise, arvelduse ja aruandluse üksuse tasemel käsitlema ilma käsitsi nippideta.

Ta peaks olema seadme-sõltumatu. Personal peaks saama kasutada riistvara, mis rollile sobib — fikseeritud POS, iPad põrandal, telefon vastuvõtul.

Ja kriitiliselt: piisavalt seadistatav, et järgida su olemasolevaid vooge, mitte sundida jäika süsteemiloogikat. Ülemineku keskel ei vaja meeskond korraga nii uut süsteemi kui täiesti uut tööviisi.

Kuidas Tiquo koondamist käsitleb

Tiquo on algusest peale mõeldud täpselt selle stsenaariumi jaoks. Üks ühtne süsteem: kassa, broneeringud, piletid, liikmelisus, sissekanded, külaliste haldus, CRM, ürituste päringud, hotelli PMS, maksed ja aruanded. Iga funktsioon jagab sama andmebaasi, profiile ja reaalajas andmemootorit.

Kolimine Tiquole järgib ülal kirjeldatud faase. Alustatakse põhjalikust andmeimpordist, mis koondab kliendikirjed, tellimuste ajalood ja tehingud kõigist olemasolevatest süsteemidest ühte. Tiquo andmemootor teeb deduplikatsiooni, vormingute ühtlustamise ja identiteedi lahendamise — mida käsitsi tehes on eriti valus.

Edasi juurutatakse funktsioonid järjest. Kohandatav seadistus tähendab, et Tiquo paindub su meeskonna juba toimivate voogude ümber, mitte ei suru peale jäiku skeemi, mis nõuaks nullist ümberõpet. Restorani POS-i kasutav meeskond ei pea hotelli PMS-i tundma; ürituste meeskond ei pea terviseklubi broneeringuvoogu õppima. Iga roll näeb oma osa, andmekiht hoiab kõik ühenduses.

Mitme seadme tugi tähendab, et riistvara ei pea ülemineku ajal vahetama. Tiquo töötab veebis, iPhone'il, iPadil, Androidil ja spetsiaalsel POS-il piiranguteta. Kui olemasolevad tahvlid toimivad, jäävad need.

Kuna nutikad mitme üksuse maksed on platvormis sees, toimub finantskoondamine automaatselt. Iga tehing jagub õigesse juriidilisse üksusesse kohe arvetega — kaob rist-arvelduste ja leppimise koormus, mis tihti pärast operatiivset kolimist alles jääb.

Ootamise päris hind

Iga kuu killustatud stackil tähendab kulusid, mis bilansis harva eraldi ridadena paistavad. Aeg käsitsi nippidele. Kliendiandmed lagunevad süsteemide lahknedes. Ristmüügi võimalused jäävad nähtamatuks, sest ükski süsteem ei näe kogu teekonda. Juhtkond ei saa aruandeid usaldada ilma nädala käsitsi kontrollita.

Need kulud ei vähene. Need kasvavad. Ja kolimine, mis täna tundub hirmutav, on aasta pärast hirmutavam — rohkem andmeid, rohkem ümberõpet, rohkem legacy vooge lahti harutada.

Küsimus pole kas koondada. Küsimus on kas nüüd, kui ulatus on hallatav, või hiljem, kui see on aeglasem, raskem ja kallim.