Adatsablon a szolgáltatási kérelmek kezeléséhez

A Start Time rögzíti egy adott tevékenység pontos kezdési dátumát és időpontját. Ez az időbélyeg szükséges az események időrendi sorrendbe állításához, valamint a tevékenységek és a teljes ügy életciklusának időtartam-számításához. A pontos eseménynapló összeállításához minden tevékenységhez tartoznia kell kezdési időpontnak.

A folyamat elemzésekor a Start Time alapján számíthatók ki a fő teljesítménymutatók, például a ciklusidő, a tevékenységek közötti várakozási idő és a feldolgozási idő. Időalapú nézetet ad a folyamatról, kiemeli a késéseket, és segít megállapítani, mely lépések tartanak a legtovább. A teljesítmény elemzéséhez pontos időbélyegekre van szükség.

Az időbélyeg segít az események helyes sorrendbe állításában és az időalapú mutatók, például a ciklusidő és a szűk keresztmetszetek kiszámításában.

Az eseménynaplóban vagy az auditnapló tábláiban található, gyakran az egyes tevékenységrekordok „létrehozás dátuma” vagy „esemény időbélyege” mezőjeként.

A Service Request ID az elsődleges kulcs, amely az életciklusa során egyedileg azonosítja az egyes szolgáltatási igényeket. Ügyazonosítóként összekapcsolja az igényhez tartozó tevékenységeket, állapotváltozásokat és attribútumokat, így egyetlen folyamatpéldányt alkotnak.

A process mining elemzésben ez az azonosító alapvető az egyes igények teljes folyamatának rekonstruálásához. Ha az elemzők az eseményeket közös CaseId alapján csoportosítják, megjeleníthetik a folyamatmeneteket, kiszámíthatják az ügyek átfutási idejét, és feltárhatják az igények kezelésének eltéréseit. Ez az alapja a szolgáltatásigény-kezelési folyamat elemzésének.

Ez az azonosító kapcsolja össze a szolgáltatási igényhez tartozó eseményeket, így a teljes folyamat végigkövethető.

Általában a szolgáltatási igények fejlécében vagy fő tranzakciós táblájában található.

A Tevékenység attribútum a szolgáltatáskérésen végrehajtott konkrét lépést vagy műveletet írja le. Ezek a tevékenységek alkotják a folyamat egymást követő lépéseit, például „Kérés létrehozva”, „Kérés hozzárendelve”, „Folyamatban” és „Kérés lezárva”. Mindegyik tevékenység a szolgáltatáskérés útjának egy adott időpontját jelöli.

A tevékenységek elemzése a process mining alapja. Segítségével feltárható és megjeleníthető a folyamat tényleges menete. A tevékenységek sorrendjét és gyakoriságát vizsgálva az elemzők azonosíthatják a gyakori útvonalakat, a szabványos folyamattól való eltéréseket, azokat a szűk keresztmetszeteket, ahol elakadnak a kérések, valamint a szükségtelenül ismétlődő lépéseket.

Meghatározza a folyamat lépéseit, így feltárhatók a tényleges folyamatmenetek, a szűk keresztmetszetek és az eltérések.

Gyakran az igényhez kapcsolódó állapotváltozási naplókból, eseménytáblákból vagy auditnaplókból származik.

A Source System attribútum annak az IT Service Management (ITSM) platformnak vagy más alkalmazásnak a nevét adja meg, amelyből az adatokat kinyerték. Több rendszer használatakor ez a mező segít megkülönböztetni az adatforrásokat, és nyomon követhetővé teszi az adatok eredetét.

A legtöbb folyamatmenet-elemzésben közvetlenül nem használják, de az adatirányítás, az ellenőrzés és a hibakeresés szempontjából fontos. Több forrásból származó adatok egyesítésekor az elemzők rendszer szerint szűrhetik a folyamatnézetet, így feltárhatják a folyamatvégrehajtás vagy az adatminőség platformok közötti eltéréseit.

Segít az adatirányításban és a hibakeresésben, mert megmutatja az adatok eredetét, különösen több integrált rendszer használatakor.

Ezt az értéket általában az adatkinyerés (ETL) során adják hozzá, nem a forrásrendszer eredeti mezője.

A Last Data Update az utolsó adatkinyerés vagy frissítés időpontját jelzi. Segít megítélni, mennyire frissek az elemzett adatok, és hogy az elemzés az aktuális állapotot vagy egy korábbi állapotot tükröz-e.

Ez az attribútum fontos a működés nyomon követéséhez és a jelentésekhez, mert megmutatja, mennyire időszerűek az elemzés eredményei. Segít megbízni az adatokban, és azok frissessége alapján megalapozott döntéseket hozni. Másként kell értelmezni például egy olyan dashboardot, amelynek adatai egy hete frissültek, mint azt, amelyiké egy órája.

Megmutatja, mennyire frissek az adatok, így ellenőrizhető, hogy az elemzések naprakész információkon alapulnak-e.

Ez a metaadatmező általában az adatkinyerés (ETL) során jön létre és kerül tárolásra.

A Request Status megmutatja a szolgáltatási igény állapotát az életciklus egy adott pontján. Gyakori állapotok: Új, Folyamatban, Függőben, Megoldva és Lezárva. Ez az attribútum jelzi, hol tart az igény a teljes folyamatban.

A Request Status elemzése segít megérteni a folyamatmenetet és az állapotváltozásokat. Az igények szűrésére, az adott állapotban elakadt ügyek azonosítására és az egyes állapotokban töltött idő mérésére használható. Ha például megvizsgálja, mennyi ideig maradnak az igények „Függőben” állapotban, feltárhatja a felhasználóktól vagy külső csapatoktól várt információk miatti késéseket.

Megmutatja, mennyi időt töltenek az igények az egyes állapotokban, így feltárhatók a folyamat szűk keresztmetszetei és késései.

A szolgáltatási igények fő táblájában vagy az állapotváltozások naplóiban található.

A Request Priority besorolás segít a támogatási csapatoknak meghatározni az igények kezelési sorrendjét. A prioritás általában az igény üzleti hatása és sürgőssége alapján alakul ki. Gyakori szintek: Alacsony, Közepes, Magas és Kritikus.

Ez az attribútum fontos a teljesítmény elemzéséhez és az erőforrások elosztásához. Az elemzők összehasonlíthatják a ciklusidőt és az SLA-megfelelést a különböző prioritási szinteken, így ellenőrizhetik, hogy a magas prioritású igényeket megfelelően kezelik-e. Azt is megmutatja, ha az alacsony prioritású igények háttérbe szorulnak, vagy ha a támogatási csapatok nem tartják be a prioritási szabályokat.

Segít ellenőrizni, hogy az igényeket üzleti jelentőségük szerint kezelik-e, és megmutatja, hogyan hat a prioritás a megoldási időre.

Általában a szolgáltatási igény fő rekordjának szabványos mezője.

Az Assigned Team a szolgáltatási igényért felelős konkrét támogatási csoportot jelöli. A szükséges szaktudástól függően az igényeket gyakran különböző csapatokhoz irányítják, például első szintű ügyfélszolgálathoz, hálózati csapathoz vagy szoftverfejlesztőkhöz.

A csapatok közötti átadások elemzése a szolgáltatáskezelési folyamatok process mining elemzésének fontos része. Ez az attribútum megmutatja a csapatok közötti átadásokat, így feltárhatók a kommunikációs hiányosságok és a késések. A csapatok teljesítménye is összehasonlítható az igények kezelési hatékonysága, mennyisége és további eszkaláció nélküli megoldása alapján.

Segít elemezni a csapatok közötti átadásokat, feltárni az átadási késéseket és összehasonlítani a csapatok teljesítményét.

A szolgáltatási igény rekordjának szabványos mezője. A változásait auditnaplóban rögzítik.

Az Assigned Agent az a konkrét személy, aki egy adott időpontban a szolgáltatási igény kezeléséért felel. Az igény életciklusa során több ügyintézőhöz is kerülhet.

Ez az attribútum fontos a teljesítmény és a munkaterhelés elemzéséhez. Segítségével összehasonlítható az egyes ügyintézők teljesítménye, például az átlagos megoldási idejük és a kezelt igények száma. Az ügyintézők közötti újrakiosztások elemzésére is használható, amelyek a kezdeti besorolás, a szaktudás vagy a munkaterhelés elosztásának problémáira utalhatnak.

Lehetővé teszi az egyes ügyintézők teljesítményének, munkaterhelésének és az ügyintézők közötti újrakiosztások gyakoriságának elemzését.

A szolgáltatási igény rekordjában található. A mező változásait gyakran auditnaplóban vagy előzménytáblában rögzítik.

Az SLA Due Date az igényhez tartozó szolgáltatási szintre vonatkozó megállapodás alapján meghatározott célidőpont. Az igény prioritása, típusa és létrehozási ideje alapján számítják ki, és ez jelöli a megoldás elvárt határidejét.

Ez az attribútum az SLA-megfelelés elemzésének alapja. A tényleges megoldási idő és az SLA Due Date összevetésével megállapítható, hogy az igényt határidőre oldották-e meg, vagy sérült az SLA. Ez a szolgáltatás minőségét mérő fontos KPI, amely segít feltárni a késéseket és az SLA-sértésekhez vezető rendszerszintű problémákat.

Ez a teljesítménymérés viszonyítási alapja. Segítségével kiszámítható az SLA-megfelelési arány, és azonosíthatók a határidőn túl megoldott igények.

Gyakran a szolgáltatási igény rekordjának számított mezője, amelyet az alkalmazott SLA-szabályzat határoz meg.

A Service Type a szolgáltatási igény jellegét sorolja kategóriába. Ide tartozhat új hardver igénylése, szoftverhozzáférés kérése, általános kérdés vagy műszaki támogatás. A kategorizálás segít a megfelelő csapathoz irányítani az igényt, és megérteni az egyes szolgáltatások iránti keresletet.

A folyamat elemzésekor a Service Type hasznos szempont az adatok csoportosításához. Ha a folyamattérképet szolgáltatástípus szerint szűri, kiderülhet, hogy egyes igénytípusok eltérő folyamatot követnek, hosszabb a ciklusidejük, vagy gyakrabban kell újramunkát végezni. Ez alapján célzottan fejleszthetők az egyes szolgáltatási kategóriák folyamatai.

Lehetővé teszi a különböző igénykategóriák folyamatainak szűrését és összehasonlítását, így típusonként feltárhatók a szűk keresztmetszetek és a hatékonysági problémák.

A szolgáltatási igény rekordjának szabványos mezője, amely gyakran egy szolgáltatáskatalógushoz kapcsolódik.

Az End Time rögzíti egy adott tevékenység pontos befejezési dátumát és időpontját. Míg a Start Time a kezdést, az End Time a befejezést jelöli, így meghatározható egy folyamatlépés időtartama. Nem minden eseményhez tartozik külön befejezési időpont, mert egyes események azonnal lezajlanak.

Ez az attribútum szükséges az egyes tevékenységek feldolgozási idejének kiszámításához. A Start Time és az End Time különbségéből megállapítható, mennyi időt töltöttek az ügyintézők vagy a rendszerek tényleges munkával. Így azonosíthatók a legtöbb időt igénylő tevékenységek, amelyek fejlesztése vagy automatizálása szóba jöhet.

Lehetővé teszi a tevékenységek feldolgozási idejének kiszámítását, így azonosíthatók a folyamat legtöbb időt igénylő lépései.

Az eseménynaplóban vagy az auditnapló tábláiban található. Ha nincs külön rögzítve, a következő tevékenység Start Time értékéből kell meghatározni.

A Submission Channel megmutatja, hogyan hozták létre a szolgáltatási igényt, például önkiszolgáló portálon, e-mailben, telefonon vagy API-n keresztül. Az egyes csatornákhoz eltérő folyamatok és felhasználói elvárások kapcsolódhatnak.

A folyamat benyújtási csatorna szerinti elemzése hasznos összefüggéseket tárhat fel. Az önkiszolgáló portálon benyújtott igények például strukturáltabbak lehetnek, és gyorsabban megoldhatók, mint az e-mailben érkezők, amelyeknél kézi adatrögzítésre lehet szükség. Az elemzés segíthet a hatékonyabb csatornák népszerűsítésében vagy a kevésbé hatékonyak fejlesztésében.

Segít megállapítani, hogy a benyújtás módja hogyan hat a folyamat hatékonyságára, a megoldási időre és az első kapcsolatfelvételkor megoldott igények arányára.

Általában a szolgáltatási igény rekordjának szabványos mezője.

Ez az attribútum azonosítja annak a személynek a részlegét vagy üzleti egységét, aki elindította a szolgáltatási igényt. Szervezeti hátteret ad az igényhez.

A részlegenkénti elemzés feltárhatja az adott egységre jellemző igényeket, trendeket és problémákat. Ha például a pénzügyi részlegtől sok azonos típusú igény érkezik, célzott képzésre vagy rendszerfejlesztésre lehet szükség. Az adatok a költségek részlegek közötti elszámolását és a szervezet IT-szolgáltatásai iránti kereslet megértését is segítik.

Szervezeti hátteret ad, így az igények mintázata és a szolgáltatások iránti kereslet üzleti egységenként elemezhető.

Ezt az információt általában az igénylő felhasználói profiljából, a dolgozói címtárból vagy az ITSM-rendszerből veszik át.

A Resolution Code egységesen kategorizálja a szolgáltatási igények eredményét. Példák: „Felhasználó megoldotta”, „Hardver cserélve”, „Szoftver telepítve” vagy „Duplikált igény”. Ezt az információt általában az ügyintéző adja meg az igény lezárásakor.

Ezek a kódok hasznosak a kiváltó okok elemzéséhez. A különböző megoldási kódok gyakoriságát vizsgálva feltárhatók a visszatérő problémák, a gyakori megoldások, valamint a tudásbáziscikkek vagy automatizált megoldások létrehozásának lehetőségei. Ha például sok igény zárul „Jelszó-visszaállítás” kóddal, érdemes lehet önkiszolgáló jelszó-visszaállító eszközbe fektetni.

A megoldások kategorizálásával segít feltárni a kiváltó okokat, a trendeket és a problémák megelőző kezelésének lehetőségeit.

Ezt a mezőt általában az ügyintéző tölti ki kézzel a szolgáltatási igény megoldásakor vagy lezárásakor.

Ez a logikai attribútum jelzi, hogy a szolgáltatási igény teljesítette-e a meghatározott szolgáltatási szintre vonatkozó megállapodást. Értéke igaz, ha az igényt az „SlaDueDate” után oldották meg, egyébként hamis.

Az attribútum egyszerűsíti az SLA-megfelelés jelentését és elemzését. Nem kell minden lekérdezésben dátumokat összehasonlítani, elég ezt a jelzőt szűrni és összesíteni. Az SLA-teljesítményt bemutató dashboardok egyik fő mutatója, amely gyorsan megmutatja a szolgáltatási célokat nem teljesítő igények számát és arányát.

Egyszerű jelzőt ad az SLA-teljesítmény elemzéséhez, így könnyen szűrhetők és jelenthetők a határidőn túl megoldott igények.

Ez egy származtatott attribútum, amelyet az adatátalakítás során a végső megoldási időbélyeg és az „SlaDueDate” mező összehasonlításával számítanak ki.

A Reassignment Count azt mutatja meg, hányszor került át a szolgáltatási igény egyik ügyintézőtől vagy csapattól a másikhoz. A magas érték hibás kezdeti továbbításra, az ügyintézők hiányos ismereteire vagy tisztázatlan felelősségi körökre utalhat.

Ez a folyamat hatékonyságának fontos mutatója. A process mining elemzésben számszerűsíti, hányszor kerül az igény egyik helyről a másikra. A sok újrakiosztással járó ügyek elemzése feltárhatja a kezdeti besorolás fejlesztésének, az ügyintézők képzésének vagy a csapatok felelősségi köreinek pontosításának lehetőségeit, hogy az igények már elsőre a megfelelő helyre kerüljenek.

A folyamat hatékonyságának fontos mutatója. A sok újrakiosztás gyakran hosszabb megoldási idővel és elégedetlen felhasználókkal jár együtt.

Számított mutató, amely az adott „CaseId” esetén az „AssignedAgent” vagy az „AssignedTeam” mező változásainak számát adja meg.