Bevezettünk egy foglalórendszert — három hónap múlva megmértük, ki használja tényleg

A rendszer elkészült, fut, és a hibás foglalásokat tényleg megfogja. Három hónap múlva viszont nem azt kérdeztük, hogy „működik-e”, hanem azt, hogy ki használja tényleg. A mérés kellemetlen számokat adott, és pont ezért érdemes elolvasni: a bevezetés nem telepítés.

Mit építettünk: közös erőforrás-naptár saját szerveren

Minden megosztott erőforrás kapott egy saját naptárat: a szervizállások, a tesztautók és a mosóállás külön-külön. Aki használni akarja valamelyiket, oda foglal — nem a saját naptárába, nem a falra, nem szóban.

A kiszolgáló a cégcsoport saját szerverén fut, szabványos naptár-protokollon, hogy a kollégák a megszokott naptár-alkalmazásukból lássák és foglalják az erőforrásokat. Nem kell új felületet megtanulni, és az adat nem kerül külső szolgáltatóhoz. Ez illeszkedik ahhoz, ahogy dolgozni szoktunk: a meglévő rendszerekre építünk, alapból csak olvasunk, és csak kifejezett kérésre, ellenőrzött módon írunk bele bármibe. A teljes folyamatot — audittól az üzemeltetésig — az AI-automatizálás útmutatónkban írtuk le.

A cél egyetlen mondat volt: egy erőforrásra egy időben egy foglalás. Az első éles hét megmutatta, hogy erre a dobozos naptár önmagában nem alkalmas.

Miért nem elég a dobozos naptár egy közös erőforrásra?

Azért nem elég, mert a dobozos naptár elfogadja az ütköző foglalást. A kiszolgáló mentéskor nem utasította el, ha az adott erőforrásra ugyanabban az idősávban már volt bejegyzés: a felület legfeljebb kijelezte, hogy ütközés van, a mentés viszont sikerült. Két egymást átfedő foglalás állt egymás mellett a naptárban, és másnap reggel derült ki, melyik a valódi.

Ezért készült egy szerver-oldali ütközés-őr: a mentés útjába épített ellenőrzés, ami minden beérkező foglalást összevet az erőforrás meglévő bejegyzéseivel. Ha átfedés van, a szerver elutasítja a mentést, és magyarul megindokolja — melyik erőforrás, melyik idősávban, meddig foglalt. Nem figyelmeztetés a képernyő sarkában, amit el lehet kattintani: a rossz foglalás egyszerűen nem jön létre.

Húsz nap alatt 296 hibás foglalási kísérletet utasított el automatikusan, emberi beavatkozás nélkül. Ez nem 296 elkerült botrány: van köztük ugyanannak a foglalásnak a többszöri újrapróbálása, és van, aki csak kipróbálta, mi történik. De mind a 296 olyan mentés, ami a régi működésben simán átment volna — és egy részüknél reggel két autó állt volna egy emelő alatt.

Prevenció vagy utólagos észlelés: melyik ér többet?

Ha a szabály gépileg eldönthető, a prevenció ér többet. Két minta létezik: a rendszer vagy megakadályozza a rossz adat keletkezését, vagy utólag jelenti, hogy baj volt.

Az utólagos észlelés olcsóbb és gyorsabban megépíthető: egy riport hétfő reggel kilistázza, hol volt ütközés a múlt héten. Csak épp a hét már lement, az ügyfél már várt, a kolléga már mentegetőzött. A prevenció drágább, mert be kell nyúlni a mentés útjába, és ott minden hibának azonnali üzemi következménye van — cserébe a hiba nem keletkezik meg, így nincs mit felderíteni és javítani.

Ugyanez a logika máshol is működik: a bejövő számlák feldolgozásánál a kötelezően lefuttatott matematikai ellenőrzés miatt a rossz összeg nem jut el a jóváhagyásig — 470+ feldolgozott számlán át ez a réteg tartja a rendszert.

A határ ott van, ahol a szabály nem gépi. Ha az ütközés feloldása emberi mérlegelés — soron kívüli javítás, kiemelt ügyfél, vezetői döntés —, akkor a szigorú tiltás árt: blokkolja a munkát, és megtanítja a kollégákat kikerülni a rendszert. Ott a helyes megoldás a jelzés plusz az emberi döntés, nem a tiltás.

Három hónap múlva megmértük: ki használja tényleg?

Három hónap után nem azt néztük, fut-e a rendszer, hanem azt, hogy kinek a kezében van. A mérés két szót írt a projekt fölé: működik és félkész.

• 249 erőforrás-foglalás 30 nap alatt. Valódi, napi használat — a rendszer nem áll üresen.
• 296 elutasított ütköző kísérlet 20 nap alatt. Az ütközés-őr dolgozik, és többet fog meg, mint amennyire számítottunk.
• A 47 munkatársi fiókból 22 (47%) egyszer sem lépett be. Nem ritkán használták: soha.
• 21% mobil-lefedettség a célzott 80% helyett. Aki a műhelyben dolgozik, nem ül monitor előtt.
• Az erőforrás-naptárak fele üresen állt. A foglalások a naptárak másik felére koncentrálódtak.

A legfontosabb mondat nem a számokban van, hanem mögöttük: a be nem lépő félnél a papír és a telefon maradt a rendszer. Két párhuzamos rendszer pedig rosszabb, mint egy. Aki a naptárban néz rá az emelőre, azt hiszi, szabad — közben a másik telephelyen valaki telefonon már odaígérte. Az ütközés-őr ezt nem tudja megfogni, mert az a foglalás soha nem érkezik be hozzá.

Így nézett ki a különbség aközött, amit a bevezetéskor feltételeztünk, és amit három hónap múlva mértünk:

Mit csinálnánk másképp legközelebb?

Négy dolgot — és egyik sem fejlesztés. A technikai rész készen volt; a bevezetés maradt félkész.

Szerepenkénti onboarding, nem közös bemutató

Egy közös bemutató negyvenvalahány embernek arra jó, hogy mindenki lássa a felületet. Arra nem, hogy másnap reggel használja is. Legközelebb szerepenként 15 perc: aki foglal, aki csak ránéz, aki adminisztrál — mindenki a saját napi mozdulatán végigvezetve, a saját eszközén, a saját erőforrásán.

Előbb a telefon, aztán a monitor

A műhelyben, a mosónál és a telephelyek között nincs asztal. Ha a telefonos beállítás nem két perc, nem lesz meg — a 21%-os mobil-lefedettség pontosan ezt mondja. Legközelebb a mobil a fő felület, a beállítás pedig nem házi feladat, hanem a bevezetés része: helyben, a kolléga telefonján, egyszer, közösen.

Az adopció legyen sikerkritérium

Az „elkészült” nem sikerkritérium. Sikerkritérium az, hogy a 47 fiókból 40 hat héten belül hetente legalább egyszer foglal. Ezt előre le kell írni, mérni kell hozzá, és az első hetekben heti egy sorban vissza kell jelezni a vezetőnek. Ez ugyanaz a fegyelem, amit ügyfél-oldalon is tartunk: az automata emlékeztetőknél is a visszaellenőrzött kézbesítés a bizonyíték, nem az, hogy „elküldtük”.

A régi csatornának legyen kivezetési dátuma

Amíg a papír és a szóbeli odaígérés is él, a papír nyer: gyorsabb, ismerős, és nem kér jelszót. A bevezetés akkor van kész, amikor a régi csatorna megszűnik — dátummal, vezetői döntéssel. Ez nem fejlesztői feladat, és magától soha nem történik meg.

Mikor nem éri meg foglalórendszert bevezetni?

Nem éri meg, ha kevés a közös erőforrás és kicsi a csapat. Egy telephely, egy-két megosztott gép vagy terem, öt-nyolc ember: ott egy közös naptár vagy egy tábla a falon ingyen megoldja ugyanezt, és nincs mit bevezetni.

A saját kezű út korrektül. Egy megosztott naptár — akár felhős, akár saját szerveres — sokáig elég:

• Amit tud: mindenki ugyanazt látja, telefonról is; a foglalás nyoma megmarad; ingyenes vagy filléres; egy délután alatt beállítható.
• Amit nem tud: mentéskor nem utasítja el az ütköző foglalást, csak jelzi; nincs erőforrás-szintű jogosultság (bárki bármit átír); és nincs mérés arról, ki használja tényleg.

Szintén ne kezdjen bele, ha:

• Nincs gazdája a bevezetésnek. Ha senki nem felel a betanításért és a régi csatorna kivezetéséért, a rendszer félig üresen fog állni. Pontosan ezt mértük.
• Ritka és olcsó az ütközés. Ha havonta egyszer fordul elő, és tíz perc a rendezése, a megtérülés nincs meg.
• A szabály nem gépi. Ha az ütközés feloldása mindig vezetői mérlegelés, a szigorú tiltás inkább akadály, mint segítség.

Ha viszont hetente megy el idő és pénz az ütközésekre, a döntést nem kell tippelni. A folyamat-audit fix 120 000 Ft, egy hét, és garanciás: ha nem találunk legalább öt megtérülő lehetőséget, visszajár — 60 napon belüli megrendelésnél pedig beszámít a projektárba. A megépítés 300 000 Ft-tól indul, az első működő automatizálás két héten belül élesben van, a felügyelet és a hibariasztás 30 000 Ft/hó-tól. Óradíj nincs.

Gyakori kérdések

Mennyibe kerül egy foglalórendszer bevezetése?

Nálunk fix áras. A folyamat-audit 120 000 Ft, egy hét, és garanciás: ha nem találunk legalább öt megtérülő lehetőséget, visszajár, 60 napon belüli megrendelésnél pedig beszámít a projektárba. A megépítés 300 000 Ft-tól indul, és az első működő automatizálás két héten belül élesben van. A felügyelet, a hibariasztás és a havi fejlesztési keret 30 000 Ft/hó-tól. Óradíj nincs.

Kötelező-e lecserélni a meglévő naptárat vagy ügyviteli rendszert?

Nem. A meglévő rendszerekre építünk: a kollégák a megszokott naptár-alkalmazásukban látják és foglalják az erőforrásokat, a szabályokat pedig a kiszolgáló oldalán érvényesítjük. A meglévő rendszerekből alapból csak olvasunk, írni csak kifejezett kérésre és ellenőrzötten írunk. Így nincs migráció, és nem kell mindenkinek új felületet betanulnia.

Hogyan mérhető, hogy tényleg használják-e a rendszert?

Négy szám elég hozzá. Hány fiókból volt egyáltalán belépés, hány foglalás születik hetente, ezek hogyan oszlanak meg az erőforrások között, és mekkora a mobilról érkező használat aránya. Ha bármelyik elmarad a bevezetéskor kitűzött céltól, nem a rendszer hibás, hanem a bevezetés félkész. Nálunk pontosan ez történt: a fiókok 47 százaléka sosem lépett be.

Meddig elég egy közös, megosztott naptár?

Egy telephelyig, néhány közös erőforrásig és nagyjából egy tucat emberig jellemzően elég, ráadásul ingyen van. A határ ott jön el, amikor a naptár mentéskor nem utasítja el az ütköző foglalást, nincs erőforrás-szintű jogosultság, és nincs mérés arról, ki használja. Ha ezek közül kettő is fáj, érdemes szerver-oldali szabályokban gondolkodni.

Mennyi idő alatt lesz működő rendszer?

A folyamat-audit egy hét, utána az első működő automatizálás két héten belül élesben van. A technikai rész tehát gyors. A bevezetés viszont nem: a szerepenkénti betanítás, a mobilos beállítás és a régi csatorna kivezetése hetekbe telik, és éppen ez a szakasz dönti el, hogy a rendszert használják-e egyáltalán.

Mi történik, ha valaki mégis ütköző időpontot foglal?

A szerver a mentés pillanatában elutasítja, és magyarul megindokolja: melyik erőforrás, melyik idősávban és meddig foglalt. A rossz foglalás így létre sem jön, nem kell utólag felderíteni és rendezni. Ebben a projektben húsz nap alatt 296 ilyen kísérletet fogott meg automatikusan az ütközés-őr, emberi beavatkozás nélkül.

A következő lépés

Ha Önöknél is van olyan gép, terem, jármű vagy szakember-idő, amin hetente veszekedés van, két szám elég a kiinduláshoz: hányszor fordul elő havonta, és mennyi időbe kerül egyszer. A megtakarítás-kalkulátorunk ebből megmutatja a nagyságrendet. Ha a szám érdemi, kérjen egy ingyenes 30 perces konzultációt — és egyetlen dolgot vigyen el ebből a cikkből: az adopciós célszám kerüljön bele a projekt sikerkritériumába, ne csak a rendszer átadása.