Mit NE hagyj ki, ha időkapu rendszert tesztelsz?

2025. július 11.

Amikor egy cég időkapu rendszert tesztel, a figyelem legtöbbször az alapfunkciókra irányul: „Tudunk-e időpontot foglalni”, „Működik-e a bejelentkezés”, „Érkezik-e visszaigazolás”. Ezek fontos kérdések – de valójában nem ezek döntik el, hogy a rendszer éles környezetben beválik-e.

A legtöbb tesztelő nem gondol bele olyan apróságokba, mint hogy le tud-e zárni egy kaput délután kettőtől háromig, vagy hogy lehet-e rakodási típust megadni a foglalásnál. Ezek a részletek gyakran csak éles helyzetben tűnnek fel — amikor már késő.

Időszakos lezárások – a valóság nem mindig szabályos

Miért fontos?
A raktár nem gyártósor: jön egy kamion, és közben leáll a targoncás. Megcsúszik a reggeli műszak, vagy épp tűzvédelmi gyakorlat van.

Tesztkérdés: Le tudod zárni egy adott kaput csak jövő hét kedd 13:00–15:00 között úgy, hogy az ne okozzon zavart más kapuknál?

Miért fontos a teszt során?
Mert a legtöbb rendszer csak nyitvatartást kezel. Aki nem próbálja ki a lezárásokat, élesben fog rájönni, hogy nem tudja közölni a sofőrrel: „bocsi, ebédszünet”.

Részletes állapotok – ne csak „foglalva” legyen!

Miért fontos?
Egyetlen állapot, hogy „érkezik” vagy „foglalva” nem elég a portásnak, a diszpécsereknek, vagy a raktárvezetőnek.

Amit érdemes kipróbálni:
Tudsz-e különbséget tenni aközött, hogy bejelentkezett, elindult, megérkezett, rakodás alatt?
Testre szabhatók-e ezek az állapotok cégen belül?

Statisztika:
A rendszeresen használt állapotok száma átlagosan 3–5 egy jól működő időkapu rendszerben. Az, ahol csak „foglalva” és „kész” állapot van – jellemzően visszaesik a használata 1–2 hónap után.

Eltérő foglalási időtartam – mert nem minden fuvar egyforma

Gyakori hiba: A próbahónap során „mindent 30 perces blokkokban” próbálnak ki, mert az egyszerűbb.

A valóság:
egy 2 palettás furgon → 10 perc alatt lerakható,
egy ADR-es kamion → 1 órán át is tarthat.

Tesztkérdés: Be tudsz állítani kapura lebontva eltérő slothosszt?
Ha nem, előre borítékolható a túl- vagy alulterhelés.

Partner- vagy ügyfélszintű hozzáférés

Miért fontos?
A teszt során hajlamosak vagyunk „mindent magunknak foglalni”, de a valóságban a külső partnerek is belépnek majd.

Tesztkérdés:
Tudsz meghívni egy külsős szállítót, aki csak a saját fuvarját látja?
Korlátozható, hogy hova és mikor foglalhat?

Mi történik, ha nincs ilyen funkció?
→ A diszpécser továbbra is telefonon fog időpontot rögzíteni, ahelyett hogy kiszervezné a foglalást.

Változtatáskezelés – mi történik, ha módosít valaki?

Miért érdemes tesztelni:
Az egyik leggyakoribb éles problémát az okozza, hogy egy módosított időpont nem jut el a többiekhez. Pl. a diszpécser átteszi a fuvart délre, de a portás a kinyomtatott listát használja.

Tesztkérdés:
Frissülnek az adatok valós időben a különböző szerepköröknél?
Van-e naplózás (ki mikor mit módosított)?
Tud-e automatikus értesítést küldeni a rendszer a változásról?

Egyedi adatok – amit csak a ti cégeteknél kérdeznek meg

Tipp:
Tegyetek fel magatoknak egy kérdést:
„Van olyan adat, amit mindig megkérdezünk a fuvarról telefonon?”

Ha igen, azt érdemes beépíteni a rendszerbe kötelező mezőként.

• Lerakási határidő
• Sofőr neve
• Telefonos elérhetőség
• Raklap típus

Ha ezek nem kérhetők be foglaláskor, újra előkerül a telefon – vagy még rosszabb: az Excel.

Összefoglalás

A jó időkapu rendszer nem csak beenged, hanem átlát.

De ahhoz, hogy a próbahónap vagy pilot projekt valóban segítse a döntést, nem elég „kipróbálni” a felületet. Azt kell tesztelni, amitől élesben működni fog a rendszer:

• Tud kezelni kivételeket?
• Tud alkalmazkodni a járművek sokféleségéhez?
• Le tudja venni a terhet a diszpécser és portás válláról?

Tipp:
Tartsd szem előtt: az időkapu nem szoftver, hanem munkaszervezési eszköz.
Tesztelni csak akkor érdemes, ha a teszt a valóságról szól.