RM és adatminőség — governance, GIGO

Csütörtök reggel 8:05, május eleje, Hotel Peaqplus City. Dániel megnyitja a reggeli insight-listát (az 52. leckéből ismerős nézet), és az élén vastag betűs, kritikus besorolású állítás áll:

A corporate szegmens áprilisi termelése 40%-kal elmarad az előző hónapok átlagától — 400 helyett 240 szobaéj, a visszaesés március utolsó hetétől folyamatos, és a májusi same point összevetés is mélyülő lemaradást mutat.

A narratíva-réteg (53. lecke) hozzáteszi a magáét, gördülékeny mondatokban: „a corporate kereslet strukturális gyengülést mutat, javasolt a szerződéses partnerek aktivitásának felülvizsgálata és a vállalati szegmens célzott ösztönzése.” Az állítás átmegy az 52. lecke négy-elem tesztjén: van mi, van hol, van mikortól, van mihez képest. Dániel 8:40-re már egy akció-terv vázlatát írja a 10 órás meetingre: −15%-os „reaktivációs” kedvezmény a kulcs szerződéses partnereknek a teljes harmadik negyedévre, sales-kampány a top 10 vállalati ügyfélnél. A gép jelzett, az RM cselekszik — pontosan úgy, ahogy az 51. lecke munkamegosztása előírja.

Egyetlen dolog menti meg. Miközben a tervhez kigyűjti a ház-szintű számokat, feltűnik neki valami: az áprilisi foglaltság 72%, terv szerint, sőt egy hajszállal felette — a ház erős corporate-hetekre számított, és a szobák szintjén hozta is. Megáll a keze a billentyűzet fölött. Ha a corporate tényleg 160 éjszakát esett egy hónap alatt, annak látszania kellene a házban. Nem látszik. Akkor hova lett a volumen?

Ez a kérdés — nem az akció-terv — lesz a délelőtt legértékesebb munkája. Mert a corporate nem omlott össze. Az adat hazudott, mégpedig meggyőzően. Ez a lecke arról szól, hogy az expert szint minden eszköze — insight, narratíva, forecast, ár-ajánlás — egyetlen közös alapon áll: az adaton. És arról, hogyan védd ezt az alapot rendszerrel, nem szerencsével.

A GIGO-elv — a magabiztosan tévedő gép

A GIGO (garbage in, garbage out — szemét be, szemét ki) az informatika ősi alapelve: a legjobb algoritmus is torz eredményt ad, ha torz a bemenete. Az RM-ben ez az elv az AI-korszakban vált igazán veszélyessé — és éppen azért, mert az eszközök jók lettek.

Gondold végig, mi épül az adat-alapra az elmúlt hat leckéből. Az insight-réteg (52. lecke) a szegmens-bontott adatból emel ki állításokat; a narratíva (53. lecke) ezekből ír hihető szöveget; a gépi előrejelzés (55. lecke) a historikus szegmens-mintákból tanul; az ár-ajánlás (56. lecke) a forecastra épít. Egyetlen torz bemenet — egy rossz helyre könyvelt szegmens — végigfolyik a teljes láncon, és a lánc minden tagja felerősíti: az insight állítássá formálja, a narratíva történetté kerekíti, a forecast megtanulja, az ár-ajánlás pedig már döntési javaslatként adja vissza.

És itt a kulcs-különbség a régi és az új világ között: a rossz adat veszélyesebb, mint a hiányzó. A hiányzó adat látszik — üres cella, hibaüzenet, „nincs elég historikus adat” jelzés —, és óvatosságra int. A rossz adat viszont teljes értékűnek néz ki, a rendszer pedig nem kételkedik benne: ugyanolyan magabiztos mondatokat ír a torz számból, mint a helyesből. A gép nem tudja, hogy a bemenet szemét. Az RM pedig — minél jobb a rendszer, annál inkább — a rendszerben bízik. A meggyőzően tévedő gép és a gépben bízó ember párosa az, ami a szemét adatból éles döntést csinál.

Az 52. lecke baseline-vakság csapdája ennek enyhébb rokona volt: ott a viszonyítási alap torzított. Itt egy szinttel mélyebbre megyünk: maga a tény-adat hamis. A szabály pedig kiegészül: a meglepő insight első ellenőrzése a baseline-ja — a nulladik pedig az, hogy igaz-e egyáltalán az adat.

A négy klasszikus hiba-osztály

A hotel-adatvagyon torzulásainak nagy többsége négy osztályba sorolható. Mindegyiknek megvan a maga tipikus születési helye és tünete — érdemes név szerint ismerni őket, mert a diagnózis fele a felismerés.

Két észrevétel a táblához. Először: a négyből három konfigurációhoz és folyamathoz kötődik, nem technikai balesethez — vagyis megelőzhető. Másodszor: a hibák tünete szinte mindig átcsoportosítás, nem veszteség. A foglalás nem tűnik el, csak rossz fiókba kerül — a ház-szintű számok rendben vannak, miközben a szegmens-kép, amire az expert-eszköztár épül, már torz. A 15. leckében láttuk: a PMS a forrás-igazság, az RM elsődleges adatforrása — de az adat a CHM-en, a booking engine-en és a recepció kezén keresztül érkezik bele, és mindegyik kapunál el lehet rontani.

A számpélda — mit mutatott a rendszer, és mi volt a valóság

Nézzük meg számszerűen, mi történt Hotel Peaqplus Cityben. A ház áprilisi termelése 1 728 kiadott szobaéj (80 szoba × 30 nap × 72% foglaltság). A corporate szegmens stabil havi termelése 400 szobaéj, 85 EUR-os szerződéses átlagáron (ADR — average daily rate, átlagár).

Tavasz elején két dolog történt, egymástól függetlenül. Egy: a CHM-ben március 26-án lefutott egy frissítés, amely után a corporate negotiated rate plan új rate-kódot kapott — a PMS-oldali megfeleltetési tábla viszont a régi kódra mutatott, így a felismerhetetlen kódú foglalásokat a rendszer az alapértelmezett gyűjtő-szabálya szerint az „OTA – leisure” szegmensre könyvelte (1. hiba-osztály). Ezen az útvonalon a corporate-termelés CHM-en érkező része folyt át — havi 160 éj; a sales által kézzel rögzített többi 240 éj érintetlen maradt. Kettő: a sales február végén két új vállalati szerződést kötött, de a partnerek kódja nem került be a rendszerbe — az áprilistól érkező foglalásaik a webes motoron át az „egyéb” gyűjtőbe folytak (4. hiba-osztály).

Az eredmény áprilisra:

Gyors ellenőrzés: 400 − 160 = 240; 540 + 160 = 700; 15 + 75 = 90, ami 1 728 éj mellett 5,2% — és mindkét oszlop ugyanarra az 1 728-as ház-totalra összegződik. A rendszer tehát nem egyszerűen tévedett — az irányt fordította meg: a valóságban a corporate a hotel legszebben növekvő szegmense volt éppen, miközben a riport összeomlást jelzett.

És a torzítás tovább gyűrűzik. A májusi same point összevetés (18. lecke) a corporate-nál mély lemaradást mutat — hiszen az új foglalások egy része máshova könyvelődik. A gépi forecast (55. lecke) a torz áprilisi mintából tanulva a májusi corporate-ot 250 éj környékére teszi a valós ~475 helyett — a forecast-pontosság úgy romlik hónapokra, hogy a hiba forrása nem a modellben van. És mivel a forecastra ár-ajánlás épül (56. lecke), a hiba már a javasolt árakban is ott ül. Ráadásul a net ADR-számítás (43. lecke) is borul: a 160 átfolyt éjre a rendszer OTA-jutalékot feltételez, ami a valóságban nincs — a csatorna-költség-kép mindkét szegmensben hamis.

És most a legfontosabb szám: mibe került volna a rá épített döntés? Dániel akció-terve −15%-os kedvezményt adott volna a kulcs szerződéses partnereknek a teljes harmadik negyedévre — a top-partnerek negyedéves volumene nagyjából 800 szerződéses éj, és ez a volumen teljes áron is megérkezett volna, hiszen a kereslet nem gyengült, csak a könyvelése romlott el. A számla: 800 éj × 85 EUR = 68 000 EUR érintett bevétel, aminek a 15%-a 10 200 EUR közvetlen bevétel-veszteség — egy nem létező probléma megoldásáért. Plusz a nehezebben számszerűsíthető kár: a corporate szerződéses ár olyan horgony, amelyet lefelé mozdítani egy e-mail, visszaemelni egy éves újratárgyalás — ugyanaz az aszimmetria, amit a 44. lecke az árhídnál mutatott meg.

Az adatminőség-protokoll — négy réteg

A tanulság nem az, hogy „légy figyelmesebb” — a figyelem nem skálázódik. A tanulság egy protokoll, négy rétegben: rutin, változás-fegyelem, governance, audit-trail.

1. A havi ellenőrző rutin

Havonta egyszer, fix napon (praktikusan a hó zárása után, a riport-hónap „élesítése” előtt), egy rögzített checklist. Nem elemzés — egyeztetés: a cél nem az, hogy okos legyél, hanem hogy a számok stimmeljenek.

Ez a hat pont egy 80 szobás házban nagyjából egy óra havonta. A 2-es pont küszöbe külön figyelmet érdemel: az „egyéb” kategória sosem nulla — mindig van pár besorolhatatlan foglalás —, de az aránya és az iránya beszédes. A Peaqplus City-s példában a márciusi zárás még tiszta volt; az áprilisi 0,9% → 5,2% ugrás viszont önmagában riaszt — az insight-jelzéstől függetlenül, magyarázó állítás nélkül is.

2. Változás-fegyelem

A torzulások döntő többsége nem „romlik el magától” — változáskor születik: CHM-frissítés, új rate plan, új csatorna, PMS-verzióváltás, új booking engine. A szabály ezért egyszerű: minden konfigurációs változás után kötelező adat-ellenőrzés, nem a következő havi rutinnál, hanem 48–72 órán belül. A minimál-változat: a változás által érintett útvonalon 3-4 friss foglalás végigkövetése a csatornától a PMS szegmens-kódjáig. A március 26-i CHM-frissítés utáni első munkanapon egy ötperces szúrópróba — „hova könyvelődött a tegnapi corporate foglalás?” — az egész áprilisi torzulást megelőzte volna.

3. Governance — ki a gazdája az adatnak?

A rutin és a fegyelem csak akkor működik, ha van felelőse. Három elem:

• Data owner. Egy név — a Peaqplus Cityben Dánielé —, aki az adatvagyon minőségéért felel: ő futtatja a havi rutint, őt kell értesíteni minden PMS/CHM konfigurációs változásról még a változás előtt, és nála van vétó: megfeleltetési döntés nélkül új rate plan nem élesíthető. Nélküle az adatminőség mindenki felelőssége — azaz senkié.
• Kódolási szabálykönyv. Egy egyoldalas, írásban rögzített segment mapping dokumentum: mely szegmensek léteznek, melyik csatorna / rate plan / partner melyikbe tartozik, és mi a szabály a határesetekre (a walk-in céges vendég corporate vagy egyéni?). Ez zárja ki a 2. hiba-osztályt: ha a front office és a sales ugyanabból a lapból dolgozik, nem tud kétféleképpen kódolni. A dokumentum élő: minden új rate plan és szerződés felvételekor frissül.
• Belépési rituálé. Új csatorna, rate plan vagy szerződéses partner addig nem éles, amíg a megfeleltetési sora nincs beírva a szabálykönyvbe és a rendszerekbe. A példánk két kód nélküli szerződése pontosan ennek a lépésnek a hiánya: a sales megkötötte a szerződést, de a „és hova könyvelődik?” kérdést senki nem tette fel.

4. Audit-trail — a javítások nyoma

Amikor a hibát megtalálod, jön a kényes rész: a visszamenőleges javítás. A 160 éj átkódolása corporate-ra helyreállítja a jelent — de átírja a múltat: az áprilisi riport mostantól mást mutat, mint amit hetekig mindenki látott, és minden jövőbeli year-over-year összevetés ezen a javított számon fog állni. Ha a javítás nyomtalan, a historikus összevetések csendben borulnak: fél év múlva senki nem tudja, hogy az áprilisi corporate-számot utólag írták át, és miért.

Ezért a szabály: minden adat-javítás naplózva — mikor, ki, mit, miért, mekkora volumenben. Egy minta-bejegyzés: „máj. 6., D.: corporate +160 éj/hó visszamenőleg márc. 26-ig, CHM rate-kód megfeleltetési hiba; érintett riportok: áprilisi zárás + same point.” A napló mellé két gyakorlati elv: a javítást a teljes érintett időszakra egyszerre végezd el (a félig javított adat rosszabb, mint a következetesen torz — legalább a torzot lehet fejben korrigálni), és a gépi tanulási réteg gazdáját értesítsd: ha a forecast a torz hetekből már tanult, a javítás után újra kell tanulnia, különben a hiba a modellben él tovább akkor is, amikor az adatból már eltűnt.

A gyanú-reflexek — mikor kételkedj az adatban

A protokoll a rendszeres védelem. De kell a napi reflex is: mikor gyanakodj arra, hogy nem a piac mozgott, hanem az adat romlott el? Négy mintázat, amelynél az első kérdés mindig az adatminőség:

• Strukturális törés trend nélkül. A valódi kereslet-romlás lejtőn érkezik — hetek alatt épül fel, és jellemzően több jelben (pickup, foglalási ablak, compset) egyszerre látszik. A konfigurációs hiba lépcsőben érkezik: egyik napról a másikra, egyetlen metszetben. Ha a törés dátumához konfigurációs változás társítható (CHM-frissítés, rate plan-módosítás), a gyanú majdnem bizonyosság.
• Egy szegmens mozog, minden más áll. A −40%-os corporate mellett a ház-total rezzenéstelen — ez fizikailag azt jelenti, hogy a volumen nem eltűnt, hanem átkönyvelődött. A valódi szegmens-összeomlás a totálban is látszik; az átcsoportosulás csak a bontásban.
• A riport és a house count nem stimmel. Ha a szegmens-riport összege eltér a recepció aznapi valóságától — a házban 62 kiadott szoba van, a riport 65-öt összegez —, akkor nem elemzési, hanem adat-problémád van. Előbb egyeztetés, aztán elemzés.
• Kerek-szám és lehetetlen-érték anomáliák. 0 EUR-os ADR-ek szaporodása, pontosan duplázódó bevétel-sorok, jövő évi dátumra könyvelt tegnapi foglalás — ezek nem „furcsa piaci jelenségek”, hanem adathibák aláírásai.

Vedd észre, mi közös bennük: mindegyik olcsó — egyik sem igényel elemzést, csak egy odapillantást a totálra, a törés dátumára, a house countra. Az 50. lecke diagnózis-fájának technikai ága pontosan ez a reflex volt, dátum-szintre fordítva; az 52. lecke baseline-vakság szabálya pedig itt teljesedik ki: a meglepő insight ellenőrzési sorrendje adat → baseline → diagnózis. És ez nem a gép elleni bizalmatlanság, hanem az 51. lecke munkamegosztásának betartása: a rendszer azt mondja meg, mit mutat az adat; azt, hogy az adat igazat mond-e, csak te tudod megkérdezni — a gépnek nincs rá szerve.

Visszatérés a csütörtök reggelhez

Dániel délelőttje végül így alakult: a „hova lett a volumen?” kérdéstől tíz perc alatt jutott el az „egyéb” kategória 5,2%-áig és a két kód nélküli partnerig, onnan az OTA–leisure-be folyt corporate foglalásokig, és a CHM változás-naplója kiadta a március 26-i frissítést. A 10 órás meetingre nem a reaktivációs kedvezmény terve került, hanem három mondat: „A corporate nem esett, hanem nőtt — +19%. Az adat könyvelése romlott el egy CHM-frissítésnél, plusz két új szerződés kód nélkül futott. Javítjuk, és bevezetünk egy havi adat-ellenőrzési rutint.”

Ádám egyetlen kérdése — „és ha nem veszed észre?” — maga volt az aszimmetria-számítás. A döntés, amely majdnem megszületett, 10 200 EUR-ba került volna, plusz a lefelé mozdított corporate árszint többéves visszatárgyalásába. A protokoll, amely megelőzte volna: havi egy óra rutin, változásonként öt perc szúrópróba — évi nagyjából másfél munkanap. És a kár ráadásul láthatatlan maradt volna: a rossz döntés után a corporate „magához tér” (hiszen sosem volt beteg), az akció-terv sikeresnek látszik, és mindenki a rossz tanulságot tanulta volna meg.

A következő leckében (58.) a total revenue management mélyére megyünk — ahol a szoba-adat mellé F&B-, spa- és rendezvény-adat is belép a képbe. Vagyis még több adatforrás, még több kapu, ahol a szemét beszivároghat. Amit itt felépítettél, ott hatványozottan kell.

Kulcsüzenetek

• GIGO: az expert-eszköztár minden tagja az adat-alapra épül — insight, narratíva, forecast, ár-ajánlás egyetlen torz bemenetet is végigvisz és felerősít. A rossz adat veszélyesebb, mint a hiányzó: a hiányzó látszik, a rossz teljes értékűnek néz ki, és a gép ugyanolyan magabiztosan téved belőle, mint amilyen magabiztosan igazat mond a jóból.
• Négy hiba-osztály fedi le a torzulások zömét: CHM mis-mapping, inkonzisztens szegmens-kódolás, PMS-szinkron hibák, hiányzó kódok. Közös tünetük az átcsoportosítás: a ház-total stimmel, miközben a szegmens-kép már hamis.
• A számok ereje: a havi 400 éjes corporate-ból 160 éj rossz rate-kódra folyt, 75 éj új szerződéses volumen kód nélkül az „egyéb”-be — a rendszer −40%-ot mutatott, a valóság +19% volt. A rá épített pánik-kedvezmény 10 200 EUR-ba került volna; a megelőző protokoll évi másfél munkanap.
• A protokoll négy rétege: havi ellenőrző rutin (szegmens-összeg = total; „egyéb” < 3%; kód nélküli foglalások; megfeleltetés-szúrópróba; ADR-outlierek; duplikátumok) — változás-fegyelem (konfigurációs változás után 48–72 órán belüli ellenőrzés) — governance (data owner, írott segment mapping szabálykönyv, „megfeleltetés nélkül nincs élesítés”) — audit-trail (minden visszamenőleges javítás naplózva, különben a historikus összevetések csendben borulnak).
• A gyanú-reflexek olcsók: lépcsőszerű törés trend nélkül, egyetlen mozgó szegmens álló total mellett, riport–house count eltérés, lehetetlen értékek. A meglepő insight ellenőrzési sorrendje: adat → baseline → diagnózis — az „igaz-e az adat?” a nulladik kérdés, és ezt csak te teheted fel, a gép nem.