Kinek való: nagy események több idősávval

Use case 3

Nagy esemény szervezője: sok jelentkező, több idősáv, állandó mozgás

Amikor nem az a kérdés, betelik-e, hanem hogy mikor borul fel

Előtte: a folyamatos telítettség illúziója

Egy nagyobb esemény szervezése kívülről magabiztosnak tűnik.
Sok jelentkező.
Több idősáv.
Több terem.

„Meglesz ez.”

A valóságban azonban a szervező fejében egészen más kérdések futnak:

• „Ha most visszamond valaki, ki lép a helyére?”
• „Ha elfogadjuk a következőt, nem lesz-e ütközés?”
• „Ha több terem van, miért mindig ugyanaz telik be?”
• „Mi történik, ha az utolsó héten megindul a lavina?”

A nagy események sajátossága, hogy nem egyszer telnek meg, hanem folyamatosan átrendeződnek.

Az első jelentkezési hullám után jön:

• az átgondolás,
• a visszamondás,
• az újrajelentkezés,
• majd az utolsó pillanatos döntések.

A legtöbb rendszer ezt egy statikus pillanatként kezeli.
Mintha az esemény „kész lenne”.

Pedig ekkor kezd igazán élni.

A valódi probléma: a mozgás sebessége

Egy nagy eseménynél nem az a kihívás, hogy:

„Van-e elég érdeklődő?”

Hanem az, hogy:

„A rendszer képes-e követni a mozgást?”

Ha lassú:

• üres helyek maradnak,
• a várólista nem mozdul,
• a szervező kézzel avatkozik be.

Ha túl gyors:

• rossz ember kerül rossz idősávba,
• nő az elégedetlenség,
• nő a reklamáció.

A stabil működéshez ritmus kell.
Nem kapkodás.
Nem várakozás.

A szemléletváltás: rendszeres rendrakás, nem tűzoltás

Ebben a use case-ben a rendszer nem egyszer dönt, hanem folyamatosan figyel.

A működés alapja az, hogy:

• az esemény több idősávja és terme egymással összefüggő rendszer,
• nem különálló dobozok.

Amikor egy hely felszabadul:

• a rendszer először megnézi, hol van torlódás,
• kik azok, akik későn csatlakoztak,
• és hogy van-e lehetőség csendes átrendezésre.

Nem mindenkinél.
Nem mindenáron.
Csak ott, ahol ez nem okoz fennakadást.

Hogyan működik ez a gyakorlatban?

A nagy eseményeknél a rendszer rendszeres ciklusokban dolgozik.

Időről időre:

1. felméri a teljes esemény szerkezetét,
2. kiegyenlíti az idősávok és termek terhelését,
3. felszabadítja a valódi helyeket.

Ezután:

• a várólistán lévők rövid döntési idővel kapnak értesítést,
• csak akkor, amikor a hely tényleg elérhető,
• és elfogadáskor azonnal véglegesít.

Nincs többnapos lebegés.
Nincs „talán még befér”.

A rendszer pörget, de nem rohan.

Miért fontos a rövid döntési idő?

Egy nagy eseménynél a várólistán lévők:

• gyakran több eseményt is figyelnek,
• gyorsan döntenek,
• nem várnak napokig.

A hosszú gondolkodási idő itt nem kedvesség, hanem akadály.

Ezért a rendszer:

• világos határidőt ad,
• nem tart fenn látszólagos helyeket,
• és továbbmegy, ha nincs reakció.

Ez nem személytelenség.
Ez tisztelet a többiek ideje iránt.

Utána: mit lát az admin másnap reggel?

Nem azt, hogy:

• „megint hozzányúltam”.

Hanem azt, hogy:

• az idősávok arányosan teltek,
• nincs beragadt üres hely,
• a várólista mozgásban volt,
• nem kellett kézzel dönteni.

A szervező nem az eseményt tolja,
hanem felügyeli annak működését.

Ez a különbség a túlélés és az irányítás között.

Miért nem elég ehhez egy alap foglalórendszer?

Mert az alap rendszerek:

• egy eseményt egyben kezelnek,
• nem látnak rá az összefüggésekre,
• és nem tudnak ritmusban gondolkodni.

Ez a működés viszont:

• kezeli az eseményt, mint élő rendszert,
• felismeri a torlódásokat,
• és nem hagyja, hogy a mozgás káosszá váljon.

Ez nem gyorsabb.
Ez stabilabb.

Kinek való ez a működés?

Annak, aki:

• nagyobb eseményeket szervez,
• több idősávval vagy teremmel dolgozik,
• és nem akar az utolsó héten szétesni.

Ez már nem „foglaláskezelés”.
Ez esemény-irányítás.

Ehhez a működéshez az Enterprise csomag illeszkedik.
Nem azért, mert nagy eseményhez „kell a nagy csomag”,
hanem mert ilyen léptéknél csak ez ad nyugalmat.