Adatsablon a szolgáltatáskérések kezeléséhez

Ivanti Service Manager
Adatsablon a szolgáltatáskérések kezeléséhez

Adatsablon a szolgáltatáskérések kezeléséhez

Ez a sablon útmutatást ad a szolgáltatáskérések kezelésének process mining elemzéséhez szükséges adatok összegyűjtéséhez. Bemutatja, mely attribútumokat érdemes rögzíteni, mely tevékenységeket kell követni, és hogyan nyerheti ki ezeket az adatokat a rendszeréből. Használja az útmutatót az elemzéshez szükséges eseménynapló összeállításához.
  • Javasolt attribútumok a részletes elemzéshez
  • A folyamattérképezéshez követendő fő tevékenységek
  • Útmutató az adatok kinyeréséhez a forrásrendszerből
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A szolgáltatáskérések kezelésének attribútumai

Ezeket az adatmezőket javasoljuk felvenni az eseménynaplóba, hogy részletesen elemezhesse a szolgáltatáskérések kezelésének folyamatát.
5 Kötelező 9 Javasolt 7 Nem kötelező
Név Leírás
Esemény időpontja
EventTime
Az időbélyeg, amely megadja, mikor történt egy adott tevékenység vagy esemény.
Leírás

Az esemény időpontja, más néven kezdési idő, az a pontos dátum és idő, amikor a rendszer rögzítette a tevékenységet. Ez az időbélyeg szükséges az események helyes sorrendbe állításához, és minden időalapú process mining elemzés alapja, például az átfutási, várakozási és tevékenységi idők számításához.

Miért fontos?

Ez az időbélyeg szükséges az események időrendi sorrendbe állításához és az időtartam-alapú mutatók kiszámításához, amelyek fontosak a teljesítmény elemzéséhez.

Hol szerezhető be?

Az auditnaplókban, a naplóbejegyzésekben, például a Journal.CreatedDateTime mezőben, vagy a Service Requesthez tartozó állapotváltozási rekordokban található.

Példák
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Szolgáltatásikérelem-azonosító
ServiceRequestID
Minden szolgáltatási kérelem egyedi azonosítója.
Leírás

A Service Request ID egyedileg azonosítja a felhasználó vagy a rendszer által benyújtott szolgáltatási kérelmeket. Ez kapcsolja össze a kérelemhez tartozó összes eseményt a kezdeti rögzítéstől a végleges lezárásig, így minden kérelem teljes útja elemezhető.

Miért fontos?

Ez az ügy egyedi azonosítója, amely egyetlen folyamatpéldányba kapcsolja össze a kapcsolódó tevékenységeket, és lehetővé teszi a folyamat teljes körű elemzését.

Hol szerezhető be?

Ez a Service Request üzleti objektum elsődleges kulcsa, amely a ServiceReq táblában gyakran ServiceReqNumber néven szerepel.

Példák
SR-0012345SR-0012346SR-0012347
Tevékenység neve
ActivityName
Az esemény vagy feladat neve, amely a szolgáltatási kérelem életciklusának egy adott pontján történt.
Leírás

Ez az attribútum a szolgáltatásikérelem-folyamat egy adott lépését vagy állapotváltozását írja le, például: „Kérelem jóváhagyásra benyújtva” vagy „Szolgáltatási kérelem megoldva”. A tevékenységek sorrendjének és gyakoriságának elemzése alapvető a folyamat menetének megértéséhez, a szűk keresztmetszetek azonosításához és a szabványos eljárástól való eltérések feltárásához.

Miért fontos?

Meghatározza a folyamattérkép lépéseit, így megjeleníthető és elemezhető a folyamat menete, beleértve az ismételt munkavégzést, a szűk keresztmetszeteket és az eltéréseket.

Hol szerezhető be?

Általában az Ivanti Service Manager állapotváltozásaiból, naplóbejegyzéseiből vagy az auditnapló eseményleírásaiból származik.

Példák
Szolgáltatási kérelem létrehozvaKérelem jóváhagyvaSzolgáltatási kérelem megoldvaSzolgáltatási kérelem lezárva
Forrásrendszer
SourceSystem
A rendszer, amelyből az adatokat kinyerték.
Leírás

Ez az attribútum azonosítja a folyamatadatok forrását. Ebben a nézetben az értéke állandó, és azt jelzi, hogy minden adat az Ivanti Service Managerből származik. Ez akkor fontos, ha több rendszer adatait egyesítik, mert egyértelművé teszi az adatok eredetét és kontextusát.

Miért fontos?

Fontos információt ad az adatok eredetéről, így az elemzések a megfelelő forrásrendszerhez rendelhetők, különösen több rendszer használata esetén.

Hol szerezhető be?

Ez általában az adatkinyerés során hozzáadott, állandó érték, amely az adatkészlet forrását jelöli.

Példák
Ivanti Service Manager
Utolsó adatfrissítés
LastDataUpdate
A forrásrendszerből származó legutóbbi adatfrissítés időbélyege.
Leírás

Ez az attribútum jelzi, mikor nyerték ki utoljára az adatokat az Ivanti Service Managerből. Megmutatja az elemzett adatok frissességét, így a felhasználók tudják, milyen időszakot fed le az elemzés, és mikorra várható a következő frissítés.

Miért fontos?

Tájékoztatja a felhasználókat az adatok aktualitásáról, ami fontos a rendelkezésre álló legfrissebb folyamatadatokra épülő döntésekhez.

Hol szerezhető be?

Ez az érték az adatkinyeréskor jön létre, és ekkor kerül az adatkészletbe.

Példák
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
Esemény befejezési ideje
EventEndTime
Az időbélyeg, amely megmutatja, mikor fejeződött be egy tevékenység.
Leírás

Az esemény befejezési ideje jelzi, mikor ért véget egy tevékenység. Az esemény időpontja (kezdete) és a befejezési idő közötti időtartam adja az adott tevékenység feldolgozási idejét. Ez segít azonosítani, mely folyamatlépések tartanak a legtovább, és hol vannak hatékonysági problémák vagy fejlesztési lehetőségek.

Miért fontos?

Lehetővé teszi az egyes tevékenységek időtartamának kiszámítását, ami segít feltárni a folyamat szűk keresztmetszeteit és a hosszan tartó feladatokat.

Hol szerezhető be?

Előfordulhat, hogy nincs külön mező erre a célra. Gyakran ugyanazon ügy következő tevékenységének kezdési időpontja jelöli.

Példák
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
Felelős csapat
AssignedTeam
A szolgáltatási igény kezelésére jelenleg kijelölt támogatói csapat vagy csoport.
Leírás

Ez az attribútum megmutatja, hogy egy adott időpontban melyik csapat felel az igény kezeléséért. A csapatok közötti átadások, az egyes csapatoknál töltött idő és a csapatonként kezelt igények számának elemzése segít megérteni a munkaterhelés eloszlását, feltárni a szűk keresztmetszeteket és értékelni a csapatok teljesítményét. Az adat közvetlenül támogatja az SLA-k teljesülését és az ügyintézők munkaterhelését bemutató dashboardokat.

Miért fontos?

Nyomon követi a felelősségi köröket és az átadásokat, így elemezhető a csapatok közötti késedelem, a munkaterhelés eloszlása, valamint azonosíthatók a folyamat szűk keresztmetszetét jelentő csapatok.

Hol szerezhető be?

Ez az információ általában a Service Request objektum „OwnerTeam” mezőjében vagy a kapcsolódó hozzárendelési rekordokban található.

Példák
IT-szolgáltatási ügyfélszolgálatHálózati üzemeltetésHR-támogatásLétesítménygazdálkodás
Felelős ügyintéző
AssignedAgent
A szolgáltatási igény kezelésére kijelölt felhasználó vagy ügyintéző.
Leírás

Az Assigned Agent az a konkrét személy, aki a szolgáltatási igény kezeléséért felel. Ez az attribútum lehetővé teszi az egyéni teljesítmény elemzését, ami hasznos a teljesítménymenedzsmenthez, a munkaterhelés kiegyensúlyozásához és a képzési igények feltárásához. Az ügyintézők közötti áthelyezések nyomon követésével kiszámítható például az „Átlagos áthelyezések igényenként” KPI, és feltárhatók a folyamat hatékonysági problémái.

Miért fontos?

Lehetővé teszi az egyéni munkaterhelés, a teljesítmény és az áthelyezési minták elemzését. Ezekből képzési, készségbeli vagy kezdeti irányítási problémákra lehet következtetni.

Hol szerezhető be?

Általában a Service Request objektum „Owner” mezőjében található. Minden áthelyezéskor változhat, ezért az eseménynaplóban is nyomon kell követni.

Példák
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
Megoldás időbélyege
ResolutionDateTime
A dátum és idő, amikor a szolgáltatási igényt hivatalosan megoldották.
Leírás

Ez az ügy szintjén rögzített attribútum, amely a szolgáltatás teljesítésének vagy a probléma megoldásának végső időpontját jelöli, még az igény hivatalos lezárása előtt. Ez az időbélyeg a szolgáltatási igény teljes átfutási idejének kiszámításához használt végpont. Segítségével mérhető a folyamat egészének hatékonysága és az SLA-k teljesülése.

Miért fontos?

Megadja a folyamat átfutási idejének számításához szükséges végpontot. Ez a szolgáltatásnyújtás hatékonyságának egyik fontos mutatója.

Hol szerezhető be?

A Service Request objektum külön időbélyegmezője, gyakran „ResolvedDateTime” vagy hasonló néven.

Példák
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
Prioritás
Priority
A szolgáltatási igényhez rendelt prioritási szint.
Leírás

A prioritás a szolgáltatási igény sürgősségét jelzi, jellemzően „Alacsony”, „Közepes”, „Magas” vagy „Kritikus” értékkel. Ez az attribútum alapvető annak megítéléséhez, hogy a folyamat valóban előreveszi-e a magas prioritású igényeket. Az elemzés során gyakran összehasonlítják az átfutási időt és az SLA-k teljesülését az egyes prioritási szinteken, hogy kiderüljön, megfelelően működnek-e a prioritási szabályok.

Miért fontos?

Segít felmérni a prioritási stratégia hatékonyságát, és ellenőrizni, hogy a magas prioritású igények gyorsabban rendeződnek-e, mint az alacsony prioritásúak.

Hol szerezhető be?

A Service Request objektum szokásos mezője, általában „Priority” néven.

Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
SLA állapota
SLAStatus
Jelzi, hogy a szolgáltatási igényt az SLA-határidőn belül oldották-e meg.
Leírás

Ez egy származtatott attribútum, amely a szolgáltatási igényeket „Teljesült” vagy „Megsértve” értékkel jelöli a megoldási idő és az SLA-határidő összevetése alapján. Ez az „SLA-k teljesülése” dashboard és a „Szolgáltatási szintre vonatkozó megállapodások teljesülési aránya” KPI alapja. A számítás minden ügy esetében a ResolutionDateTime és az SLADeadline értékét hasonlítja össze.

Miért fontos?

Közvetlenül méri, hogy a szolgáltatás megfelel-e a vállalt feltételeknek. Ez fontos a szolgáltatás minőségének értékeléséhez és a felhasználói bizalom fenntartásához.

Hol szerezhető be?

A „ResolutionDateTime” és az „SLADeadline” összehasonlításával számítható ki. Ha a ResolutionDateTime <= SLADeadline, az állapot „Teljesült”, ellenkező esetben „Megsértve”.

Példák
TeljesültMegsértve
SLA-határidő
SLADeadline
Az időpont, ameddig a szolgáltatási igényt várhatóan meg kell oldani.
Leírás

Az SLA-határidő az a kiszámított dátum és idő, ameddig a szolgáltatási igényt meg kell oldani a szolgáltatási szintre vonatkozó megállapodás teljesítéséhez. A célidőpontot általában olyan tényezők alapján határozzák meg, mint az igény prioritása és típusa. Az SLA teljesülését a tényleges megoldási idő és a határidő összevetésével mérik.

Miért fontos?

Ez az a viszonyítási alap, amelyhez a tényleges teljesítményt mérik. Segítségével kiszámítható az SLA-k teljesülési aránya, és azonosíthatók a veszélyeztetett igények.

Hol szerezhető be?

Gyakran az Ivanti számított mezője, amelyet a szolgáltatási szintre vonatkozó megállapodáshoz vagy szolgáltatási ajánlathoz kapcsolódó mezőkben tárolnak, például „ResolutionTargetDateTime” néven.

Példák
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
Szolgáltatási igény állapota
ServiceRequestStatus
A szolgáltatási igény állapota az esemény időpontjában.
Leírás

Ez az attribútum rögzíti a szolgáltatási igény állapotát, például „Rögzítve”, „Folyamatban”, „Függőben”, „Megoldva” vagy „Lezárva”. Az állapotváltozások gyakran meghatározzák a folyamat eseménynaplójának tevékenységeit. Az egyes állapotokban töltött idő elemzésével feltárhatók a szűk keresztmetszetek, például ha az igények túl sokáig maradnak „Függőben” állapotban.

Miért fontos?

Bármely időpontban megmutatja az igény állapotát. Ez szükséges az egyes állapotokban töltött idő kiszámításához és a folyamat elakadásainak feltárásához.

Hol szerezhető be?

A Service Request objektum szokásos mezője, jellemzően „Status” néven.

Példák
RögzítveAktívÜgyfélre várTeljesítveLezárva
Szolgáltatási igény típusa
ServiceRequestType
A szolgáltatási igény besorolása vagy kategóriája.
Leírás

Ez az attribútum kategóriákba sorolja a szolgáltatási igényeket, például „Hardverigény”, „Szoftvertelepítés” vagy „Jelszó-visszaállítás” szerint. Segítségével összehasonlítható a folyamat teljesítménye, az átfutási idő és az SLA-k teljesülése a különböző szolgáltatástípusoknál. Ezeknek az eltéréseknek az ismeretében célzottabban fejleszthetők a folyamatok, és hatékonyabban oszthatók el az erőforrások.

Miért fontos?

A folyamat igénytípus szerinti bontása megmutatja, hogy bizonyos igényeknél gyakoribbak-e a késések, az ismételt munka vagy az SLA megsértése.

Hol szerezhető be?

Valószínűleg a Service Request üzleti objektum egyik mezője, amelynek neve gyakran „Service” vagy „Category”. A pontos mezőnevekért, például a „SvcReqTmplLink_Category” mezőért, tekintse meg az Ivanti Service Manager dokumentációját.

Példák
Új hardver igényléseSzoftverhozzáférésFiók módosításaInformációkérés
Beszállító neve
VendorName
A külső beszállító neve, amely részt vett az igény megoldásában.
Leírás

Ez az attribútum azonosítja azt a külső beszállítót, akit a szolgáltatáskérés teljesítéséhez vagy az abban való közreműködéshez vontak be. Ez az adat szükséges a külső beszállítói tevékenységek időtartamát bemutató dashboardhoz, amelyen mérhető és összehasonlítható a különböző beszállítók teljesítménye. A nyomon követés segít a beszállítói kapcsolatok kezelésében és a külső függőségek okozta szűk keresztmetszetek feltárásában.

Miért fontos?

Lehetővé teszi a külső partnerek teljesítményének és a szolgáltatási igények megoldási idejére gyakorolt hatásának elemzését, támogatva a beszállítók kezelését.

Hol szerezhető be?

Ez lehet a szolgáltatási igényhez kapcsolódó feladatobjektum egyik mezője, vagy a Service Request külön mezője, ha beszállítót rendeltek hozzá.

Példák
Dell SupportOracle ConsultingMicrosoft Premiernull
Hozzárendelések száma
AssignmentCount
Hányszor rendeltek hozzá vagy helyeztek át egy szolgáltatási igényt.
Leírás

Ez a számított mutató megszámolja az egyes szolgáltatási igényekhez kapcsolódó hozzárendelési tevékenységeket, például az „Assigned to Team” és az „Assigned to Agent” eseményeket. A gyakori áthelyezés, más néven „jegypingpong”, az irányítás hatékonysági problémáira, az első kapcsolatfelvételkor történő megoldás hiányára vagy a csapatok tisztázatlan felelősségi köreire utalhat. Ez az attribútum szükséges az „Átlagos áthelyezések igényenként” KPI kiszámításához.

Miért fontos?

Számszerűsíti a nem hatékony átadásokat és az irányítási problémákat. A magas érték hosszabb megoldási időre és a felhasználók elégedetlenségére utalhat.

Hol szerezhető be?

Az adatok előkészítése során úgy számítható ki, hogy minden egyedi ServiceRequestID esetében megszámoljuk a hozzárendeléshez kapcsolódó tevékenységeket.

Példák
12345
Igénybejelentési csatorna
Channel
A csatorna vagy módszer, amelyen keresztül a szolgáltatási igényt benyújtották.
Leírás

A csatorna megmutatja, hogyan hozták létre a szolgáltatási igényt, például az önkiszolgáló portálon, e-mailben, telefonon vagy egy másik rendszer automatikus műveletével. Az igények számának és megoldási idejének csatornánkénti elemzése megmutatja, mely csatornák működnek hatékonyan, és hol van szükség folyamatfejlesztésre vagy felhasználói képzésre.

Miért fontos?

Segít megérteni a felhasználói szokásokat és a csatornák hatékonyságát. Ez alapján megalapozottabb döntések hozhatók a szolgáltatásnyújtásról és az automatizálási lehetőségekről.

Hol szerezhető be?

Gyakran a Service Request objektum „Source” vagy „CreatedBy” típusú mezőjében tárolják.

Példák
Önkiszolgáló portálE-mailTelefonKözvetlen rögzítés
Igénylő szervezeti egysége
RequestorDepartment
A szolgáltatási igényt benyújtó felhasználó szervezeti egysége.
Leírás

Ez az attribútum azonosítja annak a munkatársnak vagy rendszernek a szervezeti egységét, amely a szolgáltatási igényt kezdeményezte, például „Értékesítés”, „Pénzügy” vagy „Humánerőforrás”. Segítségével összehasonlítható a szolgáltatás minősége és az igények száma a szervezet különböző területein. Például kiderülhet, hogy egyes szervezeti egységek igényeinek megoldása tovább tart, vagy több igényt nyújtanak be.

Miért fontos?

Lehetővé teszi a szolgáltatások igénybevételének és minőségének elemzését üzleti egységenként, így feltárhatók az adott szervezeti egységre jellemző problémák és trendek.

Hol szerezhető be?

Az információ általában az igénylő felhasználói profiljából származik, amely a Service Request rekordhoz kapcsolódik. A mező neve lehet például „Department” a Profile.Employee objektumban.

Példák
PénzügyÉrtékesítésMarketingInformatika
Ismételt munka történt
IsRework
Logikai jelző, amely megmutatja, hogy a szolgáltatási igényhez kapcsolódott-e ismételt munkavégzés.
Leírás

Ez a számított jelző akkor kap igaz értéket, ha a szolgáltatási igénynél ismételt munkavégzésre utaló jel látható, például a megoldás utáni újranyitás vagy bizonyos tevékenységek ismétlődése. Egyszerűbbé teszi a „Szolgáltatási igények ismételt munkavégzési aránya” KPI kiszámítását, és segít kiszűrni a nem hatékony folyamatpéldányokat, például az „Ismételt munka és áthelyezések folyamatai” dashboardon.

Miért fontos?

Segít gyorsan azonosítani és számszerűsíteni azokat az igényeket, amelyek nem tervezett többletmunkát igényelnek, így láthatóvá válnak a minőségi és hatékonysági problémák.

Hol szerezhető be?

Az adatokból származtatott érték. A számítás alapulhat azon, hogy a „ReopenCount” értéke nagyobb nullánál, vagy felismerhet bizonyos tevékenységsorozatokat, például több „Assigned to Agent” eseményt.

Példák
truefalse
Megoldási kategória
ResolutionCategory
A szolgáltatási igény megoldásának besorolása.
Leírás

A Resolution Category strukturált módon sorolja be, hogyan oldották meg végül a szolgáltatási igényt. Gyakran hierarchikus besorolást használ, például kategóriát és alkategóriát, ami segíti a kiváltó okok elemzését és a trendek követését. Így feltárhatók a visszatérő problémák és a gyakori teljesítési műveletek, amelyek alapján fejleszthetők a szolgáltatások vagy tudásbáziscikkek készíthetők.

Miért fontos?

Megmutatja, milyen jellegű megoldások születtek, így feltárhatók a gyakori problémák, a szolgáltatásfejlesztési lehetőségek és az automatizálásra alkalmas feladatok.

Hol szerezhető be?

Gyakran a megoldás rögzítésekor kitöltött besorolási mezőkben tárolják, például „ResolutionCategory” vagy egy egyedi lezárási kód mezőben.

Példák
Felhasználói képzés szükségesSzoftver telepítveHardver megjavítvaHozzáférés megadva
Újranyitások száma
ReopenCount
Hányszor nyitottak újra egy megoldott szolgáltatási igényt.
Leírás

Ez az attribútum minden alkalommal eggyel nő, amikor egy szolgáltatási igény állapota „Megoldva” vagy „Lezárva” értékről „Aktív” értékre változik. A magas újranyitási szám arra utalhat, hogy az első megoldás nem volt megfelelő, a megoldás hiányos volt, vagy a probléma visszatér. Az adat közvetlenül támogatja a „Szolgáltatási igények ismételt munkavégzési aránya” KPI kiszámítását.

Miért fontos?

Közvetlenül méri az ismételt munkavégzést, és a megoldás minőségének fontos mutatója. A magas érték arra utal, hogy az első javítás nem volt hatékony.

Hol szerezhető be?

Ez általában a Service Request objektum számlálómezője, amelyet egy üzleti szabály növel a megfelelő állapotváltozáskor. A mező neve lehet például „ReopenCounter”.

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

A szolgáltatáskérések kezelésének tevékenységei

Ezeket a folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban a pontos folyamattérképezéshez és elemzéshez.
5 Javasolt 9 Nem kötelező
Tevékenység Leírás
Kérelem csapathoz rendelve
A szolgáltatási kérelmet egy adott támogatói csapathoz rendelik feldolgozásra. Ez a Service Request rekord „OwnerTeam” mezőjének kitöltésével vagy módosításával követhető.
Miért fontos?

Ez az esemény fontos a csapatszintű teljesítmény, a munkaterhelés eloszlása és a csapatok közötti átadási idők elemzéséhez. Segít azonosítani, mely csapatok jelentenek szűk keresztmetszetet a folyamatban.

Hol szerezhető be?

A Service Request auditelőzménye vagy naplója rögzíti az „OwnerTeam” mező változásait.

Rögzítés

Az „OwnerTeam” mező módosítását jelző esemény, amelyet általában az auditnapló rögzít.

Eseménytípus explicit
Kérelem ügyintézőhöz rendelve
Egy adott ügyintéző vállalja a szolgáltatási kérelem kezelését. Ez általában abból állapítható meg, hogy az egyéni ügyintézőt jelölő „Owner” mezőt először kitöltik vagy módosítják.
Miért fontos?

Ez jelzi a kezdeti várakozás vagy sorban állás végét. Az esemény előtti idő mérése segít feltárni az erőforrás-elosztási problémákat, és adatot szolgáltat az Agent Workload dashboardhoz.

Hol szerezhető be?

A Service Request rekord „Owner” mezőjének kitöltéséből vagy módosításából állapítható meg az auditelőzmények alapján.

Rögzítés

Az első időbélyeg, amikor a rekord létrehozása vagy a csapathoz rendelés után az „Owner” mezőbe ügyintéző neve kerül.

Eseménytípus inferred
Szolgáltatási kérelem létrehozva
Ez a tevékenység jelzi a szolgáltatási kérelem életciklusának kezdetét: az új kérelmet hivatalosan benyújtják és rögzítik az Ivantiban. Az esemény akkor keletkezik, amikor új rekord jön létre a Service Request üzleti objektumban, és létrejön az egyedi szolgáltatásikérelem-azonosító.
Miért fontos?

Ez a folyamat elsődleges kezdőeseménye. A kezdőpont és a megoldás közötti idő elemzése alapvető az átfutási idő és a folyamat hatékonyságának méréséhez.

Hol szerezhető be?

Az esemény a Service Request rekord létrehozási időbélyegéből nyerhető ki, például a ServiceReq üzleti objektum CreatedDateTime mezőjéből.

Rögzítés

A ServiceReq táblában rögzített rekordlétrehozási esemény, amelyet a létrehozás időbélyege azonosít.

Eseménytípus explicit
Szolgáltatási kérelem lezárva
A szolgáltatási kérelmet hivatalosan lezárták, további intézkedésre nincs lehetőség. Ez gyakran automatikusan történik, miután a kérelem meghatározott ideig „Resolved” állapotban volt, és az életciklus végleges lezárását jelenti.
Miért fontos?

Ez a tevékenység jelenti a folyamat végleges végét. A „Resolved” és „Closed” állapot közötti időből kiderülhet, hogy késik-e a megerősítés vagy az automatikus rendszerfolyamat.

Hol szerezhető be?

A Service Request rekord „Status” mezőjének „Closed” értékre történő módosulásából és a hozzá tartozó időbélyegből állapítható meg.

Rögzítés

Az auditelőzményekben észlelt módosítás, amikor a „Status” mező értéke „Closed” lesz.

Eseménytípus inferred
Szolgáltatási kérelem megoldva
A szolgáltatási kérelem megoldottnak minősül, és a felhasználó megkapta a megoldást. Ez elsődleges mérföldkő, amelyet a „Resolved” állapotra történő változás jelez, és gyakran leállítja az SLA-időmérést.
Miért fontos?

Ez a megoldási idő és az SLA-betartás mérésének fontos végpontja. A létrehozás és e tevékenység közötti idő a folyamat teljesítményének egyik fő KPI-ja.

Hol szerezhető be?

A Service Request rekord „Status” mezőjének „Resolved” értékre történő módosulásából és a hozzá tartozó időbélyegből állapítható meg.

Rögzítés

Az auditelőzményekben észlelt módosítás, amikor a „Status” mező értéke „Resolved” lesz.

Eseménytípus inferred
A felhasználó megadta a kért információkat
A kérelmező megadta a szükséges információkat, így az ügyintéző folytathatja a munkát. Ez akkor rögzíthető, amikor a kérelem a „Waiting for Customer” állapotból ismét aktív állapotba kerül.
Miért fontos?

Ez az esemény lezárja az információkérés folyamatát. A kérés és a válasz közötti idő a késések és az ismételt munkavégzés egyik fontos összetevője.

Hol szerezhető be?

Akkor állapítható meg, amikor a Service Request rekord „Status” mezője „Waiting for Customer” állapotból aktív állapotra, például „Active” vagy „In Progress” értékre változik.

Rögzítés

A felhasználói válaszra váró állapotból aktív állapotba történő változás észlelése.

Eseménytípus inferred
Információkérés a felhasználótól
A kijelölt ügyintézőnek további információra van szüksége a kérelmezőtől a teljesítés folytatásához. Ez akkor rögzíthető, amikor a kérelem állapota például „Waiting for Customer” értékre változik.
Miért fontos?

Ez a tevékenység a kezdeti információk hiányosságából eredő késésekre hívja fel a figyelmet. Gyakoriságának és időtartamának követése fontos az Information Request Impact Analysis elemzéshez és a folyamatfejlesztési lehetőségek feltárásához.

Hol szerezhető be?

A Service Request rekord állapotváltozásából állapítható meg, például a „Waiting for Customer” vagy „Pending” értékből.

Rögzítés

A „Status” mező módosulása egy kijelölt, felhasználói válaszra váró állapotra.

Eseménytípus inferred
Kérelem jóváhagyásra benyújtva
A szolgáltatási kérelmet a teljesítés előtt jóváhagyásra küldték. Ez általában abból állapítható meg, hogy a kérelem állapota „Submitted” vagy „Pending Approval” értékre változik, ami gyakran jóváhagyási munkafolyamatot indít el.
Miért fontos?

Ennek a tevékenységnek a követése segít feltárni a jóváhagyási szakasz késéseit. A hosszú várakozás jelentős szűk keresztmetszet lehet, amely növeli a megoldási időt és rontja a felhasználói elégedettséget.

Hol szerezhető be?

A Service Request rekord állapotváltozásából állapítható meg, például a „Submitted” vagy „Waiting for Approval” értékből. Az adat a FRS_Approval vagy a FRS_ApprovalVoteTracking üzleti objektumból is származhat.

Rögzítés

A Service Request rekord „Status” mezőjének jóváhagyásra váró állapotra történő módosítása.

Eseménytípus inferred
Kérelem jóváhagyva
A szolgáltatási kérelem megkapta az összes szükséges jóváhagyást, így megkezdődhet a teljesítése. Az esemény akkor rögzíthető, amikor a jóváhagyási munkafolyamat sikeresen lezárul, és megváltozik a kérelem állapota.
Miért fontos?

Ez a mérföldkő a jóváhagyási szakasz végét és a teljesítés kezdetét jelzi. Segítségével mérhető a jóváhagyási folyamat hatékonysága.

Hol szerezhető be?

A „Waiting for Approval” állapot „Approved” vagy „Fulfilled” értékre változásából állapítható meg. A FRS_Approval üzleti objektum külön eseményként is rögzítheti.

Rögzítés

A Service Request rekord „Status” mezőjének jóváhagyási állapotról aktív állapotra történő módosítása.

Eseménytípus inferred
Külső szolgáltató bevonva
A szolgáltatási kérelem teljesítését átadták egy külső szolgáltatónak vagy harmadik félnek. Ez általában a „Waiting for 3rd Party” vagy egy hasonló állapotra történő változásból állapítható meg.
Miért fontos?

Ez a tevékenység elengedhetetlen a beszállítói teljesítmény és a teljes ciklusidőre gyakorolt hatás méréséhez. Lehetővé teszi a beszállítókkal kapcsolatos késedelmek elemzését, és adatokat biztosít a külső beszállítói tevékenységek időtartamát bemutató dashboardhoz.

Hol szerezhető be?

A Service Request rekord állapotváltozásából állapítható meg, például a „Waiting for 3rd Party” vagy „Pending Vendor” értékből.

Rögzítés

A „Status” mező módosulása egy kijelölt, szolgáltatóra váró állapotra.

Eseménytípus inferred
Prioritás módosítva
A szolgáltatási kérelem prioritása a kezdeti létrehozás után megváltozott. Az esemény a mezőszintű változásokat rögzítő auditnaplóból vagy előzményekből nyerhető ki.
Miért fontos?

A prioritásváltozások követése fontos a Prioritization Effectiveness Overview elemzéshez. Segít megállapítani, hogy megfelelően kezelik-e az eszkalációkat, és helyes-e a kezdeti prioritás.

Hol szerezhető be?

Ez a Service Request rekord auditelőzményeiből származó, kifejezett esemény, amely a „Priority” mező változásait rögzíti.

Rögzítés

A rendszer auditnaplójában rögzített esemény, amely a „Priority” mező módosítását jelzi.

Eseménytípus explicit
Szolgáltatási kérelem teljesítve
Az ügyintéző vagy a rendszer elvégezte a szolgáltatási kérelem teljesítéséhez szükséges összes feladatot. Ez a „Fulfilled” állapotra történő változásból állapítható meg, amely gyakran megelőzi a végleges „Resolved” állapotot.
Miért fontos?

Ez a mérföldkő a műszaki vagy eljárási munka befejezését jelzi. Fontos pont az aktív ügyintézési idő méréséhez, a végső megerősítés és lezárás előtt.

Hol szerezhető be?

A Service Request rekord „Status” mezőjének „Fulfilled” értékre történő módosulásából állapítható meg.

Rögzítés

A rekord előzményeiben észlelt változás, amikor a „Status” mező értéke „Fulfilled” lesz.

Eseménytípus inferred
Szolgáltatási kérelem újranyitva
Egy korábban megoldott szolgáltatási kérelmet újraaktiváltak, mert a probléma továbbra is fennáll, vagy a megoldás nem volt megfelelő. Ez akkor rögzíthető, amikor az állapot „Resolved” értékről ismét aktív állapotra, például „Active” vagy „Assigned” értékre változik.
Miért fontos?

Ez a tevékenység közvetlenül jelzi az ismételt munkavégzést és az első megoldás alacsony minőségét. Az újranyitások elemzése segít feltárni a folyamat gyenge pontjait, és javítani a Service Request Rework Rate KPI-t.

Hol szerezhető be?

Az auditelőzményekből állapítható meg, amikor a „Status” mező „Resolved” vagy „Closed” értékről aktív állapotra változik.

Rögzítés

Állapotváltozás egy végleges állapotból („Resolved”, „Closed”) nyitott állapotba („Active”, „Assigned”).

Eseménytípus inferred
Szolgáltatási kérelem visszavonva
A felhasználó vagy az ügyintéző a megoldás előtt visszavonta a szolgáltatási kérelmet. Ez egy alternatív végállapot, amelyet a „Cancelled” vagy „Withdrawn” állapotra történő változás jelez.
Miért fontos?

Ez a folyamat nem szokványos lezárását jelenti. A kérelmek visszavonási okainak elemzése feltárhatja a kérelemkezelés problémáit vagy a felhasználói igények változását.

Hol szerezhető be?

A Service Request rekord „Status” mezőjének „Cancelled” értékre történő módosulásából állapítható meg.

Rögzítés

Az auditelőzményekben észlelt módosítás, amikor a „Status” mező értéke „Cancelled” lesz.

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

Adatkinyerési útmutatók

Adatok kinyerése az Ivanti Service Managerből

Kezdheti?

Ezzel a részletes adatsablonnal többet hozhat ki a szolgáltatáskérések kezelésének folyamatából. Kezdje el még ma a működés fejlesztését.

Kezdje el még ma fejleszteni a szolgáltatáskérések kezelését

Szüntesse meg a lassú ügyintézést, csökkentse a felhasználói elégedetlenséget, és érjen el 70%-os automatizálási arányt.

Próbálja ki ingyen

Nincs szükség bankkártyára, a beállítás csak néhány perc.