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

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

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

Ez a sablon áttekinthetően összefoglalja, milyen alapvető attribútumokat érdemes gyűjteni, és mely tevékenységeket kell nyomon követni a szolgáltatási kérelmek kezelése során. Gyakorlati útmutatót is ad az adatok hatékony kinyeréséhez a BMC Helix ITSM rendszerből. Használja az adat-előkészítés egyszerűsítésére, és kezdje el magabiztosan a process mining elemzéseket.
  • Javasolt attribútumok
  • Nyomon követendő tevékenységek
  • Útmutató az adatok kinyeréséhez a BMC Helix ITSM rendszerből
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A szolgáltatási kérelmek kezelésének attribútumai

Ezek az adatmezők szükségesek a teljes eseménynapló összeállításához és a szolgáltatási kérelmek kezelési folyamatának részletes elemzéséhez.
5 Kötelező 6 Javasolt 9 Nem kötelező
Név Leírás
Kezdési idő
EventStartTime
Az az időbélyeg, amely megmutatja, mikor kezdődött egy adott tevékenység vagy esemény.
Leírás

Ez az attribútum rögzíti a tevékenység pontos kezdési dátumát és időpontját. A napló minden eseményéhez, a kezdeti benyújtástól a végső lezárásig, kezdési idő szükséges a folyamat eseményeinek időrendi sorrendbe állításához.

Ez az időbélyeg minden időalapú process mining elemzéshez nélkülözhetetlen. Segítségével kiszámítható a ciklusidő, a tevékenységek időtartama és a lépések közötti várakozás, valamint ellenőrizhető az SLA-k teljesítése. A kezdési idő támogatja a szűk keresztmetszetek feltárását és a folyamat teljesítményének időbeli elemzését is.

Miért fontos?

A kezdési idő megadja az események időrendi sorrendjét. Ez szükséges a folyamat időtartamának kiszámításához, a késedelmek felismeréséhez és a folyamat időbeli menetének megértéséhez.

Hol szerezhető be?

Ez az „SRM:Request” űrlaphoz tartozó auditnaplók vagy állapotelőzmény-táblák időbélyegmezőinek felel meg. A kezdeti eseménynél ilyen például a „Submit Date”.

Példák
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Szolgáltatási igény azonosítója
ServiceRequestId
Minden szolgáltatási igény egyedi azonosítója, amely a teljes folyamat követésének elsődleges kulcsa.
Leírás

A szolgáltatási igény azonosítója egyedileg azonosít minden felhasználó vagy rendszer által benyújtott igényt. Ez kapcsolja össze az összes későbbi eseményt a kezdeti rögzítéstől a végső lezárásig, így az igény teljes útja elejétől a végéig elemezhető.

A process mining során ez az azonosító nélkülözhetetlen az egyes esetek tevékenységsorrendjének rekonstruálásához. Segítségével az eszköz egyetlen folyamatpéldányba rendezi az összetartozó eseményeket, például az „Igény benyújtva”, az „Igény kiosztva” és a „Szolgáltatási igény lezárva” eseményeket. Ez adja a folyamatelemzés alapját.

Miért fontos?

Ez az eset alapvető azonosítója. Nélküle nem követhető végig a szolgáltatási igény útja, így a folyamat feltárása és elemzése sem lehetséges.

Hol szerezhető be?

Ez jellemzően a BMC Helix ITSM „SRM:Request” űrlapjának „InstanceId” vagy „Request Number” mezője.

Példák
SR000010572931SR000010572932SR000010572933
Tevékenység
ActivityName
Egy adott időpontban, a szolgáltatási igény folyamatában bekövetkezett esemény vagy elvégzett feladat neve.
Leírás

Ez az attribútum a szolgáltatási igény folyamatának egy konkrét lépését vagy állapotváltozását írja le, például: „Igény felülvizsgálat alatt”, „Teljesítés folyamatban” vagy „Szolgáltatási igény megoldva”. Minden tevékenység egyetlen eseményt jelöl az igény teljes útján.

A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segítségével feltárhatók a folyamatok, azonosíthatók a szűk keresztmetszetek és elemezhetők a folyamatváltozatok. A folyamatfejlesztéshez fontos tudni, milyen tevékenységek történnek, milyen sorrendben és milyen gyakran.

Miért fontos?

A tevékenységek adják a folyamattérkép építőelemeit. Követésükkel megjeleníthető és elemezhető a folyamat menete, így láthatóvá válik, hogyan zajlik valójában a munka.

Hol szerezhető be?

Ez jellemzően az „SRM:Request” űrlap „Status” és „Status Reason” mezőinek változásaiból, illetve a kapcsolódó teljesítési alkalmazások naplóiból, például az Incident vagy Work Order adataiból származik.

Példák
Igény jóváhagyásra várTeljesítés folyamatbanSzolgáltatási igény megoldvaSzolgáltatási igény lezárva
Forrásrendszer
SourceSystem
Megadja, melyik rendszerből származnak a kinyert adatok.
Leírás

Ez az attribútum jelzi a folyamatadatok forrását. Ebben a nézetben értéke rögzítetten „BMC Helix ITSM”, vagyis a szolgáltatási igényekhez kapcsolódó összes esemény ebből a rendszerből származik.

Több integrált rendszer használatakor ez a mező segít megérteni az adatok eredetét, és forrás szerint szétválasztani őket. Egyértelművé és visszakövethetővé teszi az adatokat, különösen akkor, ha több platform adatait egyesítik.

Miért fontos?

Megadja az adatok eredetét, ami több rendszert használó környezetben fontos az adatkezeléshez, a visszakövethetőséghez és a hibakereséshez.

Hol szerezhető be?

Ez egy rögzített érték, amelyet az adatok kinyerése és átalakítása során adnak hozzá. Nem a BMC Helix ITSM saját mezője.

Példák
BMC Helix ITSM
Utolsó adatfrissítés
LastDataUpdate
Az az időbélyeg, amely megmutatja, mikor frissítették utoljára a folyamat adatait a forrásrendszerből.
Leírás

Ez az attribútum jelzi, mikor nyerték ki legutóbb az adatokat a BMC Helix ITSM-ből. Segít megítélni, mennyire frissek az elemzett adatok, és melyik időszakot fedik le.

Ez fontos metaadat minden process mining dashboardon és elemzésben. Megmutatja, hogy az eredmények közel valós idejű adatokon vagy egy korábbi időszak pillanatfelvételén alapulnak. Ez befolyásolja a levont következtetések érvényességét és relevanciáját.

Miért fontos?

Tájékoztatja a felhasználókat az adatok aktualitásáról, ami szükséges ahhoz, hogy a folyamat teljesítményéről rendelkezésre álló legfrissebb információk alapján hozzanak döntéseket.

Hol szerezhető be?

Ezt az időbélyeget az adatok kinyerése és betöltése során hozzák létre és adják hozzá.

Példák
2024-05-21T08:00:00Z
Befejezési idő
EventEndTime
Az az időbélyeg, amely megmutatja, mikor fejeződött be egy adott tevékenység vagy esemény.
Leírás

A befejezési idő jelzi a tevékenység végét. Az ITSM-rendszerekben sok tevékenység azonnali állapotváltozás, de némelyiknek mérhető időtartama van. A befejezési idővel ezek időtartama pontosan kiszámítható.

Elemzéskor a befejezési időt a kezdési idővel együtt használják az egyes tevékenységek feldolgozási idejének kiszámításához. Így megállapítható, mely konkrét feladatok veszik igénybe a legtöbb időt, nem csak az, hogy mennyi a lépések közötti várakozás.

Miért fontos?

Lehetővé teszi a tevékenységek feldolgozási idejének kiszámítását. Ez segít felismerni a nem hatékony lépéseket, és megérteni, mire fordítják az erőforrások az idejüket.

Hol szerezhető be?

Ez az érték levezethető. Egy tevékenység befejezési ideje gyakran megegyezik az ugyanahhoz az esethez tartozó következő tevékenység kezdési idejével. Az utolsó tevékenységnél a megoldás vagy a lezárás időbélyege használható.

Példák
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
Igény állapota
RequestStatus
A szolgáltatási igény állapota az esemény időpontjában, például „In Progress”, „Pending” vagy „Closed”.
Leírás

Ez az attribútum rögzíti a szolgáltatási igény állapotát a folyamat különböző pontjain. Az állapot kontextust ad az egyes tevékenységekhez, és gyakran ebből származik maga a „Tevékenység” attribútum is.

Az állapotok szerinti elemzés megmutatja, mennyi időt töltenek az igények bizonyos állapotokban, például „Pending Customer” vagy „Waiting for Approval” állapotban. Ez segít feltárni a külső függőségek vagy belső várólisták okozta szűk keresztmetszeteket és késedelmeket. Közvetlenül támogatja a Szűk keresztmetszetek azonosítása dashboardot.

Miért fontos?

Pillanatképet ad az igény állapotáról, így összehasonlítható a várakozással és az aktív munkával töltött idő. Ez fontos a szűk keresztmetszetek felismeréséhez.

Hol szerezhető be?

Ez az „SRM:Request” űrlap „Status” mezője. Az előzményértékek az auditnaplóban találhatók.

Példák
TervezésFolyamatbanFüggőbenMegoldvaLezárva
Kijelölt csapat
AssignedTeam
A szolgáltatási igényért jelenleg felelős támogatói csoport vagy csapat.
Leírás

Ez az attribútum jelöli, melyik funkcionális csoport felel a kérelem kezeléséért, például a „Help Desk”, a „Hálózati csapat” vagy az „Adatbázis-adminisztráció”. Ha az értéke megváltozik, az azt jelzi, hogy a felelősség másik csapathoz került.

A felelős csapat szerinti elemzés segít feltárni a csapaton belüli szűk keresztmetszeteket, elemezni a csapatok közötti átadásokat és összehasonlítani a különböző támogatói csoportok hatékonyságát. A Kérelmek újramunkálása és újbóli kiosztása, valamint a Triage hatékonysága dashboard alapjául szolgál, és megmutatja, hogyan kerül tovább a munka a szervezeten belül.

Miért fontos?

Segítségével elemezhető, hogyan halad a folyamat a különböző funkcionális csoportok között. Így feltárhatók az útválasztás hiányosságai, és mérhető a csapatok teljesítménye.

Hol szerezhető be?

Ez a szolgáltatási kérelemhez kapcsolódó teljesítési rekord, például Work Order vagy Incident „Assigned Group” mezőjének felel meg.

Példák
Szolgáltatási ügyfélszolgálatInfrastruktúra-támogatásAlkalmazástámogatás, 2. szint
Kijelölt ügyintéző
AssignedAgent
Az a felhasználó, aki jelenleg a szolgáltatási igényen dolgozik.
Leírás

Ez az attribútum azonosítja azt az IT-ügyintézőt vagy támogatót, aki egy adott időpontban felelős az igényért. Ha az értéke az igény folyamata során megváltozik, az átadásra vagy újrakiosztásra utal.

Ez az attribútum fontos az ügyintézők teljesítményének és terhelésének elemzéséhez. Megmutatja, hogy az egyes ügyintézők hány igényt kezelnek, mennyi az átlagos megoldási idejük, és milyen gyakran osztják ki újra az igényeket. Ezek az adatok támogatják az erőforrások kezelését és a képzési lehetőségek felismerését.

Miért fontos?

A kijelölt ügyintéző követése szükséges az átadások elemzéséhez, az egyéni teljesítmény méréséhez és a támogatói csapat munkaterhelésének megértéséhez.

Hol szerezhető be?

Ez a szolgáltatási igényhez kapcsolódó teljesítési rekord, például Work Order vagy Incident „Assignee” vagy „Assigned To” mezőjének felel meg.

Példák
Bob SmithAlice JohnsonCharlie Brown
Prioritás
Priority
A szolgáltatási igényhez rendelt prioritás, amely jelzi annak üzleti hatását és sürgősségét.
Leírás

A prioritás határozza meg, milyen sorrendben és milyen gyorsan kell kezelni az igényeket. Gyakori értékei: „Critical”, „High”, „Medium” és „Low”. A prioritást általában az igény üzleti hatása és sürgőssége alapján állapítják meg.

A prioritás szerinti elemzés megmutatja, hogy a magas prioritású igények valóban gyorsabban haladnak-e, mint az alacsony prioritásúak. Ez fontos szempont a megoldási időt és az SLA-teljesítést bemutató dashboardokon, és segít ellenőrizni, hogy az erőforrások a legsürgetőbb üzleti igényekre jutnak-e.

Miért fontos?

Segít felmérni, hogy a folyamat megfelelően rangsorolja-e a munkát, és teljesíti-e a különböző üzleti hatású igényekhez elvárt szolgáltatási szinteket.

Hol szerezhető be?

Ez az „SRM:Request” űrlap „Priority” mezője.

Példák
KritikusMagasKözepesAlacsony
Szolgáltatás típusa
ServiceType
A felhasználó által igényelt szolgáltatás kategóriája vagy típusa.
Leírás

A szolgáltatás típusa az igény jellegét határozza meg, például „Új szoftver igénylése”, „Jelszó visszaállítása” vagy „Új munkatárs beléptetése”. Ez alapvető szempont a folyamatadatok szűréséhez és csoportosításához.

A folyamatelemzés során ezzel az attribútummal összehasonlítható a különböző típusú igények teljesítménye. Segít megválaszolni például, hogy mely szolgáltatástípusok megoldása tart a legtovább, vagy melyeknél kell leggyakrabban megismételni egy lépést. Ez fontos a Megoldási idő és az SLA-teljesítés dashboardokhoz.

Miért fontos?

Lehetővé teszi a szolgáltatási igények típus szerinti csoportosítását, a folyamatmenetek összehasonlítását, a típushoz kötődő problémák feltárását és a fejlesztési lépések célzott megtervezését.

Hol szerezhető be?

Ez az adat gyakran az „SRM:Request” űrlap „Title” mezőjében vagy valamelyik kategóriamezőben található. A kiválasztott katalógusbeli szolgáltatás alapján származik.

Példák
Új hardver igényléseSzoftver-hozzáférés igényléseVPN-hozzáférés beállítása
A kérelem benyújtásának csatornája
SubmissionChannel
A szolgáltatási kérelem benyújtásához használt módszer vagy csatorna.
Leírás

Ez az attribútum rögzíti, hogyan indították el a szolgáltatási kérelmet. Például önkiszolgáló portálon, e-mailben, a szervizdesknek telefonálva vagy automatikus rendszerértesítés nyomán. A különböző csatornák eltérő folyamatváltozatokhoz és megoldási időkhöz vezethetnek.

A benyújtási csatorna szerinti elemzés feltárhatja az egyes beérkezési módokhoz kapcsolódó hiányosságokat és bevált gyakorlatokat. Az önkiszolgáló portálon érkező kérelmek például gyorsabban megoldhatók, mert már az elején pontosabb adatokat tartalmaznak. Az e-mailben érkező kérelmeknél viszont több kézi triage-ra lehet szükség.

Miért fontos?

Megmutatja, hogyan hat a beérkezési mód a folyamat hatékonyságára, az adatok minőségére és a teljes átfutási időre. Ez alapján célzottan fejleszthetők az egyes csatornák.

Hol szerezhető be?

Ez gyakran kikövetkeztethető az „SRM:Request” űrlap „Client Type” vagy „Reported Source” mezőjéből, illetve a kapcsolódó teljesítési jegyekből.

Példák
Önkiszolgáló portálE-mailTelefonAutomatikusan létrehozott
A kérelmező szervezeti egysége
RequestorDepartment
A kérelmet benyújtó felhasználó üzleti területe vagy szervezeti egysége.
Leírás

Ez az attribútum a szolgáltatást igénylő személy szervezeti egységét jelöli, például a pénzügyet, a humánerőforrás-területet vagy az informatikát. Az adat általában a felhasználó rendszerbeli profiljából származik.

A folyamat szervezeti egység szerinti elemzésével feltárhatók az egyes területek igényei, kérelmezési szokásai, valamint a célzott képzés vagy szolgáltatásfejlesztés lehetőségei. Például arra is választ kaphat, hogy a pénzügyi terület kérelmeire többet kell-e várni.

Miért fontos?

Lehetővé teszi a szolgáltatások igénybevételének és a folyamat teljesítményének üzleti egységenkénti elemzését, így feltárhatók az egyes szervezeti egységekre jellemző problémák és trendek.

Hol szerezhető be?

Ez az adat általában az „SRM:Request” űrlap „Requested For” felhasználójához tartozó profilból kérhető le.

Példák
PénzügyÉrtékesítésHumánerőforrásInformatika
Átadások száma
HandoffCount
Ennyiszer osztották át a szolgáltatási kérelmet különböző ügyintézők vagy csapatok között.
Leírás

Ez a számított mutató megszámolja, hányszor változik meg az „AssignedAgent” vagy az „AssignedTeam” értéke egy szolgáltatási kérelemnél. A sok átadás a folyamat széttagoltságára, az első kapcsolatfelvételkor történő megoldás elmaradására vagy a nem hatékony útválasztásra utalhat.

Ez az attribútum az egy kérelemre jutó átlagos ügyintézői átadások KPI alapja, és a Kérelmek újramunkálása és újbóli kiosztása dashboardon is használható. A sok átadással járó esetek elemzésével javítható a triage, célzottabb képzés biztosítható, és egyszerűsíthető a megoldási folyamat. Így csökkenthetők a késések, és javítható az ügyfelek elégedettsége.

Miért fontos?

A folyamat széttagoltságát és a kommunikációs többletterhet méri. A sok átadás gyakran hosszabb megoldási idővel és alacsonyabb folyamathatékonysággal jár együtt.

Hol szerezhető be?

Ez a számított mutató úgy állítható elő, hogy minden egyedi szolgáltatásikérelem-azonosítóhoz megszámoljuk az „AssignedAgent” vagy az „AssignedTeam” attribútum különböző értékeit.

Példák
0135
Eszkalálva van
IsEscalated
Logikai jelző, amely megmutatja, hogy eszkalálták-e a szolgáltatási kérelmet.
Leírás

A jelző értéke igaz, ha a szolgáltatási kérelmet funkcionális vagy hierarchikus szinten eszkalálták. Eszkalációra általában akkor kerül sor, ha a kérelem nem a várt ütemben halad, fennáll az SLA megsértésének veszélye, vagy magasabb szintű jóváhagyásra, illetve intézkedésre van szükség.

Ez az attribútum az Eszkalációkezelés hatékonyságának elemzése dashboard alapja. Segítségével szűrhetők és elemezhetők az eszkalált kérelmek folyamatútjai. Így feltárható, mi váltja ki az eszkalációt, mennyi idő alatt oldják meg utána a kérelmeket, és mennyire hatékony az eszkalációs folyamat.

Miért fontos?

Segítségével külön elemezhetők azok a kérelmek, amelyek eszkalációt igényeltek. Ez feltárhatja a standard folyamat hiányosságait és az összetett problémák kiváltó okait.

Hol szerezhető be?

Ez általában nem egyetlen mezőből derül ki. Az auditnapló eszkalációhoz kapcsolódó tevékenységei, illetve az eszkalációs protokollt követő prioritás- vagy felelőskiosztás-változások alapján állapítható meg.

Példák
truefalse
Lezárási kód
CloseCode
A szolgáltatási kérelem lezárásának végső eredményét vagy okát jelölő kód.
Leírás

A lezárási kód egységes formában sorolja be a szolgáltatási kérelem megoldását. Ilyen érték lehet például: „A szervizdesk megoldotta”, „A felhasználó visszavonta” vagy „Duplikált kérelem”.

A lezárási kódok elemzéséből kiderül, milyen eredménnyel zárulnak leggyakrabban a kérelmek. Ha például sok kérelmet vonnak vissza a felhasználók, az elhúzódó folyamatra utalhat. A sok duplikált kérelem pedig rendszer- vagy kommunikációs problémát jelezhet. Ez az attribútum támogatja a Megoldási kategóriák pontossága dashboardot.

Miért fontos?

Strukturált adatokat ad a kérelmek eredményéről, így elemezhető a megoldások hatékonysága, valamint a befejezés vagy visszavonás oka.

Hol szerezhető be?

Ez az adat általában a szolgáltatási kérelemhez kapcsolódó teljesítési jegy „Resolution” vagy „Closure Code” mezőjében található.

Példák
SikeresA felhasználó visszavontaMár nem szükségesAutomatikus megoldás
Megoldási kategória
ResolutionCategory
A kérelem megoldásához alkalmazott megoldás besorolása.
Leírás

Ez az attribútum strukturáltan kategorizálja, hogyan oldották meg a kérelmet, például szoftverjavítással, felhasználói képzéssel vagy adathelyesbítéssel. A lezárási kódnál részletesebben írja le a megoldás jellegét.

A Megoldási kategóriák pontossága dashboardon összevethető a kezdeti szolgáltatástípussal, így ellenőrizhető, hogy a besorolások összhangban vannak-e. A megoldási kategóriák elemzése feltárja a problémák trendjeit, és segíti a megelőző problémakezelést. Például kiderülhet, ha sok kérelmet felhasználói képzéssel oldanak meg.

Miért fontos?

Megmutatja, milyen jellegű megoldásokat alkalmaznak. Segít feltárni a visszatérő problémák trendjeit, és azonosítani a megelőző problémakezelés vagy a felhasználói képzés lehetőségeit.

Hol szerezhető be?

Ez az adat a teljesítési jegy működési és termékkategória-mezői között található, gyakran „Resolution Category” néven.

Példák
FiókkezelésHardverhibaSzoftverfrissítésInformáció megadva
Sérült az SLA
IsSlaBreached
Logikai jelző, amely megmutatja, hogy az SLA-céldátum után oldották-e meg a szolgáltatási kérelmet.
Leírás

A számított jelző értéke igaz, ha a szolgáltatási kérelem végső megoldásának időbélyege későbbi az „SLA Target Date” értékénél. Kérelemszinten egyszerű, igen-nem eredményt ad az SLA teljesítéséről.

Ez az attribútum nélkülözhetetlen az SLA-megfelelés áttekintése dashboardhoz és az SLA-teljesítési arány KPI-hoz. Összesítésével könnyen kiszámítható az általános megfelelési arány, a szűrés pedig lehetővé teszi a határidőn túl teljesített és a határidőre megoldott kérelmek folyamatjellemzőinek összehasonlítását. Így feltárhatók az SLA-sértések kiváltó okai.

Miért fontos?

Egyszerűsíti az SLA-teljesítmény elemzését: az időbélyegek összehasonlítását egy logikai jelzővé alakítja, így könnyen mérhetők és megjeleníthetők a megfelelési arányok.

Hol szerezhető be?

Ez egy számított mező. A logika: HA a „Resolution Timestamp” > „SlaTargetDate”, AKKOR igaz, KÜLÖNBEN hamis.

Példák
truefalse
SLA-céldátum
SlaTargetDate
Az a dátum és időpont, ameddig a szolgáltatási szintre vonatkozó megállapodás (SLA) szerint meg kell oldani a szolgáltatási kérelmet.
Leírás

Az SLA-céldátum egy számított időbélyeg, amely a szolgáltatási kérelem teljesítésének határidejét jelöli. Az értéket a szolgáltatási megállapodás szabályai határozzák meg, amelyek gyakran a kérelem prioritását és típusát is figyelembe veszik.

Ez az attribútum az SLA-megfelelés áttekintése dashboard alapja. Viszonyítási pontként szolgál a tényleges megoldási idő méréséhez. Ha összevetjük a végső megoldási tevékenység „EventEndTime” értékét a céldátummal, megállapítható, hogy teljesült-e a szolgáltatási vállalás.

Miért fontos?

Ez a szolgáltatási vállalások teljesítésének elsődleges mércéje, ezért nélkülözhetetlen az SLA-megfelelés nyomon követéséhez és jelentéséhez.

Hol szerezhető be?

Ezt a dátumot a Service Level Management (SLM) modul számítja ki és tárolja. A szolgáltatási kérelemhez kapcsolódó SLM-űrlapokon található.

Példák
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
Újramunkálás történt
IsRework
Logikai jelző, amely megmutatja, hogy a szolgáltatási kérelmet újra kellett-e dolgozni, például vissza kellett-e lépni egy korábbi szakaszba.
Leírás

Ez a jelző azokat a szolgáltatási kérelmeket azonosítja, amelyek folyamatában visszalépés vagy újramunkálás történt. Újramunkálásnak számít például, ha egy kérelem a „Teljesítés folyamatban” állapotból visszakerül a „Kérelem felülvizsgálata” szakaszba. A pontos meghatározás az üzleti folyamat logikájától függ.

Ez az attribútum közvetlenül támogatja a Kérelmek újramunkálása és újbóli kiosztása elemzése dashboardot, valamint a Kérelmek újramunkálási aránya KPI-t. Segítségével mérhető az újramunkálás gyakorisága és feltárhatók a gyakori okok, például a hibás kezdeti felmérés vagy a hiányos információ. Ezek a folyamat hatékonyságát rontják.

Miért fontos?

Jelzi, ha egy eset eltér a szokásos folyamattól, így mérhető a folyamat hatékonyságvesztése, és feltárhatók a visszalépések, illetve az ismételt munka kiváltó okai.

Hol szerezhető be?

Ez egy számított attribútum, amely az eseménynapló tevékenységeinek sorrendjéből származik. A folyamatban történő visszalépések felismeréséhez külön logikára van szükség.

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

A szolgáltatási kérelmek kezelésének tevékenységei

A pontos folyamatfeltáráshoz és -megjelenítéshez ezeket a fontos folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban.
6 Javasolt 8 Nem kötelező
Tevékenység Leírás
Igény kiosztva
A szolgáltatási igényt a munka elvégzéséért felelős ügyintézőhöz vagy csapathoz rendelték. Ezzel véget ér a besorolási szakasz.
Miért fontos?

Ez a mérföldkő fontos a besorolási idő méréséhez és az ügyintézők terhelésének elemzéséhez. A gyakori újrakiosztás útválasztási problémára vagy készséghiányra utalhat.

Hol szerezhető be?

Az esemény közvetlenül rögzíthető az SRM:Request vagy a kapcsolódó teljesítési alkalmazás űrlapjainak, például a WOI:WorkOrder űrlapnak az „Assigned Group” vagy „Assignee” mezőjéhez tartozó auditnaplóból.

Rögzítés

Az auditnaplóban szereplő időbélyeg, amely azt mutatja, mikor kapott először nem üres értéket az „Assignee” mező.

Eseménytípus explicit
Szolgáltatási igény benyújtva
Ez a tevékenység jelzi, hogy egy felhasználó létrehozott és benyújtott egy új szolgáltatási igényt. Akkor rögzíthető, amikor az SRM:Request űrlapon új rekord jön létre, kezdeti állapota jellemzően „Submitted”.
Miért fontos?

Ez minden szolgáltatási igény folyamatának kezdőpontja. Nélkülözhetetlen a teljes ügyintézési idő méréséhez és a beérkező igények számának elemzéséhez.

Hol szerezhető be?

Az esemény az SRM:Request űrlapon szereplő rekord létrehozási időpontjából és kezdeti állapotából, például a „Submitted” értékből következtethető ki.

Rögzítés

Keresse meg az új szolgáltatási igény azonosítójához tartozó létrehozási időpontot az SRM:Request űrlapon, amikor az állapot „Submitted”.

Eseménytípus inferred
Szolgáltatási igény lezárva
A szolgáltatási igényt hivatalosan lezárták, és csak olvasható, archivált állapotba helyezték. Erre a megoldás után, valamint a visszaigazolási időszak leteltével kerül sor.
Miért fontos?

Ez a tevékenység jelzi a folyamat tényleges végét. A „Resolved” és a „Closed” közötti idő feltárhatja a lezárási eljárás hiányosságait.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot végső „Closed” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Closed” értékre változik.

Eseménytípus inferred
Szolgáltatási igény megoldva
A szolgáltatási igény teljesítése befejeződött, a megoldásról pedig tájékoztatták az igénylőt. Az igény a végső visszaigazolásra vár, vagy egy meghatározott idő elteltével automatikusan lezárul.
Miért fontos?

Ez fontos mérföldkő, amely jelzi a szolgáltatásnyújtási ciklus végét. Ez a megoldási idő és az SLA-teljesítés mérésének elsődleges végpontja.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Resolved” vagy „Completed” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Resolved” vagy „Completed” értékre változik.

Eseménytípus inferred
Szolgáltatási igény visszavonva
Az igénylő vagy az ügyfélszolgálat visszavonta a szolgáltatási igényt, mielőtt a teljesítés befejeződött volna. Ez az igény végállapota.
Miért fontos?

A visszavonások követése segít feltárni a jellemző okokat, például a tévesen benyújtott igényeket vagy azt, ha egy szolgáltatásra már nincs szükség. Ezek az információk segíthetik a szolgáltatáskatalógus fejlesztését.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Canceled” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Canceled” értékre változik.

Eseménytípus inferred
Teljesítés folyamatban
A kijelölt ügyintéző vagy csapat megkezdte a szolgáltatási igény teljesítését. Ez azt jelzi, hogy az igény kikerült a várólistáról, és aktív munkavégzés kezdődött rajta.
Miért fontos?

Ez jelzi az értékteremtő teljesítési munka kezdetét. Az ebben a szakaszban eltöltött idő elemzése segít megérteni az erőforrások termelékenységét és a teljesítés összetettségét.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „In Progress” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „In Progress” értékre változik.

Eseménytípus inferred
A felhasználó visszaigazolta a megoldást
Az igénylő megerősítette, hogy a szolgáltatást megfelelően teljesítették, és az igény megoldódott. Ez gyakran elindítja az igény végleges lezárását.
Miért fontos?

Ez egyértelműen jelzi az ügyfél elégedettségét, és hivatalosan lezárja a szolgáltatási kapcsolatot. Elkülöníti a folyamat lezárását az ügyfél elfogadásától.

Hol szerezhető be?

Az esemény rögzíthető az SRM:Request munkanaplójában vagy tevékenységi megjegyzéseiben, ha a felhasználó a portálon vagy e-mailben visszaigazolja a megoldást. Ez nem mindig jelenik meg külön állapotként.

Rögzítés

Keresse meg az SRM:WorkInfo munkanaplóiban a felhasználói visszaigazolásra vagy a felmérés kitöltésére utaló bejegyzéseket.

Eseménytípus explicit
Igény elutasítva
A szolgáltatási igényt a jóváhagyási szakaszban elutasították. Ez a végállapot megállítja a folyamatot, mielőtt megkezdődne a teljesítés.
Miért fontos?

Az elutasított igények elemzése rámutathat az indoklásokkal, a jogosultsági feltételekkel vagy a jóváhagyási szabályokkal kapcsolatos problémákra.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Rejected” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Rejected” értékre változik.

Eseménytípus inferred
Igény felülvizsgálat alatt
A szolgáltatási igényt az ügyfélszolgálat első körben áttekinti és besorolja, hogy meghatározza annak jellegét, prioritását és a teljesítésért felelős csapatot. Ezt jellemzően az igényrekord állapotának módosítása jelzi.
Miért fontos?

Ennek a tevékenységnek a követése segít mérni a besorolás hatékonyságát, és feltárni a benyújtás és a kiosztás közötti késedelmeket. Ez fontos az „Átlagos besorolási idő” KPI méréséhez.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „In Review” vagy „Planning” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „In Review” értékre változik.

Eseménytípus inferred
Igény folytatása
A szolgáltatási igény kikerült a függőben lévő vagy várakozó állapotból, jellemzően azután, hogy a felhasználó megadta a kért információt. A teljesítésért felelős ügyintéző folytatja az igény kezelését.
Miért fontos?

Ez jelzi a várakozási időszak végét, így pontosan mérhető a külső várakozás és annak hatása az SLA-k teljesítésére.

Hol szerezhető be?

Akkor következtethető ki, amikor az SRM:Request állapota „Pending” értékről ismét „In Progress” értékre változik.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Pending” értékről „In Progress” értékre változik.

Eseménytípus inferred
Igény jóváhagyásra vár
A szolgáltatási igényt elküldték a kijelölt jóváhagyónak vagy jóváhagyói csoportnak, és az a döntésre vár, mielőtt megkezdődhetne a teljesítés. Ez gyakori lépés költséggel vagy hozzáférési jogosultságokkal járó igényeknél.
Miért fontos?

Ez a tevékenység elkülöníti a jóváhagyáshoz kapcsolódó késedelmeket. Így elemezhető a jóváhagyási ciklus ideje, és feltárhatók a jóváhagyási folyamat szűk keresztmetszetei.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Waiting Approval” értékre változásából következtethető ki.

Rögzítés

Annak a frissítési eseménynek az időbélyege, amelyben az SRM:Request „Status” mezője „Waiting Approval” értékre változik.

Eseménytípus inferred
Igény jóváhagyva
Az illetékes fél hivatalosan jóváhagyta a szolgáltatási igényt, így megkezdődhet a teljesítés. Ez az esemény jellemzően a „Waiting for Approval” állapot után következik.
Miért fontos?

Ez jelzi a jóváhagyási részfolyamat végét. Fontos mérföldkő a jóváhagyás időtartamának és a teljes megoldási időre gyakorolt hatásának méréséhez.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Waiting Approval” értékről egy következő állapotra, például „Planning” vagy „In Progress” értékre változásából következtethető ki. Maga a jóváhagyási döntés a kapcsolódó jóváhagyási űrlapokon szerepel.

Rögzítés

Annak az állapotváltozásnak az időbélyege, amely pozitív jóváhagyási döntés után kivezeti az igényt a „Waiting Approval” állapotból.

Eseménytípus inferred
Megoldás bevezetve
Az ügyintéző elvégezte a szolgáltatási igény teljesítéséhez szükséges műszaki munkát. Az igény készen áll arra, hogy a felhasználó visszaigazolja a megoldást, mielőtt hivatalosan lezárnák.
Miért fontos?

Ez a tevékenység elkülöníti a műszaki munka befejezését a hivatalos lezárástól, így feltárhatók a munka elvégzése és a felhasználói visszaigazolás közötti késedelmek.

Hol szerezhető be?

Ez egy háttérrendszerben kezelt teljesítési jegy állapotváltozásából következtethető ki, például abból, hogy a Work Order állapota „Completed” lesz, mielőtt a kapcsolódó SRM:Request állapota „Resolved” értékre változik.

Rögzítés

Annak az időpontja, amikor az SRM:Requesthez kapcsolódó háttérrendszerbeli jegyet, például Work Ordert vagy Incidentet befejezettként jelölik meg.

Eseménytípus inferred
További információ kérése a felhasználótól
A teljesítésért felelős ügyintézőnek további információra van szüksége az igénylőtől a munka folytatásához. Az igény ilyenkor jellemzően „Pending” állapotba kerül.
Miért fontos?

Ez a tevékenység szükséges a „Külső információra várakozás” méréséhez, és megmutatja, milyen gyakran akadnak el az igények hiányos információ miatt.

Hol szerezhető be?

Az SRM:Request űrlapon az állapot „Pending” értékre változásából következtethető ki, ha az állapot oka például „Customer Hold” vagy „Awaiting Information”.

Rögzítés

A „Pending” állapotra váltás időbélyege, egy konkrét állapotokkal együtt.

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

Adatkinyerési útmutatók

Így nyerheti ki az adatokat a BMC Helix ITSM rendszerből

Készen áll a kezdésre?

Használja ezt a sablont az adatgyűjtés egyszerűsítésére, és kezdje el magabiztosan a process mining elemzéseket. Kezdje el még ma fejleszteni a szolgáltatási kérelmek kezelését!

Növelje a hatékonyságot: fejlessze még ma a szolgáltatási kérelmek kezelését

Érje el a 70%-os automatizálást, szüntesse meg a lassú teljesítést, és tegye elégedettebbé a felhasználókat.

Kezdje el a próbaverziót

Nincs szükség bankkártyára, percek alatt elkezdheti.