Ismétlődő karbantartási ticketek SLA-hoz: havi/negyedéves automatizálás

SLA vs preventív PM — mi a különbség

A leggyakoribb félreértés: minden ütemezett munkát „preventív karbantartásnak” hívni. A gyakorlatban két külön dologról van szó. A preventív PM (preventive maintenance) eszközhöz kötődik: kenés 90 naponta, szűrőcsere 500 üzemóránként, kompresszor éves nagyjavítás. Az SLA-s ismétlődő ticket viszont szolgáltatáshoz, helyszínhez vagy szerződéses kötelezettséghez: havi telephelyi bejárás, negyedéves tűzvédelmi ellenőrzés-koordináció, havi facility checklist, heti biztonsági kör. Az eszköz lehet „nincs”, a határidő viszont kemény — mert a szerződés, az ügyfél vagy a hatóság méri.

Számokban: egy 80 gépes gyártósor PM-je tipikusan 80–200 ismétlődő eszközfeladat/hó (gépenként 1–3 intervallum). Ugyanazon cég facility SLA-ja 40 telephelyre havi bejárással: 40 ticket/hó, de mindegyik multi-lépéses checklist, 2–4 óra helyszíni munkával. A PM megfelelőségi KPI (pl. 92% időben) eszközpark-egészséget mér; az SLA ticket megfelelőség (pl. 98% határidőn belüli lezárás) ügyfél- és szerződéses kockázatot. Ha a kettőt egy Excel-oszlopba kevered, sem a diszpécser, sem a riport nem lesz tiszta.

A döntési szabály egyszerű: ha a kérdés „melyik gépen mi esedékes?”, preventív PM modul. Ha a kérdés „melyik telephely / ügyfél / szolgáltatás SLA-határideje jön el, és ki viszi a ticketet?”, ismétlődő SLA ticket. A SafetyPro-ban a preventív ütemezés és az ismétlődő ticket-szabályok külön logikán futnak — így a gép-PM nem keveredik a szolgáltatás-SLA-val, de mindkettő munkalapként zárul le, riportálhatóan.

Excel naptár bukási pontjai

A tipikus service- vagy facility-csapat „SLA naptára” egy közös Google Sheet vagy Excel: sorok = telephelyek, oszlopok = hónapok, cellában zöld/sárga/piros. 15 telephelyig ez még él; 40-nél már naponta 20–30 perc diszpécser-idő megy a frissítésre, és mégis elcsúszik 2–4 bejárás havonta. A rejtett költség nem a táblázat, hanem a lemaradt SLA: ügyfél-panasz, szerződéses büntetés, vagy egyszerűen elveszett bizalom a következő tenderen.

Az Excel öt tipikus bukási pontja: (1) nincs egyetlen igazságforrás — a terepi csapat más fájlt ment, mint a diszpécser; (2) a határidő nem kerül a ticket tárgyába, csak a cellába, így a technikus mobilról nem látja azonnal; (3) nincs automatikus generálás: valaki „majd hétfőn létrehozza” a 40 ticketet, és ha szabadságon van, semmi sem indul; (4) a lemaradás nem eszkalálódik — a piros cellát mindenki látja, de senki nem kap riasztást; (5) az auditnál a bizonyíték szétszóródik: fotók a Drive-on, checklist a e-mailben, lezárás a táblázatban.

Egy 40 telephelyes, havi bejárásos portfóliónál éves szinten 480 ticket keletkezik. Ha ebből csak 5% „elveszik” (24 ügy), és egy ügyfél-eszkaláció átlagosan 4 óra vezetői időt visz el, az már ~100 óra/év reaktív tűzoltás — plusz a reputációs költség. Az ismétlődő szabály pont ezt a 5%-ot vágja le: a ticket akkor is létrejön, ha a diszpécser szabadságon van.

• →Nincs single source of truth: több Excel-verzió, eltérő státuszok
• →Határidő nem a ticket tárgyában, csak a naptár-cellában látszik
• →Manuális ticket-generálás — szabadság / betegség = lemaradás
• →Nincs automatikus eszkaláció lejárt SLA esetén
• →Bizonyíték (fotó, checklist, aláírás) szétszórva, nem a munkalapon
• →Riport hó végén utólagos „színezés”, nem valós idejű megfelelőség

Ismétlődő szabály mezői

Az ismétlődő ticket lényege egy szabály (recurring rule): egyszer beállítod, a rendszer a ciklus szerint ticketeket generál. A szabály nem „emlékeztető naptárbejegyzés”, hanem munkalap-sablon + ütemezés + felelősség. Tipikus mezők, amiket érdemes rögzíteni: ciklus (heti / havi / negyedéves / éves, vagy egyedi N nap), következő esedékesség (due date), telephely vagy ügyfél, felelős (személy vagy csapat), prioritás, munkalap-sablon (checklist lépésekkel), és a tárgy sablonja — ideális esetben a határidő dátuma is bekerül a tárgyba, pl. „Havi bejárás – Telephely 12 – esedékesség: 2026-08-15”.

A due date szerkeszthető a szabályon: ha az ügyfél átütemezi a bejárást a hónap 20-áról a 25-ére, nem kell új szabályt írni, csak a következő esedékességet módosítani. A manuális generálás futásidővel (run time) is fontos: ha holnap indítanád a havi kört, de a szabály szerint csak 5 nap múlva jönne, futtathatod kézzel „most” — a rendszer a megadott futásidővel létrehozza a ticketeket, és a következő ciklust is frissíti. Így a diszpécser nem veszíti el a kontrollt, de nem is kell 40 ticketet kézzel másolnia.

Gyakorlati beállítás havi SLA-ra: 1 szabály / telephely (vagy 1 szabály sablon + telephely-szűrés, ha a sablon azonos), tárgyban due date, checklist 12–20 ponttal, felelős a regionális technikus, eszkaláció 24/72 órára. Negyedéves auditnál ugyanez, de 90 napos ciklus, hosszabb checklist (30+ pont), és vezetői eszkaláció már 48 óránál. A SafetyPro ismétlődő ticket-szabályai pontosan erre épülnek: szabály mezők, szerkeszthető due date, manuális generálás futásidővel, automatikus ticket a naptárban.

• →Ciklus: heti / havi / negyedéves / éves / egyedi nap-intervallum
• →Due date a szabályon — szerkeszthető, ha az ügyfél átütemez
• →Tárgy sablon due date-tel (a technikus mobilról is látja a határidőt)
• →Telephely / ügyfél / szolgáltatás hozzárendelés
• →Felelős személy vagy csapat + prioritás
• →Munkalap-sablon checklisttel (fotó / OK-NOK mezőkkel)
• →Manuális generálás futásidővel (run now) + automatikus következő ciklus
• →Eszkalációs lánc: felelős → diszpécser → vezető

Naptár nézet a diszpécsernek

A diszpécser nem „listában gondolkodik”, hanem kapacitásban: holnap hány bejárás, melyik régióban, ki ér rá. Az ismétlődő szabályok naptárnézete ezért nem dekoráció — hanem a heti tervezés alapja. Egy jól felépített naptár mutatja a közelgő generálásokat és a már létrejött ticketek due date-jét, telephelyenként vagy felelősönként szűrhetően. Így azonnal látszik, ha a hónap 3. hetére 18 bejárás esik, a 4. hétre pedig csak 4 — és át lehet ütemezni, mielőtt a csapat összeomlik.

A naptárnézet három réteget érdemes megkülönböztetni: (1) tervezett ismétlődés (a szabály következő futásai — még nincs ticket, de jönni fog); (2) nyitott ticket due date-tel (már kiosztott munka); (3) lejárt / eszkalált tételek kiemelve. Ha a diszpécser csak a „mai listát” nézi, a jövő heti túlterhelés csak akkor derül ki, amikor már késő. Heti 15 perces naptár-review elegendő: jövő 14 nap, ütközések, szabadságok, manuális generálás ha kell.

40 telephelynél a naptár nélkül a diszpécser tipikusan 25–40 percet tölt naponta „ki mit csinál holnap” tisztázással. Naptár + ismétlődő szabály mellett ez 5–10 percre csökken, mert a ticketek előre léteznek, a tárgyban a due date, a felelős már be van állítva. A maradék idő a kivételeké: eső miatti átütemezés, ügyfél zárva, beteg technikus — nem az, hogy „emlékszik-e valaki a 27. telephelyre”.

Eszkaláció ha lemarad

Az SLA értéke nem a ticket létrehozása, hanem a határidő betartása. Ha a ticket lejár, és senki nem kap jelzést, az ismétlődő rendszer csak drága emlékeztető. Az eszkalációt érdemes időablakokra bontani, nem „mindenkinek mindent” pusholni. Példa havi bejárásra (due date = hónap 15.): due előtt 3 nap emlékeztető a felelősnek; due napján ismétlés; due +1 nap diszpécser; due +3 nap regionális vezető; due +7 nap ügyfél-SLA riportba piros flag. Kritikus (pl. hatósági) feladatoknál a lánc rövidebb: due +24 óra már vezetői szint.

A mérés legyen egyszerű és heti: SLA ticket megfelelőség % = időben lezárt / esedékes. Cél service-csapatnál: ≥95% havi, ≥98% negyedéves (ritkább, de nagyobb tét). Ha a megfelelőség 90% alá esik, ne a „motivációs meeting” legyen az első lépés — nézd a naptárt: túlterhelt hét, hiányzó backup felelős, túl hosszú checklist, vagy rossz due date a szabályon. A lemaradt ticket oka 70%-ban kapacitás- és ütemezés-hiba, nem „lusta technikus”.

A lezárási minimum az eszkaláció ellenszere: ha a checklist + fotó + időbélyeg a helyszínen kötelező, a „késznek mondom, de nem dokumentálom” esetek csökkennek. A lejárt ticket ne tűnhessen el: maradjon nyitott, eszkalált státusszal, amíg le nem zárják — és a havi riportban jelenjen meg a lemaradás oka (kapacitás / ügyfél / időjárás / egyéb). Így a vezetőség nem sejti, hanem látja, hol csúszik az SLA.

• →Due −3 nap: emlékeztető a felelős technikusnak
• →Due nap: ismételt értesítés + naptár kiemelés
• →Due +1 nap: diszpécser / csapatvezető
• →Due +3 nap: regionális vagy service vezető
• →Due +7 nap: vezetői riport + ügyfél-SLA flag (ha szerződéses)
• →Heti KPI: időben lezárt ismétlődő ticketek aránya (≥95% cél)

Példa: 40 telephely × havi bejárás + checklist

Egy multi-site facility vagy service partner 40 telephelyen havi bejárást vállal SLA-ban: minden telephelyen 15 pontos checklist (külső/belső bejárás, gépészeti helyiség, menekülési útvonalak akadálymentessége, vészkijárat, világítás, hibajegyek felvétele). Egy bejárás átlag 2,5 óra + 30 perc utazás. Havi bruttó kapacitásigény: 40 × 3 óra = 120 óra — kb. 3 teljes munkaidős technikus-hét, ha egyenletes az eloszlás. Ha a hónap utolsó 5 napjára tolódik 25 bejárás, a csapat nem bírja, és az SLA 10–15%-a csúszik.

Beállítás ismétlődő szabályokkal: 40 szabály (vagy 1 sablon × 40 telephely-példány), ciklus havi, due date telephelyenként széthúzva a hónap 1–20. napjára (ne mind a 15-ére!), tárgy: „Havi bejárás – [telephely] – esedékesség: [dátum]”, sablon a 15 pontos checklisttel, felelős a 4 regionális technikus között elosztva (~10 telephely/fő). A naptárnézet mutatja a heti terhelést; ha egy hétre 14 bejárás esne, a due date-eket a szabályon átütemezed 2 perces munkával. Manuális generálás: ha a hónap elején előre akarod indítani a kört (pl. szabadságok miatt), futtatod a szabályokat a kívánt run time-mal.

Eszkaláció: due +1 nap diszpécser, due +3 nap vezető. Mérés hó végén: 40/40 lezárt? Időben? Átlagos lezárási idő a due-hoz képest? Hány hibajegy született a bejárásokból (ez a rejtett érték: a bejárás nemcsak „pipa”, hanem reaktív ticket-forrás). 3 hónap után tipikus eredmény: Excel-korszak 88–92% SLA megfelelőség → ismétlődő szabályokkal 96–99%, diszpécser napi admin 30 percről ~8 percre, és auditnál egy kattintás a lezárt munkalap + fotók. A preventív gép-PM ettől függetlenül fut a telephelyek eszközein — a havi bejárás SLA ticket, nem kompresszor-PM.

• →40 telephely × 1 havi bejárás = 40 ismétlődő ticket / hó (480 / év)
• →Due date-ek széthúzva a hónap 1–20. napjára (terheléskiegyenlítés)
• →15 pontos checklist + fotó kötelező lezáráskor
• →4 technikus × ~10 telephely, naptárnézet heti review-val
• →Cél: ≥98% időben lezárt havi bejárás, <10 perc diszpécser/nap a generálásra
• →Bejárásból nyitott hibajegyek külön reaktív ticketként — ne a bejárás-ticketen „elveszve”

Ö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.