Duplikált munkalapok: offline és rossz hálózat elleni védelem

Honnan jön a duplikált munkalap a terepen

A tipikus forgatókönyv 15–40 másodperc: a technikus a gépházban lezárja vagy létrehozza a munkalapot, a gomb „tölt”, a válasz nem jön (liftakna, pince, fémfal, gyenge 4G). Újra nyom, vagy kilép és újra megnyitja a képernyőt. Amikor a hálózat visszaáll, a készülék — vagy a felhasználó — kétszer indítja el ugyanazt a mentést. Az irodában két azonos tartalmú munkalap jelenik meg, két ticket-kapcsolat, két számlázási jelölt.

A második forrás a dupla bejelentés: két ember ugyanarról a hibáról nyit jegyeket (portás + műszakvezető, e-mail + telefon), és a diszpécser mindkettőből indít munkalapot. Ez folyamat- és triage-hiba; a hálózati duplikátum viszont technikai: ugyanaz a szándék, kétszer a szerveren. A kettőt nem ugyanazzal a szabályal oldod meg — de mindkettő elrontja a KPI-t, a kapacitástervet és a megbízói bizalmat.

Számok, amiket 10–30 fős service vagy karbantartó csapatnál gyakran látni: heti munkalapok 3–8%-a „gyanúsan hasonló” (ugyanaz a telephely, eszköz, 5–15 percen belüli létrehozás). Ebből 40–60% a flaky hálózat / dupla koppintás, a többi párhuzamos bejelentés vagy elavult sablon. Egy-egy duplikátum 10–25 perc diszpécser-idő (összefűzés, státusz, ügyfél-üzenet), heti 5–15 ilyen tétel = fél–egy műszak adminisztráció — plusz a kockázat, hogy két szerelő megy ki ugyanarra a címre.

• →Lassú vagy elveszett válasz → technikus újra nyom
• →Offline mentés + későbbi szinkron kétszer fut le rossz queue-val
• →App újraindul / crash a mentés közben → második kísérlet
• →Párhuzamos bejelentés (emberi) vs. ugyanaz a kérés kétszer (technikai)

Mi az az idempotency key — egyszerűen

Az idempotency key (ismételhetőségi kulcs) egy egyedi azonosító, amit a telefon generál a mentés gomb megnyomásakor — még a hálózati válasz előtt. Minden létrehozási vagy lezárási kéréshez tartozik egy ilyen kulcs. A szerver megjegyzi: „ezt a kulcsot már láttam, ugyanezt a munkalapot adom vissza, nem nyitok újat.” Ha a technikus kétszer nyom, vagy a queue kétszer küldi el ugyanazt a csomagot, a második kérés nem második sort szül.

Gyakorlati metafora: a kulcs a „kasszaszalag-sorszám” a rendelésen. Ha a pincér kétszer beadja ugyanazt a cédulát, a konyha nem főz kétszer — mert a sorszám már megvan. A kulcs a kliensen születik (UUID vagy hasonló), nem a szerveren: így offline is létezik, mielőtt bármi feltöltődne. A SafetyPro-szerű CMMS-ben ez a létrehozás és a kritikus állapotváltások védelme: egy szándék = egy munkalap.

Mit nem old meg önmagában: ha a technikus szándékosan két külön munkát indít (reggeli diagnózis + délutáni javítás alkatrésszel), két kulcs, két munkalap — ez helyes. Az idempotency a véletlen ismétlést állítja meg, nem a több kiszállásos láncot. A diszpécsernek továbbra is kell a merge / összefűzés a két különböző bejelentésnél; a kulcs a gomb-duplázást és a retry-t fogja meg.

• →Kulcs a mentés pillanatában a mobilon keletkezik
• →Szerver: ugyanaz a kulcs → ugyanaz a rekord, nem új sor
• →Offline is működik, mert a kulcs nem a térerőtől függ
• →Szándékos második munkalap = új kulcs (külön kiszállás)

Offline queue: az elutasított kérést ne próbáld újra

Az offline queue a telefon „postafiókja”: ami hálózat nélkül készült, vár, amíg fel lehet tölteni. A leggyakoribb hiba a naiv újrapróbálás: ha a szerver 4xx-szel elutasít (validációs hiba, jogosultság, lezárt ticket, már létező kulcs ütközés rossz kezeléssel), a queue percenként újra küldi ugyanezt a hibás csomagot. Eredmény: zaj a naplóban, felesleges terhelés, és néha — ha a hiba átmeneti volt és a payload közben „javul” — váratlan másodpéldány.

Helyes szabályok egyszerűen: (1) hálózati hiba / timeout / 5xx → retry, backoff-fal (pl. 5 s, 15 s, 1 perc), nem azonnal tucatszor; (2) 4xx üzleti elutasítás (hiányzó kötelező mező, lezárt jegy, jogosultság) → ne retry; jelöld a tételt hibásnak a UI-on, a technikus javítson vagy a diszpécser döntsön; (3) sikeres válasz vagy „már feldolgozott” idempotency válasz → vedd ki a queue-ból, ne küldd újra; (4) sorrend: ha A munkalap kell B lezárásához, ne indítsd B-t, amíg A nincs elfogadva.

A felhasználói üzenet legalább annyira fontos, mint a technika. „Nincs térerő — a munkalap a készüléken van, szinkronizál, amint van hálózat” = nyugodt technikus. „Hiba — nem mentődött, próbáld újra” timeoutnál = újabb koppintás és duplikátum-kockázat. A UI mutassa: várakozik a szinkronra / sikeres / elutasítva (miért). Az elutasított tétel ne legyen „láthatatlan piros” a háttérben: a heti 2–5 ilyen eset 80%-a mező- vagy jogosultság-hiba, 20% valódi rendszerhiba — mindkettőhöz kell látható állapot.

• →Timeout / hálózat / 5xx → backoff-os retry
• →4xx üzleti elutasítás → stop, ne queue-loop
• →Siker vagy „már megvan” (idempotent) → kivesz a queue-ból
• →Technikus látja: vár / kész / elutasítva + ok

Mit lát a diszpécser, ha a védelem működik

Jól működő rendszerben a diszpécser nem „párosítgat” reggel 20 percig hasonló munkalapokat. Ha a technikus kétszer nyomott, egy munkalap van a listán; a második kérés ugyanazt az azonosítót adja vissza. Ha offline mentett, a tétel először „szinkronra vár” a mobilján, majd egy sorban megjelenik az irodában — nem kettőben. A ticket–feladat–munkalap lánc egy ágon marad.

Mérhető jelek 30 nap alatt: a „5 percen belüli, ugyanarra az eszközre nyitott második munkalap” aránya 3–8%-ról 0,5% alá csökken, ha a kulcs és a queue rendben van. A maradék tipikusan emberi: két bejelentő, két szándék. A diszpécser ideje a merge-re a technikai duplázás helyett a valódi összefűzésekre megy. A kapacitásterv is tisztább: nem tervezel két embert ugyanarra a „dupla” sorra.

Ha a védelem nincs meg, a tünetek: „ma reggel 12 munkalap, de csak 9 volt valós munka”; két PDF ugyanarról a javításról a megbízónak; számlázandó lista, ahol ugyanaz a tétel kétszer szerepel. A back-office „majd kézzel javítjuk” rutin heti 1–3 óra — és a hiba aránya nem csökken, mert a gyökér a kliens–szerver ismétlés, nem a figyelmetlenség.

Gyakorlati ellenőrzőlista: véd-e a te rendszered

Pipáld végig a saját CMMS / service appoddal — ideális esetben a szállítóval vagy a belső fejlesztéssel együtt. Ha 3-nál több „nem”, a terepi duplikátum nem „majd egyszer” probléma: heti üzemeltetési költség. A legtöbb modern rendszer tud idempotens létrehozást; a gyenge pont gyakran az offline queue és a hibakezelés UI-ja.

• →A mobil generál egyedi kulcsot minden létrehozás / lezárás mentésénél?
• →Ugyanazzal a kulccsal kétszer küldve a szerver egy rekordot ad vissza?
• →Offline kitöltés után a szinkron nem hoz második munkalapot újraindítás után sem?
• →4xx elutasítás után a queue nem próbálkozik automatikusan újra?
• →Timeout esetén a technikus látja a „várakozik / szinkron”, nem csak „hiba, próbáld újra”?
• →Van látható lista a sikertelen / elutasított offline tételekről?
• →Mérhető a 5 percen belüli gyanús párhuzamos munkalapok aránya?
• →Ticket–munkalap láncban a merge emberi döntés, a technikai retry nem nyit új sort?

Mit tegyetek holnap reggel a csapattal

Technikai bevezetés nélkül is van 48 órás haszon. Diszpécser: naponta 5 perc szűrés — ugyanaz a telephely + eszköz, 10 percen belüli két nyitás → azonnali merge szabály. Technikus: ha a gomb „tölt”, ne nyomj újra; várj a „szinkronra vár / mentve” állapotra. Ops: jegyezzétek fel egy hétig a kézzel összefűzött párokat — ha 5 felett van, a szoftvervédelem ROI-ja egy műszak adminisztráción belül megvan.

Ha a SafetyPro (vagy hasonló CMMS) már fut: kérdezzétek meg / ellenőrizzétek a mobil offline viselkedést a pincében és a gépházban, ne csak az irodai Wi-Fi-n. Egy 20 perces terepi próba (repülőgép mód → kitöltés → hálózat vissza → egy munkalap?) többet mond, mint egy feature-lista. A digitális napló és a ticketing csak akkor tiszta, ha a munkalap-létrehozás egy szándékot egy sorral képvisel.

Hosszabb táv: a duplikátum-arány legyen heti KPI a service desk / karbantartás vezetői dashboardon — cél: technikai dupla < 0,5%, emberi párhuzamos bejelentés külön mérve és merge-elési rutinnal. Így a hálózat minősége nem diktálja a master adat minőségét.

Összegzés és következő lépés

A cikkben összefoglalt gyakorlati lépések akkor működnek tartósan, ha egy központi rendszerben futnak a munkalapok, az eszköznyilvántartás, a preventív ütemezés és — ahol kell — a tűzvédelmi ellenőrzések is. A szétszórt Excel-fájlok és papír naplók hosszú távon nem adják az auditálhatóságot és a valós idejű átláthatóságot.

A SafetyPro CMMS ezeket egy platformon egyesíti: QR/NFC azonosítás, mobil app offline módban, riportok és emlékeztetők. A Basic csomag 24 900 Ft/hó-tól indul; 14 napos ingyenes próba egyeztethető személyesen, a bemutató után.

Ha a témában leírt folyamatokat szeretnéd élesben látni a saját telephelyed példáján, kérj bemutatót — az értékesítési csapat általában 1 munkanapon belül válaszol.