Változáskezelési adatsablon

ServiceNow
Változáskezelési adatsablon

Változáskezelési adatsablon

Ez a sablon rendszerezetten mutatja be, milyen adatokat érdemes összegyűjteni a változáskezelési munkafolyamat hatékony process mining elemzéséhez. Javaslatot ad a követendő attribútumokra és tevékenységekre, valamint gyakorlati útmutatást nyújt az adatok kinyeréséhez. Használja az adatok előkészítéséhez és a folyamat elemzéséhez, illetve fejlesztéséhez.
  • Javasolt attribútumok
  • A pontos folyamattérképezéshez követendő fő tevékenységek
  • Útmutató az adatok ServiceNow-ból történő kinyeréséhez
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Változáskezelési attribútumok

Ezeket az adatmezőket javasoljuk felvenni az eseménynaplóba a változáskezelési folyamat részletes elemzéséhez.
3 Kötelező 7 Javasolt 9 Nem kötelező
Név Leírás
Esemény időpontja
EventTime
Annak a pontos időpontja, amikor egy adott tevékenység vagy esemény történt.
Leírás

Az esemény időpontja rögzíti, hogy egy tevékenységet pontosan mikor hajtottak végre, vagy mikor jegyeztek be egy állapotváltozást. Ez az időbélyeg szükséges az események időrendi sorba rendezéséhez és minden időtartam-alapú elemzéshez.

A process mining az attribútum alapján számítja ki a ciklusidőket, a feldolgozási időket és a tevékenységek közötti várakozási időket. A teljesítményt elemző dashboardok, például a Change Approval Cycle Time és az End-to-End Change Process Flow is erre támaszkodnak. A pontos időbélyegek alapozzák meg a késések feltárását és a folyamat hatékonyságának SLA-khoz viszonyított mérését.

Miért fontos?

Ez az időbélyeg szükséges az események helyes sorrendjének meghatározásához és minden időalapú mutató kiszámításához, beleértve a ciklusidőt, az időtartamokat és az SLA-k teljesülését.

Hol szerezhető be?

ServiceNow tábla: sys_audit, mező: sys_created_on. Ez adja meg az egyes rögzített változások időbélyegét.

Példák
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
Változtatási kérelem azonosítója
ChangeRequestNumber
A változtatási kérelem egyedi azonosítója, amely elsődleges esetazonosítóként összekapcsolja a hozzá tartozó eseményeket.
Leírás

A változtatási kérelem azonosítója a változáskezelési folyamat elemzésének alapja. Minden kérelemhez egyedi szám tartozik, például „CHG0030001”, amely összekapcsolja a tevékenységeket, jóváhagyásokat és feladatokat.

A process mining ezt az attribútumot használja az egyes változtatások teljes folyamatának rekonstruálásához. Az elemzők így a létrehozástól a lezárásig követhetik a teljes életciklust, és láthatják, hogyan halad végig az egyes változtatás a rendszeren. Az azonosító szerinti csoportosítás szükséges a ciklusidők kiszámításához, az átdolgozási körök feltárásához és a folyamatváltozatok megértéséhez.

Miért fontos?

Ez az azonosító teszi lehetővé a változtatás teljes életciklusának követését, valamint az egyes kérelmek folyamatának, időtartamának és megfelelésének elemzését.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: number

Példák
CHG0030001CHG0030045CHG0030112
Tevékenység neve
ActivityName
A változáskezelési folyamatban végrehajtott esemény vagy feladat neve.
Leírás

A tevékenység neve a változtatási kérelem életciklusának egy-egy lépését vagy állapotváltozását jelöli. Ilyen például a „Változtatás elbírálásra vár”, a „Jóváhagyás kérése” és a „Változtatás megvalósítva”. Ezek a tevékenységek alkotják a feltárt folyamattérkép csomópontjait.

A tevékenységek elemzésével részletesen vizsgálható a folyamat menete. A sorrend és az előfordulási gyakoriság követésével feltárhatók a gyakori útvonalak, a standard folyamattól való eltérések és azok a szűk keresztmetszetek, ahol rendszeresen elakadnak a változtatások. Ez alapozza meg a folyamat megjelenítését és a lépések közötti átmeneti idők kiszámítását.

Miért fontos?

A folyamattérkép alapját adja: megjeleníthető vele a folyamat menete, feltárhatók a szűk keresztmetszetek és elemezhetők az eltérések.

Hol szerezhető be?

A change_request tábla „state” vagy más fontos állapotmezőinek változásaiból származik, amelyeket gyakran a „sys_audit” tábla rögzít.

Példák
Változtatás jóváhagyvaMegvalósítás megkezdveVáltoztatás lezárvaVáltoztatás megszakítva
Befejezési idő
EndTime
Az az időpont, amikor egy tevékenység véget ért. Gyakran a következő tevékenység kezdési időpontjából határozható meg.
Leírás

A befejezési idő jelzi, mikor ért véget egy tevékenység. A forrásrendszerek gyakran csak az esemény kezdetét rögzítik, ezért a befejezési időt sokszor következtetéssel határozzák meg. Általában az adott eset következő tevékenységének időbélyegével egyezik meg.

Ez az attribútum szükséges az egyes tevékenységek feldolgozási idejének kiszámításához. Az egyes lépések időtartamának ismerete segít feltárni a folyamat szűk keresztmetszeteit és hatékonytalanságait. Egy eset utolsó tevékenységénél a befejezési idő megegyezik a kezdési idővel.

Miért fontos?

Lehetővé teszi a tevékenységek feldolgozási idejének kiszámítását, ami szükséges a szűk keresztmetszetek feltárásához és az egyes folyamatlépések időtartamának méréséhez.

Hol szerezhető be?

Ezt az attribútumot jellemzően az adatátalakítás során számítják ki: az adott CaseId következő eseményének StartTime értékét veszik alapul.

Példák
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Hozzárendelési csoport
AssignmentGroup
A változtatási kérelemért felelős csapat vagy csoport.
Leírás

A hozzárendelési csoport jelzi, melyik csapat felelős éppen a változtatási kérelemért, például a „CAB Approval”, a „Network Engineering” vagy a „Database Administrators”. Ez fontos szempont a folyamat teljesítményének különböző szakterületek szerinti elemzéséhez.

Az attribútummal mérhető a csapatok hatékonysága, feltárhatók az egyes csoportokon belüli szűk keresztmetszetek, és elemezhető a csapatok közötti feladatátadások eredményessége. A „Cross-Functional Handoff Efficiency” és a „Change Implementation Throughput” dashboardok nagymértékben támaszkodnak ezekre az adatokra, hogy feltárják a csapatok közötti függőségek okozta késéseket.

Miért fontos?

Lehetővé teszi a csapatok teljesítményének elemzését, megmutatja a csoportszintű szűk keresztmetszeteket, és méri a különböző szakterületek közötti feladatátadások hatékonyságát.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: assignment_group

Példák
CAB ApprovalNetwork TeamServer SupportDatabase Administrators
Kockázati szint
RiskLevel
A változtatás felmért kockázati szintje, például „High”, „Moderate” vagy „Low”.
Leírás

A kockázati szint a változtatási kérelem kockázatfelmérésének eredménye. Azt fejezi ki, mekkora a kedvezőtlen következmények esélye a változtatás megvalósítása esetén, és segít meghatározni a szükséges ellenőrzés és jóváhagyás szintjét.

A „Risk Assessment Standardization” dashboard ezt az attribútumot használja annak ellenőrzésére, hogy az azonos jellegű változtatások következetes kockázati besorolást kapnak-e. A folyamatok kockázati szint szerinti elemzésével az is megállapítható, hogy a magas kockázatú változtatások a kisebb kockázatúaknál szigorúbb jóváhagyási és tesztelési folyamaton mennek-e végig. Ez a megfelelés ellenőrzésének fontos része.

Miért fontos?

A megfelelés elemzéséhez szükséges, és segít ellenőrizni, hogy a magas kockázatú változtatásokat megfelelő alapossággal, szigorúbb folyamat szerint kezelik-e.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: risk

Példák
MagasKözepesAlacsony
Konfigurációs elem
ConfigurationItem
Az a konkrét IT-összetevő, szolgáltatás vagy rendszer, amelyet a változtatás érint.
Leírás

A konfigurációs elem (CI) a Configuration Management Database (CMDB) azon eszköze, amelyet a változtatás érint. Lehet például szerver, szoftveralkalmazás, hálózati eszköz vagy üzleti szolgáltatás.

Ez az attribútum fontos hátteret ad a változtatás elemzéséhez. A process mining segítségével az elemzés az érintett eszköz típusa szerint bontható le. A „Change Testing Duration Analysis” dashboard például ezzel hasonlítja össze a különböző alkalmazások és rendszerek tesztelési idejét, így feltárhatók azok a CI-k, amelyekhez hosszabb tesztelési ciklusok tartoznak.

Miért fontos?

Megadja az elemzéshez szükséges üzleti hátteret. Az érintett alkalmazás, szolgáltatás vagy rendszer szerint szűrhető vele az elemzés, így feltárhatók az adott összetevőhöz kapcsolódó problémák.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: cmdb_ci

Példák
SAP ERPOracle Database 19cE-mail-szolgáltatásWebServer-01
Prioritás
Priority
A változtatási kérelem prioritási szintje, amelyet a hatása és sürgőssége határoz meg.
Leírás

A prioritás jelzi a változtatási kérelem fontosságát, és meghatározza, milyen sorrendben kell foglalkozni vele. Gyakran a változtatás hatása és sürgőssége alapján állapítják meg. Értékei például „Critical”, „High”, „Moderate” és „Low”.

A prioritás szerinti elemzés segít biztosítani, hogy a magas prioritású változtatások gyorsabban haladjanak, mint az alacsony prioritásúak. A „Critical Change Performance” dashboardon az elemzők külön követhetik a legfontosabb változtatások ciklusidejét és hibaarányát. Ha az alacsony prioritású változtatások gyorsabban készülnek el, mint a magas prioritásúak, az az erőforrások elosztásának vagy a folyamat végrehajtásának problémájára utalhat.

Miért fontos?

Segít megítélni, hogy az erőforrásokat a legkritikusabb változtatásokra fordítják-e, és lehetővé teszi ezek teljesítményének külön követését.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: priority

Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
Változtatás állapota
ChangeState
A változtatási kérelem aktuális vagy korábbi állapota, például „Assess”, „Authorize”, „Implement” vagy „Closed”.
Leírás

A változtatás állapota attribútum a változtatási kérelem adott időpontban érvényes állapotát jelöli. Röviden összefoglalja, hol tart a változtatás az életciklusában. A konkrét eseményt jelölő tevékenységtől eltérően az állapot az esemény eredményeként kialakult helyzetet mutatja.

Az elemzés során a változtatás állapota alapján csoportosíthatók az esetek, és vizsgálhatók az eredmények. Segítségével szűrhetők például a „Closed” állapotú változtatások, vagy megvizsgálható, miért akad el sok változtatás az „Authorize” állapotban. Ha létezik „Failed” állapot, közvetlenül támogatja a Change Failure Rate KPI mérését.

Miért fontos?

Pillanatképet ad a változtatási kérelem állapotáról, így elemezhetők az eredmények, szűrhetők az esetek és feltárhatók az elakadt változtatások.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: state

Példák
AssessAuthorizeScheduledImplementReviewClosedCanceled
Változtatás típusa
ChangeType
A változtatás besorolása, például „Standard”, „Normal” vagy „Emergency”.
Leírás

A változtatás típusa a változtatási kérelmet annak jellege, kockázata és jóváhagyási követelményei alapján sorolja kategóriába. A standard változtatások előzetesen jóváhagyottak, a normál változtatások a teljes folyamaton mennek végig, a sürgősségi változtatások pedig gyorsított eljárást követnek.

Ez az elemzés egyik alapvető szempontja, mert a különböző változtatástípusokhoz eltérő, jóváhagyott folyamatok tartoznak. A normál és sürgősségi változtatások teljesítményének összehasonlítása fontos információkat adhat a folyamat betartásáról és hatékonyságáról. A „Risk Assessment Standardization” dashboard is használja ezt az attribútumot annak ellenőrzésére, hogy az azonos jellegű változtatásokat következetesen kezelik-e.

Miért fontos?

Lehetővé teszi az elemzés változtatástípus szerinti bontását, mivel az egyes típusok eltérő, jóváhagyott folyamatokat követnek, és más teljesítményelvárások vonatkoznak rájuk.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: type

Példák
StandardNormalEmergency
Átfutási idő
CycleTime
A változtatási kérelem létrehozásától a lezárásáig eltelt teljes idő.
Leírás

Az átfutási idő ügyszintű mutató, amely a változtatási kérelem teljes életciklusának hosszát méri. Kiszámításához az adott változtatási kérelem első eseményének időbélyegét kivonják az utolsó esemény időbélyegéből.

Ez a teljes folyamat sebességének mérésére szolgáló fontos KPI. Az „Átfogó változtatásifolyamat-áttekintés” dashboard magas szintű képet ad vele a folyamat teljesítményéről. Az átfutási idő alakulásának elemzése és összehasonlítása olyan szempontok szerint, mint a változtatás típusa vagy prioritása, segít feltárni a folyamatfejlesztés lehetőségeit.

Miért fontos?

A változtatási folyamat teljes átfutási idejét méri, így jelzi a folyamat sebességét és hatékonyságát.

Hol szerezhető be?

Az adatelemzés során, ügyszinten számítják ki: minden CaseId esetén a legnagyobb StartTime értékből kivonják a legkisebb StartTime értéket.

Példák
60480012096002592000
Forrásrendszer
SourceSystem
Az a rendszer, amelyből az adatokat kinyerték, jellemzően a „ServiceNow”.
Leírás

Ez az attribútum azonosítja a folyamatadatok forrását. Ebben az esetben várhatóan a ServiceNow, de az adatirányítás szempontjából, illetve több rendszer adatainak egyesítésekor is fontos mező.

Az elemzés során egyértelművé teszi az adatok eredetét, és segít ellenőrizni a forrást. Több ITSM-eszközt vagy integrált rendszert használó szervezeteknél lehetővé teszi a különböző platformok folyamatainak szűrését és összehasonlítását.

Miért fontos?

Egyértelműen dokumentálja a folyamatadatok eredetét, ami fontos az adatirányításhoz és a több rendszert érintő elemzéshez.

Hol szerezhető be?

Ez jellemzően az adatkinyerés és -átalakítás (ETL) során megadott, állandó érték.

Példák
ServiceNowServiceNow_PRODSNOW_ITSM
Hatás
Impact
A változtatás lehetséges hatása az üzleti működésre, például magas, közepes vagy alacsony besorolással.
Leírás

A hatás azt méri, milyen következményekkel járhat az üzletmenetre, ha a változtatási kérelmet nem megfelelően kezelik. A sürgősséggel együtt ez határozza meg a változtatás prioritását.

A hatás szerinti elemzés segít biztosítani, hogy a kritikus szolgáltatásokat érintő változtatásokat kellő körültekintéssel kezeljék. A „Critical Change Performance” dashboardon elkülöníthetők és nyomon követhetők a nagy üzleti hatású változtatások. Az attribútum a kockázatfelmérés következetességének ellenőrzésére is használható, például annak feltárására, hogy indoklás nélkül kapnak-e alacsony kockázati besorolást a nagy hatású változtatások.

Miért fontos?

Segít a változtatások lehetséges üzleti hatás szerinti rangsorolásában, és ellenőrizhető vele, hogy a nagy hatású változtatásokat kellő körültekintéssel kezelik-e.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: impact

Példák
1 - Magas2 - Közepes3 - Alacsony
Hozzárendelt felhasználó
AssignedToUser
Az a felhasználó, aki egy adott időpontban felelős a változtatási kérelemért.
Leírás

Ez az attribútum azonosítja, hogy ki dolgozik a változtatási kérelmen. A felelős a kérelem életciklusa során többször is változhat, ahogy a munka más szakaszokhoz és csapatokhoz kerül.

A felhasználó szerinti elemzés segít megérteni a munkaterhelés eloszlását, az egyéni teljesítményt és a képzési igényeket. A feladatátadások elemzéséhez is fontos, különösen a hozzárendelési csoporttal együtt vizsgálva: így látható, milyen hatékonyan kerül át a munka az egyes felhasználók között.

Miért fontos?

Segít követni az egyes felhasználók munkaterhelését és teljesítményét, valamint feltárni a különböző erőforrások közötti átadások késéseit.

Hol szerezhető be?

ServiceNow tábla: change_request, mező: assigned_to

Példák
Beth AnglinDavid LooAbel Tuter
Lezárási kód
CloseCode
A lezárt változtatási kérelem eredményét jelző kód, például „Sikeres” vagy „Sikertelen”.
Leírás

A Lezárási kód rögzíti a lezárt változtatási kérelem végső eredményét. Megmutatja, hogy a változtatást sikeresen végrehajtották, problémák merültek fel, vagy visszaállították a korábbi állapotot.

Ez az attribútum közvetlen bemeneti adat a „Változtatási hibaarány” KPI-hoz. A lezárási kódok megoszlásából számszerűsíthető a változtatások sikeressége. Ha a folyamattérképen a „Sikertelen” lezárási kódú változtatásokra szűr, feltárhatja a hibához vezető gyakori folyamatmintákat, és elemezheti azok kiváltó okait.

Miért fontos?

Közvetlenül méri a változtatás eredményét. Ez az elsődleges adatforrás a változtatási hibaarány kiszámításához és a sikertelen változtatások okainak elemzéséhez.

Hol szerezhető be?

ServiceNow-tábla: change_request, mező: close_code

Példák
SikeresSikeres, problémákkalSikertelen / visszaállítva
SLA-állapot
SlaState
Azt mutatja, hogy a változtatási kérelem hogyan áll a szolgáltatási szintre vonatkozó megállapodáshoz (SLA) képest. Értéke például „Határidőn belül”, „Veszélyben” vagy „Határidő túllépve” lehet.
Leírás

Az SLA-állapot jelzi, hogy a változtatási kérelem az SLA-ban meghatározott határidők szerint halad-e. Az állapot a folyamat minden szakaszában nyomon követhető.

Ez az attribútum elengedhetetlen a szolgáltatási szintre vonatkozó vállalások teljesítésének ellenőrzéséhez. Ez az elsődleges adatforrás a „Változtatási SLA-teljesítmény áttekintése” dashboardhoz és a „Változtatási SLA-k betartási aránya” KPI-hoz. A határidő-túllépések helyének és okának elemzésével a szervezet kezelheti a rendszerszintű késéseket, és kiszámíthatóbbá teheti a szolgáltatást.

Miért fontos?

Közvetlenül méri a határidők teljesítését. Lehetővé teszi az SLA-túllépések proaktív nyomon követését és elemzését, így javítható a szolgáltatásnyújtás.

Hol szerezhető be?

Az adat a ServiceNow task_sla táblájából származhat, amely a feladatokhoz, például a változtatási kérelmekhez kapcsolódó SLA-kat követi nyomon. A határidőmezők alapján számítással is előállítható.

Példák
Határidőn belülVeszélybenHatáridő túllépve
Sürgősség
Urgency
Azt mutatja, milyen gyorsan kell megoldani a változtatási kérelmet. Az értéke például Magas, Közepes vagy Alacsony lehet.
Leírás

A sürgősség azt jelzi, milyen gyorsan kell végrehajtani a változtatást. A kérelem üzleti szempontú időérzékenységét fejezi ki. A Hatással együtt ebből számítják ki a teljes prioritást.

Az elemzés elsődleges mezője a Prioritás, a Sürgősség azonban további összefüggéseket mutat. Segítségével megvizsgálható, miért jelölnek sürgősnek bizonyos változtatásokat, és hogy a folyamat képes-e ezeket a stabilitás veszélyeztetése nélkül kezelni. Arra is választ ad, hogy a szervezet túl gyakran kényszerül-e sürgős, reaktív működésre.

Miért fontos?

Megmutatja, mennyire időérzékeny egy változtatás, így elemezhető, hogy a folyamat megfelelően kezeli-e a sürgős kérelmeket.

Hol szerezhető be?

ServiceNow-tábla: change_request, mező: urgency

Példák
1 - Magas2 - Közepes3 - Alacsony
Újramunka-e
IsRework
Logikai jelző, amely akkor igaz, ha egy tevékenység ugyanabban az ügyben egy korábbi lépés ismétlése.
Leírás

Ez a számított attribútum azonosítja az újramunkát jelentő tevékenységeket. Újramunkáról akkor beszélünk, ha a folyamatnak vissza kell térnie egy már elvégzett lépéshez, például ha jóváhagyás után elutasítanak egy változtatást, és újraértékelésre visszaküldik.

Ez a jelző segít számszerűsíteni a folyamat hatékonyságvesztését. Közvetlenül támogatja a „Változtatási újramunka aránya” KPI-t és a „Változtatási hibák és újramunka elemzése” dashboardot. Ha az „Újramunka-e” értéke igaz, az elemzők elkülöníthetik és megvizsgálhatják az újramunka okait, például a hiányos kezdeti értékelést vagy a változó követelményeket, majd intézkedhetnek a veszteségek csökkentéséről.

Miért fontos?

Az ismétlődő munka jelölésével közvetlenül számszerűsíti a folyamat hatékonyságvesztését, és segít feltárni a folyamatkörök, valamint a felesleges ráfordítások kiváltó okait.

Hol szerezhető be?

Az adatátalakítás során számítják ki annak ellenőrzésével, hogy az adott CaseId esetén előfordult-e már ugyanaz a tevékenység vagy a standard folyamat egy korábbi lépése.

Példák
truefalse
Utolsó adatfrissítés
LastDataUpdate
Az időbélyeg azt jelzi, mikor frissítették utoljára a rekord adatait a forrásrendszerből.
Leírás

Ez az attribútum az utolsó adatkinyerés időpontját adja meg. Olyan metaadatmező, amely segít megállapítani, mennyire frissek az elemzett adatok.

Az elemzők ezzel ellenőrizhetik, hogy naprakész adatokkal dolgoznak-e, és mikoriak az információk. Ez különösen fontos a folyamatok aktuális teljesítményét figyelő működési dashboardoknál, hogy a döntések ne elavult adatokon alapuljanak.

Miért fontos?

Jelzi az adatok frissességét, így az elemzések és a dashboardok aktuális, releváns információkra támaszkodhatnak.

Hol szerezhető be?

Ez az adatkinyerés és -átalakítás (ETL) során létrehozott metaadatmező, amely az adatlekérés időpontját jelzi.

Példák
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Kötelező Javasolt Nem kötelező

Változáskezelési tevékenységek

Ezeket a fő folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban a változáskezelési folyamat pontos feltérképezéséhez.
7 Javasolt 6 Nem kötelező
Tevékenység Leírás
Kockázat- és hatáselemzés kész
A változtatási kérelem kockázat- és hatáselemzésének befejezését jelzi. Ez fontos mérföldkő a jóváhagyás kérése előtt. Gyakran abból állapítható meg, hogy az állapot „Assess” értékről „Authorize” vagy „Awaiting Approval” értékre vált.
Miért fontos?

Az elbírálási szakasz időtartamának követése szükséges az „Avg. Risk Assessment Cycle Time” KPI méréséhez. Segít egységesíteni az elbírálást, és feltárni, hol húzódik el az elemzés.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Assess” értékről „Authorize” értékre váltásából állapítható meg. Az esemény időbélyegét az állapotváltozás auditnaplója rögzíti.

Rögzítés

Keresse meg, mikor vált a „state” mező „Assess” értékről egy következő állapotra, például „Authorize” értékre.

Eseménytípus inferred
Változtatás jóváhagyva
A változtatási kérelem megkapta az ütemezéshez és a megvalósításhoz szükséges összes jóváhagyást. Ez fontos mérföldkő: akkor rögzül, amikor megadják a végső jóváhagyást, és az „approval” mező értéke „approved” lesz.
Miért fontos?

Ez a mérföldkő zárja le a jóváhagyási szakaszt. A jóváhagyási ciklusidő méréséhez és a döntéshozatal szűk keresztmetszeteinek feltárásához is szükséges.

Hol szerezhető be?

A change_request tábla „approval” mezőjének „approved” értékre váltásából állapítható meg. Az időbélyeg az ehhez tartozó auditelőzményből származik.

Rögzítés

Rögzítse az időbélyeget, amikor az „approval” mező értéke „approved” lesz.

Eseménytípus inferred
Változtatás lezárva
A változtatási kérelmet sikeresen végrehajtották és felülvizsgálták, így lezártnak tekinthető. Ez a folyamat elsődleges sikeres végállapota, amely akkor rögzül, amikor a változtatás állapota „Closed” értékre vált.
Miért fontos?

Ez a tevékenység jelzi a változtatás életciklusának sikeres lezárását. Ez a végpont az elejétől a végéig tartó folyamat időtartamának és az SLA-k teljesülésének méréséhez.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Closed” értéke alapján állapítható meg. Az időbélyeg a végső állapotváltozás auditelőzményéből származik.

Rögzítés

Rögzítse az időbélyeget, amikor a „state” mező értéke „Closed” lesz.

Eseménytípus inferred
Változtatás megszakítva
A változtatási kérelmet a megvalósítás befejezése előtt visszavonták vagy megszakították. Ez alternatív végállapot, amely akkor rögzül, amikor az állapot értéke „Canceled” lesz.
Miért fontos?

A megszakított változtatások elemzése feltárhatja a folyamat hiányosságait. Ilyen például a szükségtelenül létrehozott kérelem, illetve a jóváhagyásra túl sokáig váró, időközben elavult változtatás.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Canceled” értéke alapján állapítható meg. Az időbélyeget az állapotváltozás auditnaplója rögzíti.

Rögzítés

Rögzítse az időbélyeget, amikor a „state” mező értéke „Canceled” lesz.

Eseménytípus inferred
Változtatás megvalósítva
A megvalósítási munka befejeződött, a változtatás készen áll az ellenőrzésre, felülvizsgálatra vagy tesztelésre. Ez abból állapítható meg, hogy a változtatási kérelem állapota „Implement” értékről „Review” értékre vált.
Miért fontos?

Ez a fontos mérföldkő zárja le a megvalósítási szakaszt. A „Change Failure Rate” és a „Change Rework Rate” KPI kiszámításához is szükséges.

Hol szerezhető be?

Az „Implement” állapotból egy következő állapotba, például „Review” értékre történő váltásból állapítható meg. Az időbélyeget a change_request tábla „state” mezőjének auditelőzménye rögzíti.

Rögzítés

Keresse meg, mikor vált a „state” mező „Implement” értékről „Review” értékre.

Eseménytípus inferred
Változtatás ütemezve
A jóváhagyott változtatáshoz megadták a tervezett kezdési és befejezési dátumot, így felkerült a megvalósítási naptárba. Ez abból állapítható meg, hogy a változtatási kérelem állapota „Scheduled” értékre vált.
Miért fontos?

Ez a tevékenység elválasztja a tervezési és jóváhagyási szakaszt a tényleges megvalósítástól. Az állapotban töltött idő megmutathatja, mennyi késés telik el a jóváhagyás és a munka megkezdése között.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Scheduled” értékre váltásából állapítható meg. Az időbélyeget a megfelelő auditnapló-bejegyzés rögzíti.

Rögzítés

Kövesse nyomon a change_request tábla auditelőzményeiben a „state” mező „Scheduled” értékre váltását.

Eseménytípus inferred
Változtatási kérelem létrehozva
Ez az esemény jelzi, hogy új változtatási kérelem rekord jött létre a rendszerben. Ezzel hivatalosan is elindul a változáskezelési folyamat. Az eseményt a change_request táblába beszúrt új rekord rögzíti.
Miért fontos?

Ez a folyamat elsődleges kezdőeseménye. Az esemény és a későbbi tevékenységek közötti idő elemzésével meghatározható a teljes átfutási idő, és feltárhatók a folyamat elején jelentkező késések.

Hol szerezhető be?

Ez az esemény a ServiceNow change_request táblájában szereplő rekord létrehozási időbélyegének (sys_created_on) felel meg.

Rögzítés

Használja a change_request tábla sys_created_on időbélyegét.

Eseménytípus explicit
Felülvizsgálat folyamatban
Folyamatban van a megvalósítás utáni felülvizsgálat (PIR), amely azt vizsgálja, hogy a változtatás sikeres volt-e, és elérte-e a célját. Az esemény akkor rögzül, amikor a változtatási kérelem állapota „Review” értékre vált.
Miért fontos?

A felülvizsgálati szakasz időtartamának elemzése feltárja a változtatás eredményességének ellenőrzésében jelentkező késéseket. Azokat a megfelelésnek nem megfelelő változtatásokat is megmutatja, amelyeknél kimarad ez a lépés.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Review” értékre váltásából állapítható meg. Az időbélyeg az állapotváltozás auditnaplójából származik.

Rögzítés

Rögzítse a „state” mező „Review” értékre váltásának időbélyegét a change_request auditelőzményeiből.

Eseménytípus inferred
Jóváhagyás kérése
Ez a tevékenység azt jelzi, hogy a változtatási kérelmet hivatalosan jóváhagyásra küldték, jellemzően egy vezetőnek vagy a Change Advisory Boardnak (CAB). Az esemény akkor rögzül, amikor a kérelem jóváhagyási állapota „requested” értékre vált.
Miért fontos?

Ezzel kezdődik a jóváhagyási ciklus. Az esemény és a „Change Approved” közötti idő közvetlenül megadja az „Average Change Approval Time” KPI értékét.

Hol szerezhető be?

A change_request tábla „approval” mezőjének „requested” értékre váltásából állapítható meg. Az időbélyeget a mezőváltozást rögzítő sys_audit tábla tartalmazza.

Rögzítés

Annak az időpontja, amikor a change_request tábla „approval” mezője „requested” értéket kap.

Eseménytípus inferred
Megvalósítás megkezdve
Megkezdődött a változtatás tényleges megvalósítása. Az esemény akkor rögzül, amikor a változtatási kérelem állapota „Implement” értékre vált, jelezve az átmenetet a tervezésből a végrehajtásba.
Miért fontos?

Ez jelzi a tényleges megvalósítási munka kezdetét. Innen mérhető az „Average Implementation Duration” KPI, és elemezhető a csapat hatékonysága.

Hol szerezhető be?

A change_request tábla „state” mezőjének „Implement” értékre váltásából állapítható meg. Az időbélyeg az állapotváltozás auditnaplójából származik.

Rögzítés

Rögzítse a „state” mező „Implement” értékre váltásának időbélyegét a change_request auditelőzményeiből.

Eseménytípus inferred
Változtatás elbírálásra vár
A változtatási kérelmet benyújtották, és most a műszaki, illetve üzleti elbírálásra vár. Ez jellemzően abból állapítható meg, hogy a kérelem állapota „Assess” vagy hasonló értékre vált, vagyis kilép a piszkozatfázisból.
Miért fontos?

Ez a tevékenység segít mérni, mennyi idő telik el a kérelem benyújtásától az elbíráló csapathoz való továbbításig. Az itt tapasztalható késés az adatok hiányosságára vagy az elbíráláshoz szükséges erőforrások elérhetetlenségére utalhat.

Hol szerezhető be?

A change_request tábla „state” mezőjének változásából állapítható meg, jellemzően az „Assess” értékre váltásból. Az időbélyeg a mezőváltozást rögzítő auditelőzményből (sys_audit) származik.

Rögzítés

Kövesse nyomon a change_request tábla auditelőzményeiben a „state” mező „Assess” értékre váltását.

Eseménytípus inferred
Változtatás elutasítva
A jóváhagyó vagy a CAB elutasította a változtatási kérelmet. Ez a kérelem végállapota, kivéve, ha átdolgozzák és újra benyújtják. Az esemény akkor rögzül, amikor az „approval” mező értéke „rejected” lesz.
Miért fontos?

Az elutasítások követése segít feltárni a gyakori okokat, például a hiányos adatokat vagy a magas kockázatot. Az elemzés javíthatja a későbbi változtatási kérelmek minőségét.

Hol szerezhető be?

A change_request tábla „approval” mezőjének „rejected” értékre váltásából állapítható meg. Az időbélyeget az auditelőzmény rögzíti.

Rögzítés

Rögzítse az időbélyeget, amikor az „approval” mező értéke „rejected” lesz.

Eseménytípus inferred
Változtatási kérelem újranyitva
A változtatási kérelem egy későbbi szakasz elérése után visszakerült egy korábbi állapotba, például „Implement” vagy „Assess” értékre. Ez a nem lineáris állapotváltás átdolgozásra utal.
Miért fontos?

Ez a tevékenység segít feltárni az átdolgozási köröket és kiszámítani a „Change Rework Rate” KPI értékét. A gyakori újranyitás a megvalósítás, a tesztelés vagy a tervezés minőségi problémáira utalhat.

Hol szerezhető be?

A change_request auditelőzményeiben szereplő állapotváltozások sorrendjének elemzésével állapítható meg. Ha egy későbbi állapotból, például „Review” értékről korábbi állapotba, például „Implement” értékre vált a kérelem, az újranyitást jelez.

Rögzítés

Keresse meg a „state” mező előzményeiben a nem egymást követő, visszafelé történő állapotváltásokat.

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

Adatkinyerési útmutatók

Adatok kinyerése a ServiceNow-ból

Készen áll a kezdésre?

Használja ezt a sablont az adatok előkészítéséhez, és tárja fel a ServiceNow változáskezelési folyamatának működését. Kezdje el még ma a hatékonyság növelését.

Elég a sikertelen változtatásokból, javítsa ServiceNow-folyamatának eredményességét!

Találja meg a szűk keresztmetszeteket, és érje el könnyebben a 95%-os változtatási sikerarányt.

Próbálja ki ingyen

Nincs szükség bankkártyára, a beállítás percek alatt elvégezhető.