Incidenskezelési adatsablon

Általános process mining sablon
Incidenskezelési adatsablon

Incidenskezelési adatsablon

Általános process mining sablon

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
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Az incidenskezelés attribútumai

Ez a rész ismerteti azokat a javasolt adatmezőket és esetjellemzőket, amelyek szükségesek a részletes eseménynapló összeállításához és az incidenskezelési folyamat alapos elemzéséhez.
5 Kötelező 8 Javasolt 4 Nem kötelező
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
Kötelező Javasolt Nem kötelező

Az incidenskezelés tevékenységei

A táblázat bemutatja azokat az alapvető folyamatlépéseket és fontos mérföldköveket, amelyeket érdemes követni a folyamat pontos feltárásához és az incidensmegoldás menetének megértéséhez.
7 Javasolt 7 Nem kötelező
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
Javasolt Nem kötelező

Adatkinyerési útmutatók

Hogyan szerezze be az adatokat a process mininghez?

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.

Próbálja ki ingyen

Bankkártya nem szükséges, a beállítás 5 percet vesz igénybe