Incidenskezelési adatsablon
Incidenskezelési adatsablon
Ez a(z) Incidenskezelés folyamathoz készült általános process mining adatsablonunk. Részletesebb útmutatásért használja a rendszerspecifikus sablonokat.
Válasszon egy konkrét rendszert- Bármely incidenskezelő rendszerhez használható általános adatszerkezet
- Javasolt attribútumok és tevékenységek a részletes elemzéshez
- Útmutató az adatkinyeréshez, rendszerspecifikus példákkal
Az incidenskezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időbélyege EventTimestamp | Az incidenshez kapcsolódó konkrét tevékenység vagy esemény pontos dátuma és időpontja. | ||
| Leírás Az esemény időbélyege pontosan jelzi, mikor történt egy tevékenység. Az incidens életciklusának minden tevékenységéhez időbélyeg szükséges az események időrendi sorrendjének megállapításához. Ez az attribútum minden időalapú process mining elemzéshez elengedhetetlen. Segítségével kiszámítható a tevékenységek közötti átfutási idő, az egyes lépések időtartama és az incidens teljes megoldási ideje. Az időbélyegek elemzésével a szervezetek azonosíthatják a szűk keresztmetszeteket, mérhetik az SLA-k betartását, és nyomon követhetik a folyamat teljesítményének változását. Az olyan fontos teljesítménymutatók kiszámításának is ez az alapja, mint az átlagos megoldási idő. Miért fontos? Megadja az események időrendi sorrendjét, ami elengedhetetlen az időtartamok kiszámításához, a szűk keresztmetszetek azonosításához és a folyamat teljesítményének időbeli elemzéséhez. Hol szerezhető be? Eseménynaplókban, auditelőzményeket tartalmazó táblákban, illetve az egyes kapcsolódó rekordok „last modified” vagy „creation date” mezőjében található. Példák 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| Incidensazonosító IncidentId | Az egyes incidensekhez rendelt egyedi azonosító. Ez az azonosító szolgál elsődleges kulcsként az incidens teljes életciklusának nyomon követéséhez. | ||
| Leírás Az incidensazonosító egyedi alfanumerikus kód, amely megkülönbözteti az adott incidenst a rendszer összes többi incidensétől. Az új incidens létrehozásakor jön létre, és változatlan marad, amíg az incidenst véglegesen nem archiválják vagy törlik. A process mining elemzésben az incidensazonosító az elemzés alapja, ez szolgál Case ID-ként. Segítségével a szoftver egyetlen folyamatpéldányba rendezi az összetartozó eseményeket, állapotváltozásokat és tevékenységeket. Ha minden eseményt a közös incidensazonosító alapján csoportosítanak, az elemzők pontosan feltérképezhetik az egyes incidensek teljes útját a bejelentéstől a megoldásig és lezárásig. Miért fontos? Az összetartozó tevékenységek és események összekapcsolásával rekonstruálható az incidens teljes életciklusa a process mining elemzéshez. Hol szerezhető be? Ez az incidens elsődleges kulcsa, amely jellemzően minden incidenseket tartalmazó tábla vagy objektum fejlécében, illetve fő rekordjában található. Példák INC0010032TICKET-84321789456123 | |||
| Tevékenység neve ActivityName | Az incidens életciklusa során végrehajtott konkrét üzleti tevékenység, esemény vagy állapotváltozás neve. | ||
| Leírás A tevékenység neve az incidenskezelési folyamat egy-egy jól elkülöníthető lépését vagy feladatát jelöli. Ezek a tevékenységek alkotják a folyamattérkép építőelemeit. Lehetnek automatikus rendszeresemények, például „SLA-sértés észlelve”, vagy felhasználói műveletek, például „Ügyintéző hozzárendelve” vagy „Kerülő megoldás biztosítva”. Ez az attribútum alapvető a process mining elemzéshez. Meghatározza a folyamatgráf csomópontjait, így az elemzők megjeleníthetik a munkafolyamatot, azonosíthatják a gyakori útvonalakat és a szűk keresztmetszeteket, valamint feltárhatják a standard eljárástól való eltéréseket. A tevékenységnevek részletessége és egyértelműsége közvetlenül befolyásolja a levonható következtetések minőségét és mélységét. Miért fontos? Ez az attribútum határozza meg a folyamat lépéseit, így megjeleníthető és elemezhető az incidens életciklusa. Hol szerezhető be? Gyakran eseménynaplók, auditnyomok, állapotváltozási rekordok vagy az incidenskezelő rendszer feladatleíró mezőinek kombinációjából származik. Példák Incidens létrehozásaCsoport hozzárendeléseIncidens megoldvaÁllapotváltás függőben lévőre | |||
| Forrásrendszer SourceSystem | Annak a rendszernek a neve vagy azonosítója, amelyből az incidensadatokat kinyerték. | ||
| Leírás A forrásrendszer attribútum azonosítja az adatok eredetét. Több ITSM-eszközt vagy integrált rendszert használó környezetben ez a mező segít megkülönböztetni a különböző forrásokból származó rekordokat. Bár közvetlenül nem használják a folyamattérkép elkészítéséhez, ez az attribútum hasznos az adatok ellenőrzéséhez és irányításához. Segít az elemzőknek visszakövetni az adatokat a forrásukig, megérteni a rendszerek közötti eltéréseket és részekre bontani az elemzést. Például összehasonlíthatók ugyanazon szervezet ServiceNow- és Jira-rendszerében megvalósított incidenskezelési folyamatok. Miért fontos? Megmutatja az adatok eredetét, ami több rendszert használó környezetben fontos az adatok ellenőrzéséhez, a hibakereséshez és az összehasonlító elemzéshez. Hol szerezhető be? Ez gyakran az adatkinyerés során hozzáadott statikus érték, vagy a forrásrendszer tábláiban elérhető mező. Példák ServiceNowJira Service ManagementBMC HelixZendesk | |||
| Utolsó adatfrissítés LastDataUpdate | Az az időbélyeg, amely megmutatja, mikor frissítették utoljára a rekord adatait a forrásrendszerből. | ||
| Leírás Az utolsó adatfrissítés időbélyege jelzi, mikor nyerték ki vagy szinkronizálták legutóbb az adatokat a forrásrendszerből. Ez a metaadatmező az elemzett adatok aktualitását mutatja. A process mining elemzésben ez az attribútum segít megítélni, mennyire naprakészek a kapott eredmények. A felhasználók így tudják, hogy valós idejű adatokat vagy egy korábbi időpontban készült pillanatképet látnak. Ez a háttér-információ fontos a működés nyomon követéséhez és ahhoz, hogy a döntések aktuális, releváns adatokon alapuljanak. Miért fontos? Jelzi az adatok aktualitását, így az elemzők tudják, mennyire naprakész a folyamat elemzése. Hol szerezhető be? Ezt az értéket rendszerint az adatkinyerés és -átalakítás (ETL) során állítják elő, majd rögzítik minden rekordban. Példák 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
| Bejelentési csatorna ReportingChannel | Az a módszer vagy csatorna, amelyen keresztül az incidenst bejelentették, például e-mailben, telefonon vagy az önkiszolgáló portálon. | ||
| Leírás A bejelentési csatorna megmutatja, honnan érkezett az incidensbejelentés. Ez az attribútum nyomon követi, hogyan veszik igénybe a felhasználók a támogatást, akár közvetlenül, például telefonhívással, akár automatikusan, például rendszerfelügyeleti riasztással. A folyamat bejelentési csatorna szerinti elemzése fontos hatékonyságbeli különbségeket tárhat fel. Az önkiszolgáló portálon bejelentett incidensek például gyorsabban megoldhatók, mert a bejelentés gyakran már kezdetben strukturáltabb információkat tartalmaz. Az elemzés segít optimalizálni a támogatási csatornákat és ösztönözni a hatékonyabb módszerek használatát. Miért fontos? Segít elemezni, hogy a bejelentés forrása szerint mennyire hatékony az incidenskezelés, és milyen megoldási útvonalakat követ. Az eredmények alapján megtervezhető a csatornák használata és az erőforrások elosztása. Hol szerezhető be? Ezt az információt általában automatikusan rögzíti a rendszer, vagy az ügyintéző választja ki az incidens létrehozásakor. Példák E-mailTelefonÖnkiszolgáló portálRendszerriasztás | |||
| Hozzárendelt csoport AssignedGroup | Az a támogatási csapat, várólista vagy csoport, amely jelenleg az incidens kezeléséért felel. | ||
| Leírás A hozzárendelt csoport megmutatja, hogy egy adott időpontban melyik csapat felel az incidensért. Az incidensek gyakran kerülnek át különböző csoportokhoz, például az első szintű Service Deskhez, a második szintű hálózati csapathoz vagy a harmadik szintű alkalmazástámogatáshoz. Ez az attribútum fontos az átadások és a munkaterhelés elemzéséhez. A process mining segítségével megjeleníthető, hogyan kerülnek át az incidensek a csapatok között, mérhető az egyes csapatok várólistáján töltött idő, és azonosíthatók a gyakori újra-hozzárendelések okozta szűk keresztmetszetek. Segít megválaszolni a csapatok hatékonyságával és együttműködésével kapcsolatos kérdéseket, és alapul szolgál az átadások és újra-hozzárendelések elemzésére szolgáló dashboardhoz. Miért fontos? Nélkülözhetetlen a csapatok közötti átadások, a várakozási idők, valamint az egyes csapatok teljesítményének és munkaterhelésének elemzéséhez. Hol szerezhető be? Ezt az információt általában az incidensrekord tárolja, és minden alkalommal frissül, amikor az incidenst új csapathoz rendelik. Példák Service DeskHálózatüzemeltetésAdatbázis-adminisztrációAlkalmazástámogatás, 2. szint | |||
| Hozzárendelt ügyintéző AssignedAgent | Az incidens kezelésével megbízott támogatási ügyintéző vagy felhasználó. | ||
| Leírás A hozzárendelt ügyintéző azonosítja az incidensért felelős személyt. Míg a hozzárendelt csoport a csapatot jelöli, az ügyintéző az a munkatárs, aki az incidens megoldásán dolgozik. Ez az attribútum részletesebb teljesítmény- és munkaterhelés-elemzést tesz lehetővé. Az ügyintézői szintű hozzárendelések nyomon követésével a vezetők felmérhetik az egyéni teljesítményt, azonosíthatják a képzési igényeket, és kiegyensúlyozhatják a munkaterhelést. A process mining olyan összetett újra-hozzárendelési mintákat is feltárhat, amelyek csoportszinten nem láthatók, és segít megérteni, hogyan járulnak hozzá az egyes munkatársak a megoldási időhöz. Miért fontos? Részletesen elemezhető vele az egyéni munkaterhelés, a teljesítmény és a csapaton belüli vagy csapatok közötti újra-hozzárendelések mintázata. Hol szerezhető be? Az incidens fő rekordjában található mező, amely akkor frissül, amikor egy ügyintéző átveszi az incidens felelősségét, vagy hozzárendelik azt. Példák John SmithJane Doeagent.12345Emily Jones | |||
| Incidens állapota IncidentStatus | Az incidens aktuális vagy korábbi állapota az életciklus során, például „New”, „In Progress” vagy „Closed”. | ||
| Leírás Az incidens állapota megmutatja, hogy az incidens az életciklus melyik szakaszában volt egy adott időpontban. Áttekintést ad arról, hol tart az incidens megoldása. A gyakori állapotok közé tartozik az új, a hozzárendelt, a folyamatban lévő, a függő, a megoldott és a lezárt. Ez az attribútum alapvető a folyamatelemzéshez, mivel az állapotváltozások gyakran a folyamattérkép tevékenységeit is meghatározzák. Az egyes állapotokban eltöltött idő elemzése segít azonosítani a késéseket, például ha az incidensek hosszú ideig „Pending” állapotban várakoznak. Az attribútum a nyitott incidensek számának kiszámítására és a megoldás felé tett előrehaladás nyomon követésére is használható. Miért fontos? Segít megérteni az incidens előrehaladását, és gyakran ebből származtatják a folyamattérkép tevékenységeit. Az egyes állapotokban eltöltött idő elemzésével feltárhatók a késések. Hol szerezhető be? Általában az incidens fő rekordjának egyik alapmezőjeként vagy az incidens előzménynaplójában érhető el. Példák ÚjFolyamatbanÜgyfélre várMegoldvaLezárva | |||
| Incidenskategória IncidentCategory | Az incidens besorolása, gyakran hierarchikus szerkezetben, például Hardver > Laptop > Akkumulátor. | ||
| Leírás Az incidenskategória az incidensek jellegük szerinti, strukturált besorolását teszi lehetővé. Ez jellemzően hierarchikus mező, amely fokozatosan részletesebb besorolást kínál, így az incidensek logikus csoportokba rendezhetők a jelentésekhez és az elemzéshez. A kategorizálás fontos az okok és a trendek elemzéséhez. A kategória szerint szűrt folyamattérképek elemzésével a szervezetek azonosíthatják az ismétlődő problémákat és az egyes incidenciatípusokhoz kapcsolódó mintákat. Például egy „Szoftver” kategóriájú incidens megoldási folyamata jelentősen eltérhet egy „Hardver” kategóriájúétól. Ezek az adatok olyan KPI-k alapjául szolgálnak, mint az első besorolás pontossága és az ismétlődő incidensek aránya. Miért fontos? Elengedhetetlen az okok feltárásához, az ismétlődő incidensek trendjeinek azonosításához és a különböző problématípusok kezelésének megértéséhez. Hol szerezhető be? Az incidensrekord standard, gyakran kötelező mezői, amelyeket a besoroláshoz használnak. Példák Szoftver | Alkalmazás | Bejelentkezési problémaHardver | Nyomtató | Nem válaszolHálózat | Wi-Fi | Lassú kapcsolat | |||
| Megoldás módja ResolutionMethod | Az incidens végső megoldásának módját jelző kód, kategória vagy leírás. | ||
| Leírás A megoldás módja az incidens kimenetelét és megoldásának módját írja le. Lehet szabványos kód vagy a végrehajtott lépések szabad szöveges leírása. Például: „Felhasználói oktatás”, „Szoftverjavítás telepítve”, „Nem találtunk hibát” vagy „Duplikált incidens”. Ez az attribútum fontos háttér-információt ad a folyamat végéről. A megoldás módja szerinti elemzés segít megérteni a különböző megoldások hatékonyságát. Rávilágíthat azokra az esetekre, amelyeket tényleges javítás nélkül zártak le, és feltárhatja az egyes incidenskategóriákra jellemző megoldási mintákat. Ezek alapján tudásbázis építhető, és javítható az első kapcsolatfelvételkor megoldott incidensek aránya. Miért fontos? Megmutatja, hogyan oldják meg a problémákat, így azonosíthatók az automatizálás, a tudásbázis fejlesztése és a képzés lehetőségei. Hol szerezhető be? Ezt a mezőt általában a támogatási ügyintéző tölti ki, amikor az incidens állapotát „Resolved” vagy „Closed” értékre állítja. Példák A Service Desk megoldottaNem találtunk hibátDuplikáltSzoftverfrissítés telepítve | |||
| Prioritás Priority | Az incidenshez rendelt prioritási szint, amely meghatározza a megoldás sürgősségét és sorrendjét. | ||
| Leírás A prioritás az incidens relatív fontosságát és a szükséges válaszadási sebességet meghatározó attribútum. Gyakran az incidens hatása és sürgőssége alapján számítják ki. A szintek jellemzően a kritikustól az alacsonyig terjednek. A process mining elemzésben a prioritás szerinti bontás megmutatja, hogyan kezeli a folyamat a különböző sürgősségű incidenseket. Az elemzők összehasonlíthatják a magas és alacsony prioritású incidensek megoldási idejét, ellenőrizhetik az SLA-k teljesülését és az erőforrások elosztását. Így arra is választ kaphatnak, hogy valóban a legsúlyosabb incidenseket kezelik-e a leggyorsabban. Miért fontos? Lehetővé teszi a folyamat teljesítményének összehasonlítását a különböző sürgősségi szinteken, és segít ellenőrizni, hogy a kritikus incidenseket gyorsabban kezelik-e, mint a kevésbé sürgős eseteket. Hol szerezhető be? Az incidens fő rekordjának standard mezője. Kézzel is megadható, vagy automatikusan kiszámítható a hatás és a sürgősség alapján. Példák 1 - Kritikus2 - Magas3 - Közepes4 - Alacsony | |||
| Súlyosság Severity | Az incidens üzleti hatásának mértéke, amely megmutatja, mennyire érinti a felhasználókat vagy a szolgáltatásokat. | ||
| Leírás A súlyosság az incidens üzleti hatásának mértékét jelzi. Arra ad választ, mennyire komoly a probléma, a sürgősségétől függetlenül. Például egy teljes rendszert érintő leállás súlyos incidens, míg egy kisebb, csak a megjelenést érintő hiba alacsony súlyosságú. Az incidensek súlyosság szerinti elemzésével a szervezetek megérthetik, mely problémák okozzák a legnagyobb fennakadást. A process mining feltárhatja, hogy a súlyos incidensek megoldása eltérő, egyszerűbb útvonalon történik-e. Ez az attribútum fontos az okok feltárásához és az erőforrások megelőző problémakezelésre való összpontosításához, hogy a legsúlyosabb incidensek ne ismétlődjenek meg. Miért fontos? Segít csoportosítani az incidenseket, és megérteni, hogy a nagy hatású problémákat másként vagy hatékonyabban oldják-e meg, mint a kisebb hatásúakat. Hol szerezhető be? Az incidensrekord standard mezője, amelyet gyakran a sürgősséggel együtt használnak a prioritás meghatározásához. Példák 1 - Magas2 - Közepes3 - AlacsonyKritikus | |||
| Bejelentő Requester | Az a felhasználó, munkatárs vagy rendszer, amely először bejelentette az incidenst. | ||
| Leírás A bejelentő az a személy, aki tapasztalja a problémát, és kezdeményezi az incidens bejelentését. Lehet belső munkatárs vagy külső ügyfél. Az attribútum a bejelentő részlegét vagy szervezetét is rögzítheti. Az incidensek bejelentő vagy bejelentői részleg szerinti elemzése megmutatja, hogy egyes felhasználói csoportoknál gyakrabban fordulnak-e elő problémák. Ez képzési igényre vagy helyi környezeti problémára utalhat. A process mining segítségével a támogatási folyamat a felhasználók szempontjából vizsgálható, így megérthető, hogyan élik meg a folyamatot a különböző felhasználói csoportok. Miért fontos? Lehetővé teszi a felhasználóközpontú elemzést, és segít azonosítani, ha egyes felhasználók, részlegek vagy telephelyek aránytalanul sok incidenst jelentenek. Hol szerezhető be? Az incidensrekord standard mezője, amelybe általában a jegyet létrehozó felhasználó vagy az a személy kerül, akinek a nevében létrehozták. Példák Alice JohnsonÉrtékesítési részlegb.williamsCustomer-XYZ Corp | |||
| Érintett szolgáltatás AffectedService | Az incidens által érintett üzleti szolgáltatás, alkalmazás vagy konfigurációs elem (CI). | ||
| Leírás Az érintett szolgáltatás összekapcsolja az incidenst az IT-infrastruktúra egy konkrét elemével, például egy üzleti alkalmazással, szerverrel vagy hálózati eszközzel. Ez az elem gyakran a konfigurációkezelési adatbázishoz (CMDB) kapcsolódik. Ez az attribútum fontos üzleti hátteret ad az incidenshez. A process mining segítségével elemezhető az egyes szolgáltatások vagy eszközök megbízhatósága. A szervezetek azonosíthatják, mely szolgáltatásokhoz kapcsolódik a legtöbb incidens, elemezhetik azok megoldási folyamatait, és a problémakezelési erőforrásokat a kritikus üzleti szolgáltatások stabilitásának javítására összpontosíthatják. Ez segít megérteni az IT-incidensek tágabb üzleti hatását. Miért fontos? Az incidenseket konkrét üzleti szolgáltatásokhoz vagy IT-összetevőkhöz kapcsolja, így elemezhető, mely szolgáltatásoknál fordul elő a legtöbb probléma, és mekkora ezek hatása. Hol szerezhető be? Általában a konfigurációkezelési adatbázisból (CMDB) származik, vagy az incidensűrlap szolgáltatáskatalógusából választható ki. Példák E-mail-szolgáltatásokSAP ERP pénzügyVállalati VPNSRV-SQL-01 | |||
| SLA-státusz SlaStatus | Jelzi, hogy az incidens a szolgáltatási szintre vonatkozó megállapodás (SLA) célértékein belül van-e, veszélyben van-e, vagy már túllépte azokat. | ||
| Leírás Az SLA-státusz pillanatképet ad arról, hogyan teljesít az incidens az előre meghatározott időcélokhoz, például a válaszadási vagy megoldási időhöz képest. A gyakori státuszok közé tartozik a „Folyamatban”, a „Veszélyben” és a „Túllépve”. Ez az attribútum közvetlenül méri a szolgáltatás minőségét, és fontos adatforrás az SLA-teljesítmény áttekintő dashboardhoz. A process mining segítségével összehasonlíthatók a határidőn belül és azon túl lezárt incidensek folyamatai. Így azonosíthatók azok a tevékenységek, késések és ismétlődő folyamatkörök, amelyek leginkább az SLA-célok túllépéséhez vezetnek, és célzott folyamatfejlesztés indítható. Miért fontos? Közvetlenül mutatja a célértékekhez viszonyított teljesítményt. A határidőn túl lezárt incidensek elemzésével feltárhatók azok a folyamatbeli hibák, amelyek rontják a szolgáltatás minőségét. Hol szerezhető be? Ezt az értéket általában az ITSM-eszköz számítja ki, és az incidens prioritása, kora, valamint a beállított SLA-szabályok alapján folyamatosan frissíti. Példák FolyamatbanSzüneteltetveHatáridőn túlVeszélyben | |||
| Újra-hozzárendelések száma ReassignmentCount | Az incidens másik ügyintézőhöz vagy csoporthoz történő újra-hozzárendeléseinek száma. | ||
| Leírás Az újra-hozzárendelések száma azt mutatja meg, hányszor adták át az incidenst az életciklusa során. A magas érték gyakran a folyamat hatékonyságának hiányára, a kezdeti hibás irányításra vagy a támogatási csapatok tudáshiányára utal. Ez az attribútum hasznos a process mining elemzéshez. A process mining ugyan megjeleníti az újra-hozzárendeléseket, de az előre kiszámított érték megkönnyíti a szűrést és a KPI-k mérését. Az átadások és újra-hozzárendelések elemzésére szolgáló dashboard közvetlenül használja ezt az adatot. Segít feltárni azokat a „pingponghelyzeteket”, amikor a jegyek oda-vissza járnak a csapatok között, ami meghosszabbítja a megoldási időt és rontja a felhasználói élményt. Miért fontos? Ez a mutató közvetlenül számszerűsíti a folyamat hatékonyságának hiányát. A magas érték gyakran hosszabb megoldási idővel jár együtt, és az irányítás vagy a csapatok képességeinek problémájára utal. Hol szerezhető be? Gyakran az incidensrekord standard számlálómezőjeként érhető el. Ha nincs ilyen mező, az incidens auditnaplójában szereplő hozzárendelés-változások megszámlálásával is kiszámítható. Példák 0135 | |||
Az incidenskezelés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| A kivizsgálás megkezdése | Azt jelzi, hogy a hozzárendelt ügyintéző megkezdte az incidens aktív kezelését. Ezt gyakran az „Assigned” vagy „New” állapot „In Progress” állapotra váltása jelzi. | ||
| Miért fontos? Ez a mérföldkő jelzi a kezdeti várakozási idő végét és az aktív munka kezdetét. Az eseményig eltelt idő mérése segít megérteni az ügyintézői kapacitást és a válaszadás késedelmét. Hol szerezhető be? Ezt általában az incidens előzménynaplójában szereplő állapotváltozásból következtetik ki. Rögzítés Keresse meg azt az időbélyeget, amikor az incidens állapota először „In Progress”, „Work in Progress” vagy hasonló aktív állapotra vált. Eseménytípus inferred | |||
| Csoport hozzárendelése | Az incidens első hozzárendelését jelzi egy adott támogatási csoporthoz vagy csapathoz, amely kivizsgálja az ügyet. Ez az első hivatalos átadás, és ekkor indul a megoldási munkafolyamat. | ||
| Miért fontos? Ez fontos irányítási lépés. A késedelmes vagy hibás hozzárendelés jelentősen meghosszabbíthatja a megoldási időt, és szükségtelen csapatok közötti átadásokhoz vezethet. Hol szerezhető be? Az esemény az auditnaplóból következtethető ki: meg kell keresni, mikor töltötték ki először az „Assignment Group” vagy a „Support Team” mezőt. Rögzítés Keresse meg az incidens előzményeiben azt az időbélyeget, amikor először kitöltötték az „Assignment Group” mezőt. Eseménytípus inferred | |||
| Incidens létrehozása | Ez a tevékenység jelzi, hogy a rendszerben hivatalosan létrejött az incidensrekord. Ezzel indul az incidens életciklusa, és ekkor rögzítik a felhasználó vagy a felügyeleti eszköz kezdeti bejelentését. | ||
| Miért fontos? Ez a folyamat elsődleges kezdőeseménye. A létrehozás és a későbbi mérföldkövek közötti idő elemzése alapvető a teljes megoldási idő méréséhez és a kezdeti késedelmek feltárásához. Hol szerezhető be? Ezt általában a forrásrendszer elsődleges incidens- vagy jegytáblájának létrehozási időbélyege alapján rögzítik. Rögzítés Használja a fő incidensrekord „create_date” vagy „submitted_on” időbélyegét. Eseménytípus explicit | |||
| Incidens lezárva | Az életciklus utolsó tevékenysége: az incidensrekordot hivatalosan lezárják, és csak olvasható előzménnyé válik. Ez gyakran automatikusan történik, miután az incidens egy meghatározott ideig „Resolved” állapotban volt. | ||
| Miért fontos? Ez jelöli az incidens életciklusának tényleges végét. A létrehozástól a lezárásig eltelt teljes idő elemzése megmutatja a folyamat teljes időtartamát, beleértve a megoldás utáni adminisztrációt is. Hol szerezhető be? Az incidens előzménynaplójában rögzített, kifejezett „Closed” állapotváltozásból származik, amely megadja a végső időbélyeget. Rögzítés Használja az auditnapló időbélyegét arról az időpontról, amikor az incidens állapota „Closed” értékre változott. Eseménytípus explicit | |||
| Incidens megoldva | Ez a tevékenység azt jelzi, hogy megoldották az incidenst, és a felhasználó számára helyreállt a szolgáltatás. Fontos mérföldkő, amely rendszerint megállítja az SLA szerinti megoldási idő mérését. | ||
| Miért fontos? Ez a megoldási idő mérésének egyik fontos végpontja. A megoldás és a végleges lezárás közötti időből kiderülhet, mennyit késik a felhasználói visszaigazolás, illetve hogyan hatnak az automatikus lezárási szabályok. Hol szerezhető be? Ez szinte mindig kifejezetten rögzített esemény, amely akkor keletkezik, amikor az ügyintéző az incidens állapotát „Resolved” vagy „Solved” értékre állítja. Rögzítés Használja az auditnapló időbélyegét arról az időpontról, amikor az incidens állapota „Resolved” értékre változott. Eseménytípus explicit | |||
| Incidens újranyitva | Akkor történik, amikor egy korábban megoldott incidens ismét aktív állapotba kerül. Ez általában azért van, mert a felhasználó jelzi, hogy a probléma visszatért, vagy a megoldás nem vált be. | ||
| Miért fontos? A gyakori újranyitás a megoldás minőségének problémájára, hiányos okfeltárásra vagy idő előtti lezárásra utalhat. Ez fontos mutató az ismételt munkavégzés elemzéséhez. Hol szerezhető be? Az állapotelőzményekből következtethető ki, amikor az incidens állapota „Resolved” vagy „Closed” értékről ismét aktív állapotra, például „In Progress” értékre változik. Rögzítés Észlelje az állapotváltozást a megoldott állapotból nyitott állapotba, és rögzítse a változás időbélyegét. Eseménytípus inferred | |||
| SLA-sértés észlelése | Számított esemény, amely akkor következik be, ha az incidensre adott válasz vagy annak megoldása túllépi a szolgáltatási szintű megállapodásban (SLA) meghatározott célidőt. Nem felhasználói művelet váltja ki, hanem az idő múlása. | ||
| Miért fontos? Az SLA-sértések az egyik legfontosabb teljesítménymutató (KPI). Annak elemzése, hogy mikor és miért fordulnak elő, segít javítani a szolgáltatásnyújtást és teljesíteni a szerződéses kötelezettségeket. Hol szerezhető be? Ez az esemény nem szerepel közvetlenül a naplókban. Az incidensrekordban tárolt SLA-határidőket kell összevetni az események időbélyegeivel, és így kiszámítani. Rögzítés Hasonlítsa össze a megoldás időbélyegét az „SLA Due Date” értékével. Ha a megoldás később született, rögzítsen SLA-sértési eseményt az SLA-határidő időpontjával. Eseménytípus calculated | |||
| A munka folytatása | Azt jelzi, amikor a felfüggesztett incidens ismét aktívvá válik. Ez általában akkor történik, amikor megérkezik a szükséges információ, és az ügyintéző folytathatja a munkát. | ||
| Miért fontos? Ez a tevékenység elengedhetetlen a külső várakozási idő pontos méréséhez. A „Pending” és a „Resumed” közötti idő megmutatja, mennyi ideig állt a folyamat külső okból. Hol szerezhető be? Az incidens állapotelőzményeiből következtethető ki, amikor az ügy a „Pending” állapotból visszavált „In Progress” vagy más aktív állapotba. Rögzítés Rögzítse azt az időbélyeget, amikor az incidens állapota függőben lévő állapotból ismét aktívra vált. Eseménytípus inferred | |||
| Állapotváltás függőben lévőre | Akkor történik, amikor az incidens kezelése szünetel, általában azért, mert a felhasználótól, egy beszállítótól vagy más külső féltől várnak információt. Ez az állapot jellemzően megállítja az SLA-idő mérését. | ||
| Miért fontos? A függőben lévő állapotban töltött idő elemzése feltárja a külső függőségeket és késedelmeket. A túl hosszú várakozás elfedheti a belső hatékonysági problémákat, és torzíthatja a megoldási idő mutatóit. Hol szerezhető be? Az incidens állapotelőzményeiből következtethető ki, amikor az állapot „Pending”, „On Hold” vagy „Awaiting User” értékre változik. Rögzítés Rögzítse az időbélyeget minden alkalommal, amikor az incidens állapota valamelyik kijelölt függőben lévő állapotra vált. Eseménytípus inferred | |||
| Átmeneti megoldás biztosítása | Azt jelzi, hogy a szolgáltatás működésének helyreállításához átmeneti megoldást közöltek a felhasználóval. Ez mérsékli az üzleti hatást, amíg elkészül a végleges javítás. | ||
| Miért fontos? Az átmeneti megoldás biztosítása fontos lépés a súlyos incidensek kezelésében. Lehetővé teszi, hogy a szolgáltatás helyreállításáig eltelt időt külön mérje a végleges megoldásig eltelt időtől. Hol szerezhető be? Ez lehet külön állapot vagy jelölő, de gyakran az ügyintézői megjegyzésekből vagy kommunikációs naplókból, kulcsszavak keresésével következtetnek rá. Rögzítés Azonosítsa egy olyan állapot alapján, mint a „Workaround Provided”, vagy keressen az ügyintézői megjegyzésekben olyan kifejezéseket, mint a „workaround” vagy a „temporary fix”. Eseménytípus inferred | |||
| Incidens besorolása | Az incidens besorolását jelöli, beleértve a kategória, a típus és az elem megadását. Ez a fontos előzetes értékelési lépés segít az incidens megfelelő irányításában és a helyes megoldási eljárás kiválasztásában. | ||
| Miért fontos? A hibás besorolás késedelmet, újrakiosztást és torz jelentéseket eredményezhet. Ennek a tevékenységnek az elemzésével felmérhető a kezdeti értékelés minősége és annak hatása a megoldás hatékonyságára. Hol szerezhető be? Ezt az eseményt általában az auditnaplóból vagy az előzménytáblából következtetik ki, megkeresve, mikor töltötték ki először a besoroláshoz kapcsolódó mezőket. Rögzítés Keresse meg az incidens létrehozása utáni első módosítást az olyan mezőkben, mint a „Category”, a „Subcategory” vagy a „Configuration Item”. Eseménytípus inferred | |||
| Incidens prioritásának megadása | Ez a tevékenység akkor történik, amikor megadják az incidens prioritását, jellemzően annak hatása és sürgőssége alapján. A prioritási szint határozza meg a szolgáltatási szintű megállapodások (SLA-k) szerinti célzott válasz- és megoldási időt. | ||
| Miért fontos? A prioritás közvetlenül befolyásolja az erőforrások elosztását és az incidensek kezelésének sorrendjét. Ennek a lépésnek az elemzése segít biztosítani, hogy a kritikus incidensek kapjanak először figyelmet, és teljesüljenek az SLA-k. Hol szerezhető be? Ezt az auditnaplóban a „Priority” vagy „Severity” mező módosításainak követésével rögzítik. Rögzítés Használja az auditnaplóban a „Priority” mező módosításához tartozó időbélyeget. Eseménytípus explicit | |||
| Incidens újrakiosztása | Az incidens átadását jelöli egyik támogatási csoporttól vagy ügyintézőtől a másikhoz. Erre gyakran akkor kerül sor, ha az első csapat nem tudja megoldani a problémát, és más szaktudásra van szükség. | ||
| Miért fontos? A gyakori újrakiosztás a folyamat hatékonysági problémájára, hibás kezdeti irányításra vagy a csapat tudásában lévő hiányosságokra utalhat. Ezeknek az átadásoknak az elemzése segít egyszerűsíteni a megoldási folyamatot. Hol szerezhető be? Az auditnaplóból következtethető ki, ha az első hozzárendelés után megváltozik az „Assignment Group” vagy az „Assignee” mező. Rögzítés Rögzítsen új eseményt az „Assignment Group” mező minden olyan módosításakor, amely az első kitöltés után történik. Eseménytípus inferred | |||
| Ügyintéző hozzárendelése | Ez a tevékenység jelzi, amikor egy adott ügyintéző átveszi vagy megkapja az incidens kezelésének felelősségét. Ekkor a csapatszintű felelősség egyéni felelősséggé válik. | ||
| Miért fontos? Az ügyintézők hozzárendelésének követése segít elemezni az egyéni munkaterhelést és teljesítményt, valamint azonosítani azokat a szűk keresztmetszeteket, ahol az incidensek a szabad ügyintézőre várnak. Hol szerezhető be? Az incidens auditnaplójában az „Assignee” vagy „Assigned To” mező változásainak követésével rögzíthető. Rögzítés Használja azt az időbélyeget az auditnaplóból, amikor az „Assignee” mezőt először kitöltötték, vagy új felhasználóra módosították. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Az adatkinyerési módszerek rendszerenként eltérnek. Részletes útmutatásért
olvassa el az ETL-útmutatónkat vagy válasszon ki egy konkrét folyamatot és rendszert.
Készen áll a kezdésre?
Kezdje el még ma átalakítani incidenskezelési folyamatát. Válasszon az alábbi rendszerspecifikus adatkinyerési útmutatók közül, vagy használja ezt az általános sablont az eseménynapló összeállításához és a folyamat alapos elemzéséhez.
Oldja meg gyorsabban az incidenseket, kezdje el most az átalakítást
Tárja fel a szűk keresztmetszeteket, csökkentse az állásidőt, és növelje a csapat hatékonyságát.
Bankkártya nem szükséges, a beállítás 5 percet vesz igénybe