Integration er ikke et teknologiprojekt. Det er arbejdet med at forvandle en reservation til et klargjort værelse uden et telefonopkald, en gæstehenvendelse til en opgave med en ansvarlig og en fejl til en udbedring med en deadline. Holdt inden for et stramt omfang passer dette arbejde ind på 30 dage for ethvert PMS med et dokumenteret API, og nedenstående plan viser rækkefølgen, de ansvarlige og kontrolpunkterne.

Hvem denne plan er for

• Systemejere og IT-chefer, der har brug for et forsvarligt omfang og en realistisk tidsplan

• Driftsdirektører og hoteldirektører, der ønsker værdi før højsæsonen

• Ledere af housekeeping og vedligeholdelse, der går op i pålidelig status og færre opkald

Den forudsætter et cloud-PMS med API-adgang, såsom Mews, Apaleo, Oracle OPERA Cloud, Cloudbeds eller Guestline, samt et enkelt hotel eller ét hotel i en koncern, der bruges som pilotprojekt.

Hvad skal være på plads før dag ét?

Fire ting, og hvis én af dem mangler, er uret ikke begyndt at gå endnu.

1. API-adgang er tildelt, ikke blot lovet. Ansvarlig: systemejer eller IT-chef. Varighed: afsæt en til to uger før dag ét, da dette er det trin, leverandører ofte forsinker. Du skal bruge loginoplysninger, de dokumenterede rate limits og, hvis det tilbydes, et sandkassemiljø. Mews offentliggør sine endpoints i Mews Connector API-dokumentationen, og Apaleo offentliggør sine på apaleo.dev, så du kan læse begrænsningerne, før du forpligter dig til et omfang.

2. En navngiven ledelsessponsor. Ansvarlig: hoteldirektør. Varighed: én samtale. Nogen skal kunne sige nej til omfangsglidning i uge tre.

3. En skriftlig baseline. Ansvarlig: oldfrue/rengøringschef og receptionschef. Varighed: en halv dag. Registrer dagens gennemsnitlige tid for værelsesklargøring, rettidig færdiggørelse og opkald pr. vagt mellem receptionen og housekeeping. Uden dette kan du ikke bevise, at projektet virkede.

4. Et pilotområde. Ansvarlig: rengøringschef. Varighed: en time. Én etage, én vagt, én supervisor.

Bør integrationen være envejs eller tovejs?

Vælg den model, der matcher din leverandør og din risikovillighed, og start simpelt.

Start med envejs, hvis du er i tvivl. Tilføj tilbageskrivning i måned to, når teamet har opbygget tillid til det, de ser. Sweeply understøtter begge modeller på tværs af sine mere end 20 PMS-integrationer, så beslutningen handler om din drift frem for om integrationsforbindelsen.

30-dagesplanen: otte trin med en ansvarlig og en varighed

1. Aftal use cases, og fastlås omfanget. Ansvarlig: ledelsessponsor. Varighed: dag 1 til 2. Fire use cases er det rette antal for en første udrulning: synkronisering af værelsesstatus, oprettelse af rengøringsopgaver ud fra udtjekninger, gæsteanmodninger der bliver til opgaver, og overdragelser til vedligeholdelse. Alt andet placeres på en liste mærket ”fase to”.

2. Definer statusser i et klart sprog. Ansvarlig: oldfrue/rengøringschef sammen med receptionschefen. Varighed: dag 3 til 5. Skriv ned, hvad rent, snavset, i gang, inspiceret, klar, ude af drift (out of order) og ude af salg (out of service) rent faktisk betyder på dit hotel, og hvilke overgange der er tilladt. De fleste integrationsfejl skyldes, at denne halve side mangler.

3. Kortlæg værelser, værelsestyper og etager. Ansvarlig: systemejer. Varighed: dag 6 til 8. Opret én kanonisk referencetabel, og hold den under versionsstyring. Enhver senere uoverensstemmelse diagnosticeres ud fra denne tabel.

4. Konfigurer opgavetyper, prioriteter og svartider. Ansvarlig: rengøringschef og teknisk leder i fællesskab. Varighed: dag 9 til 12. Forbind kategorier af gæsteanmodninger med opgavetyper, angiv tidsfrister, og beslut, hvem en forfalden opgave eskaleres til. Sweeplys moduler til housekeeping og vedligeholdelse konfigureres i dette trin.

5. Angiv roller, adgang og dataminimering. Ansvarlig: systemejer sammen med den databeskyttelsesansvarlige. Varighed: dag 13 til 15. Hent kun de felter, som arbejdet kræver, begræns gæstedata til de roller, der har brug for det, og slå revisionslogføring til. Sweeplys vilkår for hosting, kryptering og databehandling er offentliggjort på tillidssiden, hvis indkøbsafdelingen efterspørger dem.

6. Gennemfør en pilot på én etage og én vagt. Ansvarlig: rengøringschef. Varighed: dag 16 til 20, kørende live i tre til fem dage. Observer faktiske vagter i stedet for at læse rapporter. Registrer enhver uoverensstemmelse i kortlægningen og hvert øjeblik, en medarbejder tøver.

7. Ret fejl, og afhold derefter et go/no-go-kontrolpunkt. Ansvarlig: ledelsessponsor. Varighed: dag 21 til 24. Sammenlign pilotens tid for værelsesklargøring og rettidig færdiggørelse med udgangspunktet fra før dag ét. Hvis tallene ikke har flyttet sig, skal årsagen findes, før du opskalerer problemet.

8. Faseinddel udrulningen, og stabiliser. Ansvarlig: hoteldirektør med én tovholder pr. afdeling. Varighed: dag 25 til 30 samt to ugers daglige kontroller. Rul ud etage for etage eller bygning for bygning, tjek API-helbred og forfaldne opgaver hver morgen, og før en synlig problemoversigt, så tilliden vokser.

To offentliggjorte udrulninger er værd at læse sideløbende med denne plan. STAYERY skiftede fra regneark til automatiseret planlægning af rengøring under opholdet på Apaleo (STAYERY-casestudie), og Volkshotel Amsterdam holdt 196 værelser og et team bestående af 33 nationaliteter i drift gennem en migration til Mews (Volkshotel-casestudie).

Hvilke data skal rent faktisk matche?

Fire objekter bærer næsten hele risikoen. Bliv enige om deres felter, før du konfigurerer noget.

Skriv de tilladte statusovergange ned som en sekvens, f.eks. fra snavset til i gang til rent til inspiceret til klar, og hold dem enkle. Hver ekstra status er en tilstand, nogen skal oplæres i.

Hvordan ved du, om det virker?

Følg fem tal ugentligt i de første to måneder, og derefter månedligt:

• Procentdel af værelser, der tildeles automatisk frem for manuelt

• Gennemsnitlig tid for værelsesklargøring i forhold til udgangspunktet før integrationen

• Andel af gæsteanmodninger og vedligeholdelsesordrer, der fuldføres til tiden

• API-fejlrate og gennemsnitlig latenstid

• Opkald pr. vagt mellem reception og housekeeping

Den sidste er det tal, personalet mærker først. På tværs af Sweeplys kunder falder koordineringstiden typisk med omkring 20 %, og det er den kapacitet, projektet reelt frigiver.

Hvad går i stykker, og hvordan løser du det hurtigt?

Tre typer af fejl tegner sig for de fleste supportsager. Uoverensstemmelser i status, hvor PMS'et viser et værelse som klar, og housekeeping viser det som snavset, løses ved en daglig afstemningskørsel, der sammenligner begge værelseslister og markerer forskelle i stedet for at overskrive dem i det skjulte. Fejl ved levering af webhooks løses ved genforsøg med backoff plus den samme afstemning som et sikkerhedsnet. Leverandørers feltændringer efter en API-opdatering løses ved at versionsstyre din oversættelsestabel (mapping table), så du kan se, hvad der blev ændret, og rulle tilbage.

Sørg for at have en skriftlig eskaleringsprocedure, inklusive hvad din PMS-leverandør skal bruge fra dig for at undersøge sagen: tidsstempel, endpoint, anmodnings-id (request identifier) og det berørte værelse.

Hvornår 30 dage er den forkerte plan

Denne køreplan forudsætter betingelser, som ikke alle hoteller opfylder, og det er bedst at vide i uge nul.

• On-premise PMS uden API eller med betalt grænsefladeadgang. Integrationen kan stadig være værd at lave, men tidslinjen fastsættes af din leverandørs kommercielle proces, ikke af denne plan. Få tilbuddet på grænsefladen, før du planlægger andet.

• Flere PMS-forekomster på tværs af en koncern. Gennemfør det på ét hotel fra start til slut først. At køre fire hoteller på tre PMS-versioner parallelt gør en 30-dagesplan til et seksmåneders projekt.

• Meget små overnatningssteder. Under cirka 25 værelser med én rengøringsassistent vil en fælles opgaveliste give det meste af udbyttet, og et formelt integrationsprojekt er overflødigt besvær, du ikke har brug for.

• Hvor Sweeply ikke er svaret. Sweeply er et operationelt lag oven på PMS'et, ikke et PMS, en integrationsplatform eller en middleware-licens. Hvis det, du har brug for, er en universel datapipeline mellem økonomi-, kasse- og BI-systemer, er det et andet værktøj og et andet projekt.

Start samtalen om datakortlægning

Book et opkald med vores salgsteam med angivelse af dit PMS-navn og -version, dit værelsesantal og din ønskede go-live-dato. Vi bekræfter, at integrationen er understøttet, og fortæller dig, hvilke af de fire ovenstående objekter der kræver kortlægningsarbejde i dit tilfælde.