HIBABEJELENTÉS ÉS TICKETING

Definíció

A hibabejelentés egy észlelt műszaki, szolgáltatási vagy használati probléma strukturált közlése az üzemeltetés felé. A bejelentésből a ticketing rendszerben önállóan azonosítható hibajegy, angol szóval ticket jön létre, amely a probléma teljes életútját végigkíséri a rögzítéstől a kivizsgáláson és a beavatkozáson át egészen a lezárásig.

Leírás

A hibabejelentés a napi Facility Management egyik legfontosabb információs belépési pontja. A bejelentő jelzi, hogy hol, mikor és milyen rendellenességet tapasztalt, a rendszer pedig a közölt adatokat egységesen rögzíti. A ticket sorszámot, időbélyeget és státuszt kap, ezért később pontosan követhető, hogy ki foglalkozott vele, milyen intézkedés történt, és mennyi idő alatt oldották meg.

A jó hibabejelentés nem feltétlenül hosszú. A megoldáshoz sokszor fontosabb a helyszín, az érintett eszköz, a hibakategória, a sürgősség és egy fénykép pontos rögzítése, mint egy terjedelmes szabad szöveges leírás. A bejelentési felület feladata ezért az, hogy a felhasználót gyorsan végigvezesse a szükséges adatok megadásán, miközben ne terhelje felesleges kérdésekkel.

A hibabejelentés és a munkalap nem feltétlenül ugyanaz. A hibabejelentés a problémát és az igényt rögzíti, míg a munkalap az elvégzendő vagy elvégzett szakmai feladatot dokumentálja. Egy bejelentésből több munkalap is keletkezhet, több azonos bejelentés pedig összevonható egyetlen javítási feladatba.

A hibabejelentés folyamata

A folyamat a bejelentés fogadásával és azonosításával kezdődik. Ezt követi a kategorizálás, a prioritás megállapítása, az illetékes személy vagy szolgáltató kijelölése, majd szükség esetén a munkalap létrehozása. A végrehajtás során a ticket státusza változik, a lezáráskor pedig rögzíthető a megoldás, a felhasznált anyag, a ráfordított munkaidő és a bejelentő visszajelzése.

A prioritás nem azonos a bejelentő türelmetlenségével. A helyes besorolást az üzleti hatás, a biztonsági kockázat, az érintett felhasználók száma, a szolgáltatás kiesése és a hiba sürgőssége alapján kell meghatározni. Egy csöpögő csap általában alacsonyabb prioritású, mint egy szerverterem hűtésének leállása vagy egy főbejárat hozzáférési hibája.

A lezárás sem pusztán egy státusz átállítása. Ellenőrizni kell, hogy a probléma valóban megszűnt-e, szükséges-e további intézkedés, történt-e ideiglenes megoldás, és értesült-e a bejelentő. Az újranyitott hibajegyek aránya fontos jelzés lehet a javítás minőségéről vagy a lezárási fegyelemről.

Facility Management

A Facility Managementben hibabejelentés érkezhet többek között épületgépészeti, villamos, beléptetési, takarítási, őrzés-védelmi, területhasználati vagy komfortproblémáról. A bejelentők lehetnek dolgozók, bérlők, recepciósok, műszaki üzemeltetők, automatizált felügyeleti rendszerek vagy akár külső szolgáltatók.

A központi helpdesk előnye, hogy a különböző csatornákon érkező igények egyetlen nyilvántartásba kerülnek. Telefon, e-mail, webes felület, mobilalkalmazás, QR-kód vagy automatikus riasztás egyaránt létrehozhat ticketet, de az ügy további kezelésének ugyanabban a követhető folyamatban kell történnie.

A hibabejelentési adatokból megállapítható, mely helyszíneken vagy eszközökön ismétlődnek a problémák, hol sérülnek az SLA-határidők, milyen hibák okozzák a legtöbb kiesést, és mely folyamatok igényelnek fejlesztést. A ticketing ezért nemcsak ügykezelés, hanem a karbantartási és szolgáltatási döntések fontos adatforrása is.

CAFM rendszerek

A CAFM-rendszerben a hibabejelentés közvetlenül összekapcsolható az épülettel, emeleti alaprajzzal, helyiséggel, eszközzel, szerződéssel, szolgáltatóval, SLA-val és munkalappal. Így nem különálló üzenetek vagy e-mailek keletkeznek, hanem kereshető, elemezhető és visszakövethető üzemeltetési adatok.

A rendszer automatikusan meghatározhatja az illetékes csoportot, kiszámíthatja a reakció- és megoldási határidőt, értesítéseket küldhet, eszkalálhatja a késedelmes ügyeket, és a bejelentőt is tájékoztathatja a változásokról. QR-kód vagy helyhez kötött bejelentőfelület alkalmazásával a helyszín és az eszköz adatai kézi keresés nélkül is kitölthetők.

A ticketing megbízhatósága az egyszerű használaton és az adatminőségen múlik. Ha túl sok kötelező mező lassítja a bejelentést, a felhasználók más csatornákhoz fordulnak. Ha viszont túl kevés adat kerül rögzítésre, az üzemeltetőnek kell visszakérdeznie, ami növeli a reakcióidőt. A jó CAFM-felület a bejelentő számára gyors, az üzemeltetés számára mégis elegendően strukturált.

Gyakorlati példa

A műszaki üzemeltetők részéről szinte mindig a legelsőként kért, legfontosabb funkció a ticketing. Nemigen beszélhetünk a hibák megoldásáról, amíg a hibákat nem jelentik be. Ezzel szemben, a vagyonkezelésre fókuszáló felhasználóinknak sokszor egyáltalán nincs szükségük erre, náluk a szerződések, bérlők, költségek és a pénzügyek körül forog a világ.

Ha pusztán a hibák bejelentése és nyomon követése a cél, erre számtalan egyszerű, dobozos Helpdesk szoftver is alkalmas. Mivel ezek a rendszerek általános célra készültek, egyáltalán nem biztos, hogy jól használhatók az ügyfél létesítményében. Sőt. Ahány fajta létesítmény, ahány üzemeltetési csapat, annyi különböző igény szokott felmerülni a hibabejelentéssel kapcsolatban. Egy sok épületből álló egyetemi kampusz esetén például a helyszín megadásánál biztos, hogy elvárás az ingatlan, épület, és azon belül a helyiség megadása, ahol a probléma felmerül. Egy kiskereskedelmi bolthálózat esetén viszont gyakran elég megadni, hogy melyik boltban van a probléma, nem kell vesződni épülettel és helyiséggel. Van, aki a bejelentésnél nem is csak egy helyszínt, de egy konkrét műszaki berendezést is ott akar látni a bejelentő űrlapon. Van aki szeretné, hogy a felhasználó megadhasson prioritást, van aki épp ellenkezőleg ezt kifejezetten megtiltja.

A klasszikus Helpdesk rendszerek elsődleges feladata általában a bejelentések fogadása, és a hibajavítás folyamatának követésé. Egy CAFM rendszer viszont a bejelentéseket kifejezetten FM műszaki üzemeltetési kontextusban értelmezi, így azok erősen kapcsolódnak Ingatlanokhoz, helyiségekhez, műszaki berendezésekhez. A javításoknak nem csak a ténye fontos, de a munkalapjai, részletei és a költségei is. Ezeket az adatokat a CAFM rendszer integráltan tárolja is, és ezekből végül tetszőleges KPI és egyéb statisztikákat is elő tud állítani.

Kapcsolódó fogalmak

A hibabejelentés szorosan kapcsolódik a helpdeskhez, a ticketinghez, a munkalaphoz, az SLA-hoz, a KPI-hoz, a CMMS-hez, a TMK-hoz, az Asset Managementhez, a BMS-hez és a CAFM-hez.

Az angol szaknyelvben az incident, a service request és a work order eltérő fogalmak. Az incident egy nem tervezett szolgáltatási zavar, a service request szabványos szolgáltatási igény, a work order pedig a végrehajtandó munka dokumentuma. A hétköznapi gyakorlatban ezek gyakran ugyanabban a ticketing rendszerben jelennek meg, de a pontos megkülönböztetés javítja a riportok és a folyamatok minőségét.

Érdekességek

A digitális hibajegyekre használt ticket szó eredetileg valóban egy kis papírlapot, címkét vagy igazolást jelentett. A sorszámozott papírcédulák régóta szolgálnak arra, hogy egy ügyet vagy egy sorban várakozó személyt egyértelműen azonosítsanak. A modern helpdesk- és ticketing rendszerek ugyanezt az alapelvet vitték tovább digitális formában: minden bejelentés saját azonosítót kap, és ez a „jegy” kíséri végig az ügyet a beérkezéstől a lezárásig.

Források

A hibabejelentési és szolgáltatáskezelési folyamatok értelmezéséhez az alábbi nemzetközi szabványok és szakmai források adnak támpontot:

• ISO 41001:2018 – Facility management – Management systems – Requirements with guidance for use – a Facility Management irányítási rendszerének követelményei.
• ISO 41011:2024 – Facility management – Vocabulary – a Facility Management nemzetközi terminológiájának alapja.
• ISO/IEC 20000-1:2018 – Information technology – Service management – szolgáltatásmenedzsment-folyamatok és követelmények.
• Online Etymology Dictionary – ticket – a ticket szó történeti jelentése és eredete.