Kinek való: szűk kapacitás, sok jelentkező

Use case 11

Szűk kapacitás, sok jelentkező

Amikor gyorsan kell dönteni – de nem lehet önkényesen

Előtte: amikor minden felszabaduló hely túl nagy jelentőséget kap

Vannak szolgáltatások, ahol a kapacitás eleve szűk.
Kevés időpont.
Sok érdeklődő.
Hosszú várólista.

Itt minden felszabaduló hely „esemény”.

Az admin fejében ilyenkor ezek a kérdések futnak:

• „Kinek adjuk?”
• „Ki vár régóta?”
• „Ki jelezte már korábban, hogy rugalmas?”
• „Ha most ő kapja, nem lesz-e ebből később vita?”

A nyomás nagy, mert:

• a hely gyorsan elkelne,
• de a döntés látható és megjegyezhető.

Egy rossz lépés:

• bizalmatlanságot szül,
• „kivételezés” érzetét kelti,
• és újabb magyarázkodási köröket indít el.

A valódi probléma: gyors döntés ≠ jó döntés

Szűk kapacitásnál az admin gyakran két rossz opció között választ:

1. Gyors feltöltés
• aki épp elérhető, kapja,
• a várólista mozog,
• de az igazságosság sérül.
2. Hosszas mérlegelés
• mindenki szempontja számít,
• a döntés védhető,
• de a hely közben üresen áll.

A legtöbb rendszer csak az elsőt tudja.
A kézi admin inkább a másodikat próbálja.

Ez a use case ott jön létre, ahol mindkettőre szükség van.

A szemléletváltás: a gyors döntést is lehet szabályossá tenni

Ebben a működésben a rendszer nem választ személyesen,
de nem is késlekedik.

Amikor felszabadul egy hely:

• nem több embernek jelez egyszerre,
• nem indít versenyt,
• és nem hagy bizonytalanságot.

A rendszer:

• előre rögzített, igazságos logika alapján halad,
• sorban kezeli a jelentkezőket,
• és egyértelmű helyzetet teremt.

A gyorsaság nem kapkodásból fakad,
hanem abból, hogy nincs mit újra eldönteni.

Hogyan működik ez a gyakorlatban?

Amikor a havi tervezés vagy újraosztás során kiderül, hogy:

• csak kevés szabad hely van,
• de sok az igény,

a rendszer:

1. figyelembe veszi, kinek van már végleges helye,
2. kizárja azokat az időpontokat, ahol nincs valódi kapacitás,
3. majd a fennmaradó helyeket sorban kiosztja.

Nem ígér többet, mint amennyi van.
Nem generál „majd meglátjuk” állapotot.

Aki helyet kap:

• azonnal végleges státuszba kerül,
• nem marad kérdőjel.

Aki nem:

• tudja, hogy miért nem,
• és hol áll a sorban.

Ez a gyorsaság nem sért, mert érthető.

Miért fontos, hogy itt nincs lebegő állapot?

Mert szűk kapacitásnál a lebegés:

• hamis reményt kelt,
• növeli a frusztrációt,
• és megnehezíti a kommunikációt.

Ebben a működésben:

• vagy van hely,
• vagy nincs,
• és ez azonnal kiderül.

Ez nem ridegség.
Ez korrektség.

Mit lát az admin a hónap végén?

Mielőtt a következő időszakot tervezné, ezt látja:

• a kevés hely mind betöltött,
• nem volt versenyhelyzet,
• nem kellett utólag visszavonni döntést,
• és nem keletkezett „kinek miért ő jutott” típusú vita.

A rendszer:

• gyors volt,
• de nem önkényes.

Az admin nem érzi azt, hogy „szerencsén múlt”.
Érzi, hogy rend volt.

Miért nem működik ez egy hagyományos foglalórendszerrel?

Mert az alap rendszerek:

• vagy túl sokat engednek,
• vagy túl keveset látnak,
• és nem tudják kezelni a ritka, értékes helyeket.

Ez a működés viszont:

• egyszerre látja a teljes igényhalmazt,
• tiszteletben tartja a meglévő foglalásokat,
• és nem hagy teret a hibának.

Ez már nem időpontkezelés.
Ez kapacitásvédelem.

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

Annak, aki:

• szűk kapacitással dolgozik,
• sok jelentkezést kezel,
• és nem engedheti meg, hogy egyetlen döntés is vitatható legyen.

Egyetlen naptár esetén
ez Pro szint.

Több szolgáltatás vagy naptár párhuzamos tervezésénél
ez már egyértelműen Enterprise működés.