Å bytte PMS eller eventsystem: det ingen forteller deg i demoen

Å bytte PMS eller eventsystem: det ingen forteller deg i demoen

De fleste demoer viser deg produktet. Nesten ingen viser deg overgangen dit. Det er synd, for det er der de fleste systembytter faktisk går galt — ikke fordi det nye systemet er dårlig, men fordi noen undervurderte hvor mye jobb det er å komme seg fra det gamle til det nye uten at driften merker det.

Vi har skrevet tidligere om hvilke spørsmål dere bør stille før dere velger leverandør, og om hvorfor et ordentlig API er en forutsetning for alt det gode dere blir lovet. Dette innlegget handler om det som skjer etter dere har signert — fasen ingen selger snakker like mye om, fordi den ikke selger noe.

Migrering er ikke én oppgave. Det er tre.

Det er lett å tenke på et systembytte som én stor overgang: en dag kjører dere gammelt system, neste dag kjører dere nytt. I praksis er det tre separate ting som må løses, og de krever ulik kompetanse:

Data må flyttes — reservasjoner, gjesteprofiler, priser, romkoder, historikk. Prosesser må tegnes om — hvordan et tilbud faktisk beveger seg fra forespørsel til signert kontrakt i det nye systemet, ikke bare i det gamle. Og folk må læres opp — ikke bare på hva knappene gjør, men på hvordan de nye rutinene henger sammen med alt annet de gjør i løpet av en vakt.

De fleste leverandører er gode på den første. Færre er gode på den andre. Den tredje blir ofte overlatt til dere selv, fordi ingen leverandør kan vite nøyaktig hvordan deres resepsjon faktisk jobber en vanlig tirsdag.

Fellen: dere migrerer alt, fordi det er der

Det er fristende å tenke at mer historikk er bedre — ta med alt fra det gamle systemet, så mister dere ingenting. I praksis er dette en av de vanligste årsakene til at migreringer trekker ut i tid og blir dyrere enn planlagt.

Spør heller: hva trenger vi faktisk å ha tilgjengelig i det nye systemet fra dag én, og hva holder det å arkivere et sted vi kan slå opp i ved behov? En femårs gjestehistorikk med kommentarfelt fulle av notater fra tre ulike resepsjonister, skrevet i tre ulike formater over tre ulike systemer, er sjelden verdt å migrere linje for linje. Det er verdt å rydde i, eller rett og slett la ligge i et arkiv, mens dere starter det nye systemet med ren, korrekt data dere faktisk stoler på.

Dette er også et godt tidspunkt for noe de fleste utsetter til det er for sent: å rydde opp i data som uansett var feil i det gamle systemet. Duplikate gjesteprofiler, romkoder som ikke lenger stemmer med den fysiske bygningen etter en ombygging, priskategorier ingen husker hvorfor finnes. Det er kjedelig arbeid. Det er også mye billigere å gjøre før migreringen enn etter.

Fellen: dere undervurderer opplæringstiden, fordi systemet er «intuitivt»

Vi har hørt dette i nesten hver eneste selgerpitch: «systemet er så intuitivt at opplæringen tar en time.» Det stemmer kanskje for grunnfunksjonene. Det stemmer sjelden for det som faktisk skjer i en travel resepsjon — en avbestilling midt i en gruppeinnsjekking, et prisavvik som må korrigeres manuelt, en gjest som ringer om en faktura fra i fjor.

En realistisk plan har med tid til at ansatte får bruke systemet på ekte oppgaver, med en erfaren kollega eller superbruker tilgjengelig, før det er skarpt. Dette er spesielt viktig hvis staben deres består av mange vikarer og sesongansatte, som ikke har samme tid til å bygge opp erfaring gjennom bruk over måneder slik en fast ansatt ville hatt.

Et konkret råd: identifiser 2-3 «superbrukere» internt før migreringen, gi dem ekstra opplæringstid, og la dem være de andre ansatte spør først i de første ukene. Det avlaster både leverandørens support og deres egen ledelse, og bygger intern kompetanse dere beholder lenge etter at implementeringsprosjektet er avsluttet.

Fellen: dere bytter midt i sesongen fordi kontrakten sier det

Dette høres opplagt ut skrevet ned, men det skjer likevel stadig vekk: en kontrakt signeres, en oppstartsdato avtales basert på når leverandøren har ledig kapasitet, og ingen stopper opp og spør om akkurat den datoen faktisk passer med hotellets egen drift.

Et konferansehotell med tung sommersesong bør ikke gå live med et nytt PMS i juni. Et sted med mye julebordsesong bør tenke seg om før november. Dette er ikke bare av hensyn til at de ansatte skal lære seg noe nytt — det er fordi eventuelle feil i migreringen, som datofeil på romblokk eller manglende priskoder, oppdages først når systemet faktisk brukes i skarpt driftspress. Det er langt bedre å oppdage dem i en rolig periode enn midt i den travleste uken i året.

Fellen: dere antar at parallell drift betyr trygghet

Mange velger, med god grunn, å kjøre gammelt og nytt system side om side en periode. Det er ofte lurt. Men parallell drift er ikke automatisk trygt — det er bare trygt hvis dere har bestemt dere for hvordan dere håndterer avvik mellom de to systemene mens dere kjører begge.

Hva gjør dere når en booking registreres i det nye systemet, men ikke i det gamle, og en gjest ringer og spør om noe dere ikke finner igjen fordi dere lette i feil system? Hvem har ansvar for å oppdatere begge systemer i overgangsperioden, og hvor lenge varer den perioden egentlig — er det en fast dato, eller «til vi føler oss trygge», som fort kan bli en periode uten noe reelt sluttpunkt?

Sett en konkret sluttdato for parallell drift før dere starter, ikke en følelse dere skal nå. Det er den eneste måten å unngå at overgangsperioden blir en permanent tilstand der dere egentlig driver to systemer på ubestemt tid.

Fellen: dere sjekker eksporten fra gammelt system for sent

Vi har skrevet om dette før i sammenheng med API-tilgang, men det er verdt å gjenta spesifikt i migreringssammenheng: sjekk hva det gamle systemet faktisk kan eksportere, før dere planlegger hva som skal inn i det nye. Det er ikke uvanlig at et gammelt system rett og slett ikke kan eksportere alt dere trodde det kunne, spesielt hvis det er et eldre system uten et ordentlig API. Da må dataene hentes ut manuelt, eller ikke i det hele tatt — og det bør dere vite tidlig i prosjektet, ikke to uker før planlagt oppstart.

Fellen: dere glemmer alt som ikke er PMS-et selv

Et systembytte er sjelden isolert til bookingsystemet. Det påvirker som regel også nøkkelkortsystemet, kassasystemet i restauranten, minibar-oppfølgingen, og eventuelle eksterne kanaler som channel managers eller betalingsløsninger. Lag en liste over alt som i dag snakker med det gamle systemet, før dere signerer noe nytt — ikke etter. Det er den vanligste kilden til uforutsette forsinkelser og ekstrakostnader vi har sett, fordi en integrasjon dere glemte å nevne i innkjøpsprosessen plutselig må bygges eller kjøpes separat.

Det som faktisk avgjør om et bytte går bra

Hvis vi skal koke det ned til noe konkret: et systembytte som går bra, har som regel én ting felles. Noen internt — ikke bare hos leverandøren — eier prosjektet, kjenner både det gamle og det nye systemet godt nok til å stille kritiske spørsmål, og har fått satt av reell tid til det ved siden av vanlige arbeidsoppgaver. Et systembytte som blir en ekstra oppgave oppå en allerede full stilling, blir sjelden gjort grundig nok, uansett hvor god viljen er.

Det er heller ikke en skam å be leverandøren om en realistisk plan, med marginer, i stedet for den optimistiske planen som ser bra ut i et tilbudsdokument. En leverandør som er ærlig om at migrering tar lengre tid enn de helst skulle sagt, er som regel en dere kommer bedre ut av det med enn en som lover at alt er klart på tre uker.