Incidenskezelési adatsablon

Jira Service Management
Incidenskezelési adatsablon

Incidenskezelési adatsablon

A sablon rendszerezetten összegyűjti az incidenskezelési folyamat elemzéséhez szükséges adatokat. Bemutatja, mely attribútumokat érdemes rögzíteni, mely tevékenységeket kell követni, és gyakorlati útmutatást ad az adatok forrásrendszerből történő kinyeréséhez. Így minden szükséges adat rendelkezésére áll az incidensek megoldási munkafolyamatainak fejlesztéséhez.
  • Javasolt attribútumok
  • Követendő tevékenységek
  • Adatok kinyerése a Jira Service Managementből
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Az incidenskezelés attribútumai

Ezeket az adatmezőket érdemes felvenni az eseménynaplóba az incidenskezelési folyamat részletes elemzéséhez.
5 Kötelező 6 Javasolt 12 Nem kötelező
Név Leírás
Incidensazonosító
IncidentId
A Jira Service Managementben minden incidensjegy egyedi azonosítója.
Leírás

Az incidensazonosító, amelyet a Jirában gyakran Issue Key néven említenek, minden bejelentett incidens egyedi azonosítója. Az incidens létrehozásától a végleges lezárásig összekapcsolja a hozzá tartozó tevékenységeket, megjegyzéseket és állapotváltozásokat. A process mining során ez az azonosító teszi lehetővé az egyes incidensek teljes életútjának rekonstruálását és a folyamat egészének elemzését.

Miért fontos?

Ez az alapazonosító kapcsolja össze az összes kapcsolódó eseményt egyetlen esetté, ezért minden process mining elemzés kiindulópontja.

Hol szerezhető be?

Ez a Jira Service Management-jegyek szokásos „Key” mezője, például „ITSM-123”.

Példák
INC-10234HELPDESK-5678OPS-9901
Kezdés időpontja
EventTimestamp
A tevékenység pontos dátuma és időpontja.
Leírás

Ez az attribútum rögzíti az incidens életútjának minden tevékenységéhez tartozó időbélyeget. Ezek alapján számítható ki a lépések időtartama, a ciklusidő és a várakozási idő. A pontos időbélyegek részletes teljesítményelemzést, SLA-követést és a szűk keresztmetszetek azonosítását teszik lehetővé. Az olyan mutatók, mint a megoldási idő és a diagnosztika időtartama, szintén ezekből számíthatók.

Miért fontos?

Az időbélyegek nélkülözhetetlenek az időalapú mutatók kiszámításához, a folyamat időtartamának megértéséhez és a teljesítményt hátráltató szűk keresztmetszetek feltárásához.

Hol szerezhető be?

A Jira-jegy változásnaplójában vagy előzményeiben szereplő bejegyzés „created” dátuma.

Példák
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Tevékenység
ActivityName
Az incidenshez kapcsolódó esemény vagy állapotváltozás neve.
Leírás

A tevékenység az incidenskezelés életútjának egy-egy lépését vagy eseményét jelöli, például „Incidens létrehozva”, „Incidens kiosztva” vagy „Megoldás javasolva”. Ezeket általában a Jira-jegy előzményeiben vagy változásnaplójában rögzített állapotváltásokból és frissítésekből állítják elő. A tevékenységek sorrendjének és időtartamának elemzése a process mining egyik fő célja: feltárja a tényleges folyamatmenetet, a szűk keresztmetszeteket és az eltéréseket.

Miért fontos?

A tevékenységek adják a folyamattérkép alapját, amelyen megjeleníthető és elemezhető az incidens teljes életútja.

Hol szerezhető be?

A Jira-jegy előzményeiből és változásnaplójából származik, rögzítve az állapotváltásokat és a fontos mezők módosításait.

Példák
Incidens kiosztvaKivizsgálás megkezdveIncidens megoldva
Forrásrendszer
SourceSystem
A rendszer, amelyből az adatokat kinyerték.
Leírás

Ez az attribútum azonosítja az adatok forrását, jelen esetben a Jira Service Managementet. Különösen hasznos, ha több rendszer adatait egyesítik a folyamat egységes áttekintéséhez. A forrásrendszer megadásával nyomon követhető az adatok eredete, és könnyebb feltárni az adatminőségi vagy kinyerési problémákat. Ennél a modellnél az érték állandó.

Miért fontos?

Megmutatja, honnan származnak az adatok, így azok eredete egyértelműen követhető, különösen több rendszer adatainak elemzésekor.

Hol szerezhető be?

Állandó érték, amelyet az adatkinyerés során kell hozzáadni.

Példák
Jira Service ManagementJira Cloud
Utolsó adatfrissítés
LastDataUpdate
Az időbélyeg, amely megmutatja, mikor frissültek utoljára az adatok a forrásrendszerből.
Leírás

Ez az attribútum rögzíti az adatkészlet utolsó frissítésének időpontját. Segít az elemzést végzőknek megítélni, mennyire frissek az adatok. Ez különösen fontos a folyamatosan figyelt dashboardoknál, ahol a naprakész információk alapján kell időben dönteni. Egy adatkinyerési csomagon belül az érték általában minden eseménynél azonos.

Miért fontos?

Tájékoztatja a felhasználókat az adatok aktualitásáról, ami az elemzés relevanciája és pontossága szempontjából is fontos.

Hol szerezhető be?

Az adatkinyerési futás időbélyege, amelyet az adatátalakítás során adnak hozzá.

Példák
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Állapot
Status
Az incidens aktuális állapota az életútján belül.
Leírás

Az Állapot mező mutatja az incidens aktuális állapotát a meghatározott workflow-ban, például „Nyitott”, „Folyamatban”, „Ügyfélre vár” vagy „Megoldva”. Az állapotváltozások jelentik a process mining tevékenységnaplójának elsődleges adatforrását. Az egyes állapotokban töltött idő elemzése alapvető a szűk keresztmetszetek azonosításához és annak megértéséhez, hol telik el a legtöbb idő az incidensek kezelésével.

Miért fontos?

Közvetlenül mutatja az incidens előrehaladását, és elsődleges forrása a folyamatlépések és a várakozási idők azonosításának.

Hol szerezhető be?

A Jira-jegy szokásos „Status” mezője.

Példák
FolyamatbanÜgyfél válaszára várMegoldvaLezárva
Felelős
Assignee
Az incidens kezelésére jelenleg kijelölt felhasználó.
Leírás

A felelős az az ügyintéző vagy felhasználó, aki egy adott időpontban az incidens kezeléséért felel. A felelős változásainak követése segít elemezni az átadásokat, megérteni a munkaterhelés eloszlását, és azonosítani, kik vesznek részt az egyes folyamatlépésekben. Az attribútum alapján az egyéni teljesítményről és a támogató csapatok erőforrás-elosztásáról is képet kaphat.

Miért fontos?

Segít követni az egyéni munkaterhelést, azonosítani az egyes ügyintézőkhöz kapcsolódó szűk keresztmetszeteket, és felmérni, hogyan befolyásolják az átadások a megoldási időt.

Hol szerezhető be?

A Jira-jegy szokásos „Assignee” mezője.

Példák
John SmithEmily JonesServiceDeskAgent1
Felelős csoport
AssignmentGroup
Az incidens kezeléséért felelős csapat vagy csoport.
Leírás

A felelős csoport az incidens kezelésére kijelölt csapat. Lehet például egy támogatási szint, mint az „L1 Helpdesk”, egy szakterületre szakosodott csapat, például a „Network Operations”, vagy egy fejlesztőcsapat. A felelős csoportok közötti váltások elemzésével feltárhatók az eszkalációk és az átadások. Mérhetővé válik a csapatok teljesítménye, azonosíthatók a csapatszintű szűk keresztmetszetek, és elemezhetők a csapatok közötti függőségek.

Miért fontos?

Segít elemezni a csapatok teljesítményét, áteresztőképességét és a munka áramlását a támogatási szintek, illetve a szakterületi csoportok között.

Hol szerezhető be?

A Jirában gyakran egyéni mezőként szerepel, például „Team” vagy „Assignment Group” néven. Esetenként a Jira Components vagy a Project Roles mezőkből is származtatható.

Példák
1. szintű támogatásInfrastruktúra-csapatAdatbázis-adminisztrátorok
Létrehozás dátuma
CreatedDate
Az a dátum és időpont, amikor az incidenst először rögzítették a rendszerben.
Leírás

Ez az attribútum jelöli az incidens életútjának hivatalos kezdetét. Ez az alap-időbélyeg, amelytől a teljes megoldási időhöz hasonló mutatókat számítják. A létrehozás dátuma incidensenként állandó, és a process mining elemzésben az eset kiindulópontja.

Miért fontos?

Kiindulópontként szolgál a teljes folyamat ciklusidejének és az SLA-mutatóknak a kiszámításához.

Hol szerezhető be?

A Jira-jegy szokásos „Created” mezője.

Példák
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Megoldás dátuma
ResolutionDate
Az a dátum és időpont, amikor az incidenst megoldottként jelölték meg.
Leírás

Ez az attribútum rögzíti, mikor került az incidens először megoldott állapotba. Ezzel zárul az aktív munkafázis, és ez az időpont a megoldási idő kiszámításának végpontja. A megoldás dátumának és a létrehozás dátumának összevetése a folyamat hatékonyságának elsődleges mérőszáma. Az SLA-k betartásának megállapításához is szükséges.

Miért fontos?

Jelöli a megoldási folyamat végét, így kiszámítható a teljes ciklusidő és az SLA-teljesítmény.

Hol szerezhető be?

A Jira-jegy szokásos „Resolved” mezője.

Példák
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Prioritás
Priority
Az incidenshez rendelt prioritási szint, amely jelzi, milyen sürgősen kell megoldani.
Leírás

A prioritás határozza meg, milyen gyorsan kell kezelni az incidenst. Meghatározásakor gyakran a hatást és a sürgősséget veszik figyelembe, és közvetlenül befolyásolja az SLA-célértékeket. A prioritás szerinti elemzésből kiderül, hogy a magas prioritású incidenseket valóban gyorsabban kezelik-e az alacsonyabb prioritásúaknál, és következetesen alkalmazzák-e a prioritási szabályokat. A folyamat teljesítményének szűréséhez és összehasonlításához is fontos szempont.

Miért fontos?

Nélkülözhetetlen az SLA-teljesítmény elemzéséhez és annak ellenőrzéséhez, hogy az erőforrásokat a legsürgősebb incidensekre fordítják-e.

Hol szerezhető be?

A Jira-jegy szokásos „Priority” mezője.

Példák
LegmagasabbMagasKözepesAlacsony
Átadások száma
HandoffCount
Az alkalmak száma, ahányszor az incidenst másik csoporthoz vagy felhasználóhoz rendelték.
Leírás

Ez a számított mutató összeszámolja, hányszor változott az „Assignee” vagy az „AssignmentGroup” mező az incidens életútja során. A sok átadás gyakran a folyamat hatékonysági problémáira, az első kapcsolatfelvételkor történő megoldás elmaradására vagy tudáshiányra utal, ami hosszabb megoldási időhöz vezet. A KPI elemzése segít egyszerűsíteni a feladatkiosztást és javítani a csapatok együttműködését.

Miért fontos?

Számszerűsíti az újrakiosztások okozta fennakadásokat és hatékonyságvesztést, így feltárhatók a folyamatfejlesztési lehetőségek.

Hol szerezhető be?

A jegy változásnaplójában az „Assignee” vagy az „AssignmentGroup” mező módosításainak összeszámításával állapítható meg.

Példák
015
Bejelentő
Reporter
Az a felhasználó, aki először létrehozta vagy bejelentette az incidenst.
Leírás

A bejelentő az a személy, gyakran egy végfelhasználó, vagy az a másik rendszer, amely először rögzítette az incidenst. A bejelentők szerinti elemzés segít azonosítani azokat a felhasználókat vagy részlegeket, amelyeknél gyakran merülnek fel problémák. A kommunikációs minták is vizsgálhatók vele, különösen az olyan tevékenységeknél, mint az „Ügyfél válaszára vár” és az „Ügyfél válaszolt”.

Miért fontos?

Segít feltárni az incidensek forrását, azonosítani az egyes felhasználókhoz vagy részlegekhez kapcsolódó mintákat, és megérteni az ügyfélválaszok késését.

Hol szerezhető be?

A Jira-jegy szokásos „Reporter” mezője.

Példák
Alice JohnsonBob Williamsmonitoring-tool@example.com
Jegytípus
IssueType
A jegy típusa, például incidens, szolgáltatáskérés vagy probléma.
Leírás

A Jira a jegytípusokkal különbözteti meg a feladatok különböző fajtáit. Incidenskezelésnél az elsődleges típus az „Incident”, de más típusok, például a „Sub-task” is relevánsak lehetnek. Ez az attribútum segít úgy szűrni az adatkészletet, hogy csak az incidensek maradjanak benne, így a process mining elemzés a megfelelő folyamatra összpontosít.

Miért fontos?

Biztosítja, hogy az elemzés az incidensekre korlátozódjon, és elkülönítse őket az olyan munkatípusoktól, mint a szolgáltatáskérések vagy a változtatások.

Hol szerezhető be?

A Jira-jegy szokásos „Issue Type” mezője.

Példák
IncidensIT-támogatásHiba
Kapcsolt problémaazonosító
LinkedProblemId
Az ehhez az incidenshez kapcsolt problém jegyazonosítója.
Leírás

A nagyobb, háttérben meghúzódó probléma tüneteként jelentkező incidenseket gyakran egy Problem jegyhez kapcsolják. Ez a mező tárolja a kapcsolódó probléma azonosítóját. A hivatkozások elemzésével megérthető az incidensek és problémák közötti kapcsolat, mérhető a problémakezelés eredményessége, és azonosíthatók a végleges javítást igénylő, visszatérő incidensek.

Miért fontos?

Összekapcsolja az incidenseket a mögöttes problémákkal, így elemezhető, mennyire eredményesen kezeli a szervezet a kiváltó okokat a jövőbeli incidensek megelőzése érdekében.

Hol szerezhető be?

Ez az információ a Jira-jegy „Issue Links” szakaszában található.

Példák
PROB-123PROB-456Nincs
Kiváltó ok kategóriája
RootCauseCategory
Az incidens mögött álló kiváltó ok besorolása.
Leírás

Ez az attribútum rögzíti az incidens alapvető okát, például „Szoftverhiba”, „Hardverhiba” vagy „Felhasználói hiba”. Az értéket általában a kivizsgálás után adják meg. Az eredményes problémakezeléshez és a jövőbeli incidensek megelőzéséhez is szükséges. A kiváltó okok kategóriáinak elemzése feltárja a rendszerszintű gyengeségeket, és segít rangsorolni a fejlesztési kezdeményezéseket. Ha sok a „Ismeretlen” kiváltó ok, az a kivizsgálási folyamat fejlesztésének szükségességére utalhat.

Miért fontos?

Lehetővé teszi a kiváltó okok elemzését, így a szervezet a reaktív kezelés helyett az incidensek forrásainak feltárására és megszüntetésére összpontosíthat.

Hol szerezhető be?

Ez szinte mindig egyéni Jira-mező. A neve és a választható értékek a szervezet saját beállításaitól függenek.

Példák
Konfigurációs hibaHálózati leállásSzoftverhiba
Komponens
Component
Az incidens által érintett rendszer, alkalmazás vagy infrastruktúraelem.
Leírás

A komponensek a Jira-projekt kisebb részeit jelölik, amelyek szerint csoportosíthatók a jegyek, például „Felhasználói felület”, „Adatbázis” vagy „API”. A komponensenkénti elemzés megmutatja, mely rendszerelemeknél fordul elő a legtöbb probléma. Ez az információ hasznos a kiváltó okok feltárásához, a szolgáltatás fejlesztéséhez és a technikai adósság csökkentéséhez.

Miért fontos?

Lehetővé teszi az érintett termék vagy rendszerterület szerinti szűrést és elemzést, így azonosíthatók a problémákra különösen hajlamos technológiai területek.

Hol szerezhető be?

A Jira-jegy szokásos „Components” mezője.

Példák
Hitelesítési szolgáltatásJelentéskészítő dashboardMobilalkalmazás
Megoldás
Resolution
Az incidens megoldásának eredménye vagy indoka.
Leírás

A Megoldás mezőből derül ki, miért került az incidens megoldott állapotba. Gyakori érték például a „Javítva”, a „Duplikátum”, a „Nem kerül javításra” vagy a „Nem reprodukálható”. A megoldástípusok megoszlásának elemzése képet adhat a bejelentések minőségéről és a megoldási folyamat eredményességéről. Ha például sok a „Duplikátum” érték, az a bejelentés vagy az előzetes besorolás problémájára utalhat.

Miért fontos?

Kontextust ad az incidens kimeneteléhez, segít csoportosítani a megoldásokat és feltárni a lezárási mintákat.

Hol szerezhető be?

A Jira-jegy szokásos „Resolution” mezője. Ezt általában akkor állítják be, amikor a jegy „Done” állapotkategóriába kerül.

Példák
KészJavítvaDuplikátumNem javítjuk
Megoldási idő célértéke
TimeToResolutionTarget
Az incidens megoldására vonatkozó SLA-célidő.
Leírás

Ez az attribútum határozza meg azt a maximális időt, amelyen belül egy adott prioritású vagy típusú incidenst meg kell oldani. A tényleges megoldási időt ehhez a célértékhez viszonyítják az SLA betartásának megállapításához. Az érték általában dinamikusan, a prioritás, a súlyosság vagy a jegytípus alapján meghatározott szabályok szerint áll be. Az SLA-teljesítményt figyelő dashboardok egyik alapvető adata.

Miért fontos?

Viszonyítási alapot ad az SLA betartásának méréséhez, és az incidensek SLA-sértési arányának KPI-jához.

Hol szerezhető be?

A Jira Service Management SLA-beállításaiból származik. Azonosítani kell a megfelelő célt, például a „Megoldásig eltelt idő” értéket.

Példák
4 óra8 óra3 nap
SLA-sértés
SlaBreach
Jelzi, hogy az incidens megoldási ideje túllépte-e az SLA-célértéket.
Leírás

Ez a számított logikai attribútum jelzi, hogy az incidens megsértette-e a „Megoldásig eltelt idő” SLA-t. Értéke igaz, ha az „IncidentResolutionCycleTime” nagyobb, mint a „TimeToResolutionTarget”. A jelző egyszerűsíti az elemzést és az adatmegjelenítést: könnyen szűrhető és összesíthető, így kiszámítható az SLA-sértések arányának KPI-ja. Az SLA-teljesítményt figyelő dashboard egyik fő eredménymutatója.

Miért fontos?

Egyértelmű, kétértékű eredményt ad az SLA-teljesítményről, így egyszerűen kiszámítható a sértések aránya és azonosíthatók a problémás területek.

Hol szerezhető be?

Számítása: („IncidentResolutionCycleTime” > „TimeToResolutionTarget”).

Példák
truefalse
Súlyosság
Severity
Az incidens üzleti hatásának mértéke.
Leírás

A súlyosság azt mutatja meg, mekkora üzleti hatással jár az incidens: az egyetlen felhasználót érintő problémától a kritikus rendszerleállásig. A prioritás a munka sorrendjét határozza meg, a súlyosság pedig az üzleti hatást jelzi. A súlyosság szerinti elemzés megmutatja, hogyan teljesít a folyamat a vállalkozás számára legnagyobb jelentőségű incidenseknél. A részletesebb elemzéshez gyakran a prioritással együtt vizsgálják.

Miért fontos?

Megmutatja az üzleti hatást, így az elemzés az üzletmenetet leginkább hátráltató incidensekre összpontosíthat.

Hol szerezhető be?

Általában egyéni Jira-mező, mivel nem része az alapértelmezett rendszermezőknek. A beállításokat a Jira Service Management projektkonfigurációjában ellenőrizze.

Példák
KritikusSúlyosEnyheJelentéktelen
Ügyfélkérés típusa
CustomerRequestType
Az ügyfél által a szolgáltatási portálon beküldött kérés konkrét típusa.
Leírás

Ez a mező az ügyfél szemszögéből sorolja be a Jira Service Management portálon megjelenő kéréseket, például „Rendszerhiba bejelentése”. Felhasználóbarát kategóriát ad az incidensnek, amely eltérhet a belső „Issue Type” értékétől. Az attribútum elemzése megmutatja, hogyan érzékelik és jelentik be az ügyfelek a problémákat, ami segíthet a portál és a szolgáltatások fejlesztésében.

Miért fontos?

Az incidenskategóriákat az ügyfél szemszögéből mutatja be, ami hasznos a kereslet elemzéséhez és az ügyfélélmény javításához.

Hol szerezhető be?

A Jira Service Management-projektekre jellemző „Customer Request Type” mező.

Példák
IT-támogatás kérése > Rendszerhiba bejelentéseE-mail > Hozzáférési kérelem
Újramunkát igényel
IsRework
Jelzi, hogy az incidens igényelt-e újramunkát, például újranyitás miatt.
Leírás

Ez a számított logikai attribútum azonosítja azokat az incidenseket, amelyek visszakerültek a folyamat egy korábbi szakaszába. Ez leggyakrabban akkor történik, amikor egy megoldott incidenst újranyitnak. Az újramunkát igénylő körök jelentős hatékonyságveszteséget és ügyfél-elégedetlenséget okozhatnak. A jelzővel könnyen mérhető az újramunka aránya, és elemezhető, miért nem sikerül elsőre megfelelően megoldani az incidenseket.

Miért fontos?

Jelzi a többszöri munkát igénylő incidenseket, így feltárhatók a folyamat minőségi problémái és hatékonysági veszteségei, valamint elemezhető az újramunka.

Hol szerezhető be?

Az eseménynaplóban szereplő állapotváltások meghatározott sorrendje alapján számítható ki, például „Megoldva” -> „Újranyitva”.

Példák
truefalse
Kötelező Javasolt Nem kötelező

Az incidenskezelés tevékenységei

Ezeket a fontos folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban, hogy pontosan feltárhassa és elemezhesse az incidensek megoldási munkafolyamatait.
7 Javasolt 8 Nem kötelező
Tevékenység Leírás
Incidens létrehozva
Az incidens életciklusának hivatalos kezdetét jelöli: ekkor nyújtják be az incidensbejelentést, és új ügy jön létre a Jirában. Ez az esemény akkor rögzül, amikor a rendszerben új, „Incidens” típusú ügyet hoznak létre.
Miért fontos?

Ez a folyamat elsődleges kezdő eseménye. Az ettől a tevékenységtől a megoldásig eltelt idő elemzése alapvető a teljes átfutási idő és az SLA betartásának méréséhez.

Hol szerezhető be?

Ez a Jirában az incidensügy „created” időbélyegéből rögzített esemény. Az ügy létrehozása az ügy előzményeiben is megjelenik.

Rögzítés

Használja az ügy létrehozásának időbélyegét.

Eseménytípus explicit
Incidens lezárva
Az incidensjegy végleges, adminisztratív lezárását jelöli, miután az incidenst megoldották és ellenőrizték. Az esemény a „Closed” állapotba váltásból állapítható meg.
Miért fontos?

Ez a folyamat záró eseménye. A „Resolved” és a „Closed” állapot közötti idő elemzése feltárhatja az adminisztratív lezárás vagy a felhasználói visszaigazolás késedelmeit.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény időbélyege az a pillanat, amikor az állapot a végleges „Closed” értékre vált.

Rögzítés

Keresse meg az állapot „Closed” értékre váltásának időbélyegét.

Eseménytípus inferred
Incidens megoldva
Ez a tevékenység jelzi, hogy az incidens megoldása sikeres volt, és a szolgáltatás helyreállt. Gyakran egybeesik a „Resolved” állapotba váltással.
Miért fontos?

Ez a folyamat elsődleges sikermérföldköve. Az eddig eltelt idő a leggyakrabban használt KPI, amely a megoldásig eltelt időt (TTR) mutatja.

Hol szerezhető be?

A „Resolved” állapotba váltásból állapítható meg. Sok munkafolyamatban ez ugyanaz az esemény, mint a „Megoldás javasolva”, vagyis a megoldás fő mérföldköve.

Rögzítés

Keresse meg az állapot „Resolved” értékre váltásának időbélyegét.

Eseménytípus inferred
Incidens újra kiosztva
Akkor történik, amikor az incidens az első kiosztás után egy másik ügyintézőhöz vagy csoporthoz kerül. Az esemény az „Assignee” vagy az „Assigned Group” mező bármely módosításából állapítható meg.
Miért fontos?

Az újrakiosztások nyomon követése elengedhetetlen az átadások elemzéséhez. A gyakori újrakiosztás sokszor a folyamat hatékonysági problémáira, tudáshiányra vagy hibás kezdeti kiosztásra utal, ami késlelteti a megoldást.

Hol szerezhető be?

Az ügy előzményeiből állapítható meg: keresse meg az „Assignee” mező első kitöltése utáni módosításokat. Minden módosítás újrakiosztási eseménynek számít.

Rögzítés

Keresse meg az „Assignee” mező kezdeti kiosztás utáni módosításait.

Eseménytípus inferred
Kivizsgálás megkezdve
Azt jelzi, hogy a kijelölt ügyintéző megkezdte az incidens aktív diagnosztizálását. Az esemény általában akkor állapítható meg, amikor az incidens állapota „Open” vagy „New” értékről „In Progress” értékre változik.
Miért fontos?

Ez a fontos mérföldkő jelöli az aktív megoldási munka kezdetét. Az addig eltelt idő mérése segít feltárni a kezdeti várakozási időt és az erőforrások elérhetőségével kapcsolatos problémákat.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény időbélyege az a pillanat, amikor az állapot aktív munkát jelző értékre, például „In Progress” értékre vált.

Rögzítés

Keresse meg az állapot „In Progress” értékre váltásának időbélyegét.

Eseménytípus inferred
Megoldás javasolva
Azt jelzi, hogy megtalálták és alkalmazták a megoldást, az incidens pedig visszaigazolásra vagy végső ellenőrzésre vár. Az esemény a „Resolved” állapotba váltásból állapítható meg.
Miért fontos?

Ez fontos mérföldkő, amely a támogatási csapat aktív munkájának végét jelzi. Gyakran ez az esemény állítja meg az SLA-idő mérését.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény időbélyege az a pillanat, amikor az állapot „Resolved” vagy azzal egyenértékű értékre vált.

Rögzítés

Keresse meg az állapot „Resolved” értékre váltásának időbélyegét.

Eseménytípus inferred
Ügyfélre várakozik
Azt jelöli, amikor a támogatási csapat az ügyféltől vár információt vagy intézkedést. Az esemény egy erre szolgáló várakozó állapotba, például „Waiting for customer” állapotba történő váltásból állapítható meg.
Miért fontos?

A várakozási idő elkülönítése elengedhetetlen a pontos SLA-méréshez, mivel ezt az időt gyakran nem számítják bele a megoldási időbe. Az elemzés az ügyfél válaszidejének vizsgálatát is segíti.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény időbélyege az a pillanat, amikor az állapot „Waiting for customer” vagy hasonló értékre vált.

Rögzítés

Keresse meg az állapot „Waiting for customer” értékre váltásának időbélyegét.

Eseménytípus inferred
Átmeneti megoldás biztosítva
A szolgáltatás helyreállítását célzó ideiglenes javítás bevezetését jelöli, amíg a végleges megoldás készül. Az esemény állapotváltozásból vagy egy adott hozzászólásból állapítható meg.
Miért fontos?

Az átmeneti megoldás biztosításáig eltelt idő a szolgáltatás helyreállításának sebességét jelző fontos mutató. Segít elkülöníteni az ideiglenes kárenyhítést a végleges megoldástól.

Hol szerezhető be?

Ez az esemény gyakran következtetéssel állapítható meg. Jelezheti a „Workaround Provided” állapotba váltás, vagy egy olyan nyilvános hozzászólás, amely például a „workaround” kifejezést tartalmazza.

Rögzítés

Keressen egy adott állapotváltozást vagy kulcsszót a hozzászólásokban.

Eseménytípus inferred
Hozzászólás hozzáadva
Azt a kommunikációs vagy jegyzetelési eseményt jelöli, amikor egy felhasználó hozzászólást fűz az incidensjegyhez. Ez minden hozzászólás közzétételekor külön eseményként rögzül.
Miért fontos?

A hozzászólások gyakoriságának elemzése betekintést adhat a kommunikációs mintákba, az együttműködés hatékonyságába és az incidensek összetettségébe. Segít azonosítani azokat az incidenseket, amelyeknél túl sok egyeztetésre van szükség.

Hol szerezhető be?

Ez kifejezetten rögzített esemény. A Jira minden hozzászólást időbélyeggel és szerzővel együtt tárol, az ügy hozzászólásainak előzményeiben vagy az API-n keresztül.

Rögzítés

Használja az ügyhöz hozzáadott minden egyes hozzászólás időbélyegét.

Eseménytípus explicit
Incidens kiosztva
Ez a tevékenység azt jelöli, amikor az incidens kezelését először egy ügyintézőhöz vagy csoporthoz rendelik. Az esemény a „Assignee” vagy az „Assigned Group” mező első kitöltésének nyomon követésével rögzíthető.
Miért fontos?

A kezdeti válasz és a kiosztás idejét méri, amelyek az SLA-mutatók fontos elemei. Segít feltárni az aktív kivizsgálás megkezdése előtti késedelmeket.

Hol szerezhető be?

Az ügy előzményeiből állapítható meg: keresse meg az „Assignee” mező első módosítását, amikor az előző érték „Unassigned” volt.

Rögzítés

Keresse meg az „Assignee” mező első módosítását az ügy előzményeiben.

Eseménytípus inferred
Incidens prioritása megadva
Az incidens prioritásának és/vagy súlyosságának beállítását jelöli. Ez határozza meg az incidens sürgősségét és üzleti hatását. Az esemény általában abból állapítható meg, hogy a „Priority” vagy a „Severity” mezőt a létrehozás után először kitöltik vagy módosítják.
Miért fontos?

A prioritás megadásának nyomon követésével ellenőrizhető, hogy az incidenseket időben és következetesen értékelik-e. Az ebben a lépésben jelentkező késedelem közvetlenül befolyásolhatja az SLA számítását és az erőforrások elosztását.

Hol szerezhető be?

Az ügy előzménynaplójából állapítható meg, amely az összes mező módosítását rögzíti. Keresse meg a „Priority” vagy az egyéni „Severity” mező első módosítását az ügy létrehozása után.

Rögzítés

Keresse meg a „Priority” mező első módosítását az ügy előzményeiben.

Eseménytípus inferred
Incidens újranyitva
Azt jelöli, amikor egy korábban megoldott incidens ismét aktívvá válik, mert a probléma visszatért, vagy a javítás nem volt hatékony. Az esemény abból állapítható meg, hogy az állapot „Resolved” vagy „Closed” értékről nyitott állapotra vált.
Miért fontos?

Az újranyitott incidensek közvetlenül jelzik a megoldás minőségét, és az ismételt munka egyik fő mutatói. Elemzésük segít feltárni az idő előtti lezárásokat és a nem hatékony megoldásokat.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény akkor rögzül, amikor az állapot egy lezárt állapotból, például „Resolved” vagy „Closed” értékről „Open” vagy „In Progress” értékre vált.

Rögzítés

Keresse meg az állapot „Resolved” vagy „Closed” értékről nyitott állapotra váltását.

Eseménytípus inferred
Problémajegyhez kapcsolva
Akkor történik, amikor az incidenst kiváltóok-elemzés céljából egy „Problem” típusú ügyhöz kapcsolják. Ez kifejezetten rögzített esemény, amely akkor jön létre, amikor „relates to” vagy „caused by” típusú kapcsolatot hoznak létre egy „Problem” típusú ügyhöz.
Miért fontos?

A kapcsolat nyomon követése elengedhetetlen annak megértéséhez, hogy a szervezet mennyire hatékonyan jut el az incidens elhárításától a kiváltó okok elemzéséig és a megelőzésig.

Hol szerezhető be?

Ez az ügy kapcsolati előzményeiben rögzített esemény. Minden kapcsolat létrehozásához tartozik időbélyeg, és az események szűrhetők a „Problem” típusú ügyekhez vezető kapcsolatokra.

Rögzítés

Használja a „Problem” típusú ügyhöz vezető kapcsolat létrehozásának időbélyegét.

Eseménytípus explicit
Szakértői csapathoz eszkalálva
Azt jelzi, hogy az incidens magasabb szintű támogatásért szakértői csapathoz, például a 2. szintű támogatáshoz vagy a fejlesztőkhöz került. Ez az egyéni „Support Team” mező módosításából vagy egy meghatározott újrakiosztásból állapítható meg.
Miért fontos?

Megmutatja, mely incidensek igényelnek speciális szaktudást, és nyomon követi az esetek útját a különböző támogatási szintek között. Segít feltárni a szakértői csapatok szűk keresztmetszeteit és elemezni az eszkalációs mintákat.

Hol szerezhető be?

Az ügy előzményeiből állapítható meg: kövesse nyomon a kijelölt csapatot jelölő egyéni mező módosításait, vagy keresse meg az „Assignee” mező olyan módosítását, amely ismert szakértői csoport tagjához rendeli az ügyet.

Rögzítés

Keresse meg az „Assigned Team” egyéni mező módosítását vagy az adott felelősre történő átkiosztást.

Eseménytípus inferred
Ügyfél válaszolt
Azt jelzi, hogy az ügyfél megadta a kért információt, így az incidens kezelése folytatódhat. Az esemény abból állapítható meg, hogy az állapot „Waiting for customer” értékről aktív állapotra vált.
Miért fontos?

Ez a tevékenység jelöli az ügyfél miatt bekövetkezett késedelem végét. A „Waiting For Customer” állapot és e tevékenység közötti idő elemzésével meghatározható az ügyfél átlagos válaszideje.

Hol szerezhető be?

Az ügy állapotváltozásainak előzményeiből állapítható meg. Az esemény akkor történik, amikor az állapot „Waiting for customer” értékről például „In Progress” értékre vált, gyakran azért, mert az ügyfél hozzászólást fűzött az ügyhöz.

Rögzítés

Keresse meg az állapot „Waiting for customer” értékről „In Progress” értékre váltását.

Eseménytípus inferred
Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a Jira Service Managementből

Kezdheti?

Használja ezt az adatsablont az incidenskezelés fejlesztéséhez, a hatékonysági problémák feltárásához és a megoldási idő csökkentéséhez. Kezdje el még ma a folyamat fejlesztését.

Fejlessze incidenskezelését, és oldja meg gyorsabban az incidenseket

Csökkentse 35%-kal az MTTR-t, és javítsa a felhasználói elégedettséget gördülékenyebb folyamatokkal.

Próbálja ki ingyen

Nincs szükség bankkártyára • Beállítás 5 perc alatt