Módosításkezelési adatsablon

Ivanti Cherwell
Módosításkezelési adatsablon

Módosításkezelési adatsablon

Ez a sablon útmutatást ad a módosításkezelési folyamat elemzéséhez szükséges adatok összegyűjtéséhez. Bemutatja a rögzítendő attribútumokat és követendő tevékenységeket, valamint azt is, hogyan nyerheti ki ezeket az adatokat a forrásrendszerből. Használja az útmutatót a process mining elemzésekhez szükséges eseménynapló összeállításához.
  • Javasolt attribútumok
  • Követendő fő tevékenységek
  • Adatok kinyerése az Ivanti Cherwellből
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A módosításkezelés attribútumai

Ezeket az adatmezőket javasoljuk felvenni az eseménynaplóba a módosításkezelés részletes elemzéséhez és a folyamat feltárásához.
5 Kötelező 6 Javasolt 8 Nem kötelező
Név Leírás
Esemény időpontja
EventTime
Az időbélyeg azt mutatja, mikor történt egy adott tevékenység vagy esemény a változtatási kérelem során.
Leírás

Az esemény időpontja, más néven időbélyeg, rögzíti a tevékenység pontos dátumát és időpontját. Ez az időadat szükséges az események időrendi sorba rendezéséhez, és minden időalapú process mining elemzés alapját képezi.

Az attribútum segítségével kiszámítható a tevékenységek közötti idő, mérhető az esetek teljes átfutási ideje, és azonosíthatók a várakozások, illetve a késések. Az időalapú célértékek, például a változtatás jóváhagyási idejének nyomon követésére szolgáló dashboardok létrehozásához is szükséges.

Miért fontos?

Ez az időbélyeg alapozza meg a teljesítmény és az időtartam elemzését. Segítségével kiszámítható az átfutási idő, azonosíthatók a szűk keresztmetszetek, és nyomon követhetők az SLA-k.

Hol szerezhető be?

Általában az Ivanti Cherwell Change Request objektumához tartozó állapotváltási naplókban, auditnaplókban vagy naplóbejegyzések időbélyegeiben található.

Példák
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Tevékenység neve
ActivityName
A változáskezelési folyamat egy adott időpontjában bekövetkezett esemény vagy elvégzett feladat neve.
Leírás

A tevékenység neve a változtatási kérelem életciklusának egy konkrét lépését vagy mérföldkövét jelöli, például „Change Submitted For Assessment” vagy „Change Approved by CAB”. Ezek a tevékenységek alkotják a feltárt folyamattérkép csomópontjait.

Az elemzésben ez az attribútum alapvető a folyamatmenet megjelenítéséhez, az események sorrendjének feltárásához és a standard eljárástól való eltérések felismeréséhez. Segítségével kiszámítható a tevékenységek közötti átmeneti idő, és megállapítható, hol keletkeznek késések.

Miért fontos?

Ez az attribútum elengedhetetlen a tényleges folyamatmenet feltárásához és megjelenítéséhez. Segítségével azonosíthatók a szűk keresztmetszetek, az ismételt munkavégzést jelentő körök és a megfelelőségi előírásokat sértő útvonalak.

Hol szerezhető be?

Az Ivanti Cherwell Change Request objektumához kapcsolódó állapotváltásokból, naplóbejegyzésekből vagy eseménynaplókból állítható elő.

Példák
Változtatási kérelem benyújtva értékelésreVáltoztatás jóváhagyásra várA változtatás megvalósult
Változtatási kérelem azonosítója
ChangeRequestId
Egy változtatási kérelem egyedi azonosítója. Összekapcsolja a kérelemhez tartozó összes tevékenységet a kezdeményezéstől a lezárásig.
Leírás

A Change Request ID az elsődleges kulcs, amely a változtatási kezdeményezést annak teljes életciklusa során egyedileg azonosítja. A process mining során ez szolgál az eset azonosítójaként, és egyetlen folyamatpéldányba kapcsolja össze az összes eseményt, például a benyújtást, az értékelést, a jóváhagyást és a megvalósítást.

A Change Request ID alapján végzett elemzés teljes, elejétől a végéig tartó képet ad a változáskezelési folyamatról. Lehetővé teszi az egyes változtatások nyomon követését, a teljes átfutási idő kiszámítását, valamint az adott kérelemhez kapcsolódó folyamateltérések és szűk keresztmetszetek azonosítását.

Miért fontos?

Ez az alapvető esetazonosító kapcsolja össze az összes kapcsolódó eseményt. Így végigkövethető a változtatási kérelem teljes útja, és elemezhető a teljesítménye.

Hol szerezhető be?

Ez általában az Ivanti Cherwell Change Request üzleti objektumának elsődleges azonosítója.

Példák
CR-105421CR-105422CR-105423
Forrásrendszer
SourceSystem
Az a nyilvántartó rendszer, amelyből az adatokat kinyerték. Ebben a nézetben ez az „Ivanti Cherwell”.
Leírás

Ez az attribútum azonosítja az eseményadatok forrásrendszerét. Többféle rendszert használó környezetben segít megkülönböztetni az egyes forrásokból származó adatokat. Ebben az adatmodellben állandó értéke jelzi, hogy az adatok az Ivanti Cherwellből származnak.

Egyetlen forrásrendszer esetén az érték állandónak tűnhet, de az adatirányítás, a nyomon követhetőség és a későbbi rendszerintegrációk szempontjából fontos. Egyértelművé teszi az adatok eredetét, és segít az adatminőség kezelésében.

Miért fontos?

Fontos információt ad az adatok eredetéről, ami szükséges az adatirányításhoz, a hibakereséshez és a nyomon követhetőség biztosításához.

Hol szerezhető be?

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

Példák
Ivanti Cherwell
Utolsó adatfrissítés
LastDataUpdate
Az időbélyeg azt mutatja, mikor nyerték ki vagy frissítették utoljára az esemény adatait a forrásrendszerből.
Leírás

Ez az attribútum rögzíti, mikor kérdezték le utoljára az adatokat az Ivanti Cherwellből. Nem a folyamat egyik eseményét jelöli, hanem az adatok frissességére vonatkozó metaadat.

A dashboardot használók ebből tudhatják meg, mennyire aktuális az elemzés. Az attribútum segít az adatfrissítések ütemezésében, és biztosítja, hogy a döntések ismert korú adatokon alapuljanak.

Miért fontos?

Az adatok frissességét jelzi. Ez segít a felhasználóknak megbízni az elemzésben, és megítélni, mennyire tükrözi az a működés aktuális állapotát.

Hol szerezhető be?

Ez az időbélyeg az ETL-folyamat során jön létre, és minden rekordhoz hozzáadódik.

Példák
2024-05-21T02:00:00Z
Tervezett befejezési dátum
TargetCompletionDate
A változtatás megvalósításának befejezésére tervezett vagy egyeztetett határidő.
Leírás

A tervezett befejezési dátum az az időpont, ameddig a változtatás megvalósításának és ellenőrzésének várhatóan be kell fejeződnie. Ez a dátum gyakran szerepel egy szolgáltatási szintre vonatkozó megállapodásban (SLA), és a teljesítmény egyik fő viszonyítási alapja.

Az attribútum szükséges a határidők betartásának nyomon követéséhez. A tényleges befejezési dátummal összevetve kiszámítható az időben befejezett változtatások aránya és a változtatások SLA-megfelelési aránya. Segít időben felismerni azokat a változtatásokat, amelyeknél fennáll a határidő túllépésének kockázata.

Miért fontos?

Alapot ad a határidőre történő teljesítés és az SLA-k betartásának méréséhez. Ezek a folyamat hatékonyságának és megbízhatóságának fontos mutatói.

Hol szerezhető be?

Ez általában a Change Request objektum egyik dátummezője, amelynek neve például „Target Date”, „Due Date” vagy „SLA Target”.

Példák
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Változtatás állapota
ChangeStatus
A változtatási kérelem aktuális vagy végső állapota, például „Closed”, „Rejected” vagy „In Progress”.
Leírás

A változtatás állapota azt mutatja, hogy a kérelem egy adott időpontban milyen állapotban volt, vagy mi lett a végső eredménye. Ez az attribútum fontos az esetek lezárásának megértéséhez és a kivételek azonosításához.

A folyamatelemzésben az attribútum segítségével meghatározott eredményekre lehet szűrni, például csak az elutasított vagy visszavont változtatások vizsgálatára. Ez szolgáltat adatot olyan KPI-khoz, mint a változtatási kérelmek elutasítási aránya, és segít felmérni a változáskezelési folyamat általános állapotát és hatékonyságát.

Miért fontos?

Meghatározza a változtatási kérelem eredményét, így elemezhető az elutasítási és befejezési arány, valamint a nyitott és lezárt esetek megoszlása.

Hol szerezhető be?

Az Ivanti Cherwell Change Request üzleti objektumának „Status” mezőjének felel meg.

Példák
JóváhagyvaElutasítvaLezárvaVisszavonvaJóváhagyásra vár
Változtatás felelőse
ChangeOwner
A változtatási kérelemért jelenleg felelős felhasználó vagy személy.
Leírás

A változtatás felelőse az a személy, akit a folyamat adott szakaszában a kérelemhez rendeltek, és aki felel érte. A felelős a kérelem életciklusa során gyakran változik, ami a felelősség átadását jelzi.

A felelős elemzése segít megérteni az erőforrások terhelését, és feltárni az egyes személyekhez kapcsolódó szűk keresztmetszeteket. A felelősségátadások elemzéséhez is alapvető, mivel ezek jelentős késéseket okozhatnak. Az attribútum a „Változtatások átadása és az erőforrások kihasználtsága” dashboardot támogatja.

Miért fontos?

Nyomon követi az egyéni felelősséget, így elemezhető a munkaterhelés megoszlása, az átadások gyakorisága és az egyes erőforrásokhoz kapcsolódó szűk keresztmetszetek.

Hol szerezhető be?

Általában a Change Request üzleti objektum „Owned By” vagy „Assigned To” mezője.

Példák
Alice JohnsonBob WilliamsCharlie Brown
Változtatás kockázati szintje
ChangeRiskLevel
A változtatáshoz rendelt kockázati szint, például „Low”, „Medium” vagy „High”.
Leírás

A változtatás kockázati szintje az értékelési szakaszban megadott besorolás, amely a változtatás lehetséges kedvezőtlen hatását jelzi. Ez az értékelés gyakran befolyásolja a jóváhagyási folyamatot és a szükséges ellenőrzés szigorúságát.

A process mining során ez az attribútum a kockázatértékelések következetességének vizsgálatára és a kockázat, valamint a folyamat működése közötti összefüggések feltárására használható. Például ellenőrizhető, hogy a magas kockázatú változtatások szigorúbb jóváhagyási folyamaton mennek-e keresztül, vagy hosszabb ideig tart-e a megvalósításuk. Közvetlenül támogatja a „Változtatások kockázatértékelésének következetessége” dashboardot.

Miért fontos?

Segítségével elemezhető, hogyan hat a kockázat a folyamatmenetre, a jóváhagyási időre és a sikerességi arányra. Így ellenőrizhető, hogy a magas kockázatú változtatások megfelelő szintű vizsgálatot kapnak-e.

Hol szerezhető be?

Ez az érték a Change Request objektum „Risk Level” vagy hasonló mezőjében szerepel, és általában a kockázatértékelés során töltik ki.

Példák
AlacsonyKözepesMagasKritikus
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, sürgőssége és hatása alapján sorolja kategóriába. A gyakori típusok közé tartozik a Standard (előzetesen jóváhagyott, alacsony kockázatú), a Normal (teljes értékelést és jóváhagyást igénylő) és az Emergency (azonnali megvalósítást igénylő).

Ez az attribútum lehetővé teszi a folyamat teljesítményének összehasonlítását kategóriánként. Például kiderülhet, hogy a sürgősségi változtatások gyorsabb, eltérő útvonalon haladnak-e, vagy hogy a standard változtatások valóban fennakadás nélkül zajlanak-e. Az attribútum a „Problémás változtatástípusok teljesítménye” dashboard alapja.

Miért fontos?

A folyamat változtatástípus szerinti bontásával összehasonlítható a teljesítmény, és kideríthető, hogy egyes kategóriák, például a sürgősségi változtatások, okoznak-e szűk keresztmetszeteket vagy eltéréseket.

Hol szerezhető be?

A Change Request üzleti objektum egyik besorolási mezőjének felel meg, amelynek neve valószínűleg „Change Type” vagy „Category”.

Példák
StandardNormálSürgősségi
Változtatásért felelős csapat
ChangeTeam
A változtatási kérelemért jelenleg felelős csapat vagy csoport.
Leírás

A változtatásért felelős csapat a kérelemhez rendelt csoport vagy részleg. A felelőshöz hasonlóan ez is változhat a folyamat során, jelezve a felelősség átadását a csapatok között, például az ügyfélszolgálattól a hálózatüzemeltető csapathoz.

Ez az attribútum szükséges a csapatok közötti átadások elemzéséhez és az egyes csapatok által okozott, rendszerszintű késések feltárásához. Segít megállapítani, mely csapatok túlterheltek, illetve hol akad el a kommunikáció. Közvetlenül támogatja a „Változtatások átadása és az erőforrások kihasználtsága” elemzést.

Miért fontos?

Megmutatja, melyik csapat felel a kérelemért. Ez segít a folyamat szűk keresztmetszeteinek elemzésében, a csapatok teljesítményének mérésében és a csoportok közötti átadások késéseinek feltárásában.

Hol szerezhető be?

Ez az információ általában a Change Request objektum „Owned By Team” vagy hasonló, csoport-hozzárendelést tartalmazó mezőjében található.

Példák
HálózatüzemeltetésAdatbázis-adminisztrációAlkalmazástámogatás
A megvalósítás átfutási ideje
ImplementationCycleTime
A módosítás megvalósításának kezdetétől a befejezéséig eltelt, számított időtartam.
Leírás

Ez a mutató a módosítás megvalósítási szakaszának időigényét méri. A „Change Implementation Started” és a „Change Implemented” tevékenység közötti időtartam alapján számítjuk ki.

Ez az attribútum az „Átlagos módosításmegvalósítási idő” KPI kiszámítására szolgál, és támogatja a „Módosítások megvalósítása: folyamat és késések” dashboardot. Segít elkülöníteni a tervezés során keletkező csúszásokat a végrehajtás késéseitől, így a csapatok magára a műszaki megvalósításra összpontosíthatják a fejlesztési munkát.

Miért fontos?

Külön méri a tényleges megvalósítási szakasz teljesítményét, így azonosíthatók a műszaki vagy erőforrás-eredetű szűk keresztmetszetek, az engedélyezési késésektől elkülönítve.

Hol szerezhető be?

A process mining eszközben vagy az adatátalakítás során számítható ki a megvalósítás kezdetét és végét jelző események időbélyegei közötti különbségből.

Példák
4 óra 15 perc1 nap 2 óra30 perc
Elutasítás oka
ChangeRejectionReason
Szöveges leírás vagy kategória, amely megadja, miért utasították el a változtatási kérelmet.
Leírás

Ha elutasítanak egy változtatási kérelmet, ez az attribútum rögzíti a jóváhagyó által megadott indokot. Az ok előre meghatározott listából választható ki, vagy szabad szövegesen is megadható.

Ez az információ fontos az „Elutasított változtatási kérelmek elemzése” dashboardhoz. Az elutasítási okok kategorizálásával és elemzésével feltárhatók a benyújtások gyakori problémái, például a hiányos adatok, a nem megfelelő kockázatértékelés vagy az üzleti érdekellentétek. Ezek az eredmények segíthetnek a későbbi változtatási kérelmek minőségének javításában.

Miért fontos?

Közvetlenül megmutatja, miért vallanak kudarcot a változtatások. Így célzottan fejleszthető a benyújtás és az értékelés folyamata, és csökkenthető az elutasítások aránya.

Hol szerezhető be?

Ezt az adatot gyakran egy külön „Rejection Reason” mezőben vagy egy megjegyzésmezőben rögzítik, amikor az állapot „Rejected” lesz.

Példák
A megvalósítási terv nem elég részletesA kockázatértékelés hiányosÜtközés más ütemezett változtatásokkal
Érintett szolgáltatás
ServiceAffected
A változtatás által érintett elsődleges üzleti szolgáltatás vagy konfigurációs elem (CI).
Leírás

Ez az attribútum azonosítja azt a fő IT-szolgáltatást, alkalmazást vagy infrastruktúra-elemet, amelyre a változtatási kérelem irányul. Összekapcsolja a változáskezelési folyamatot az IT-szolgáltatásmenedzsment tágabb környezetével.

Az érintett szolgáltatás szerinti elemzés fontos a „Legproblémásabb változtatástípusok” KPI szempontjából. Segít megállapítani, mely szolgáltatásokon hajtanak végre gyakran változtatásokat, és melyekhez kapcsolódik magas elutasítási arány vagy késés. Ez hasznos információt ad a szolgáltatásfelelősöknek a stabilitás javításához és a műszaki adósság kezeléséhez.

Miért fontos?

A változtatásokat konkrét üzleti szolgáltatásokhoz kapcsolja, így azonosítható, mely szolgáltatások a legkevésbé stabilak, vagy melyekhez kapcsolódik a legtöbb problémás változtatás.

Hol szerezhető be?

Ez általában a konfigurációkezelési adatbázisból (CMDB) származik, és a Change Request objektum „Primary CI” vagy „Service” mezőjében tárolják.

Példák
E-mail-szolgáltatás (Exchange)ERP-rendszer (SAP)Alapvető hálózati kapcsoló (CISCO-4500X)
Időben befejezve
IsOnTimeCompletion
Számított jelző, amely akkor igaz, ha a módosítás a céldátumon vagy az előtt befejeződött.
Leírás

Ez egy logikai attribútum, amely az 'ActualCompletionDate' és a 'TargetCompletionDate' összehasonlításából származik. Egyértelműen jelzi, hogy az egyes módosítási kérelmek határidőre teljesültek-e.

Ez a jelző szolgál az „Határidőre teljesített módosítások aránya” KPI kiszámításának alapjául. A dashboardokon szűrőként használható a késedelmes módosítások elkülönítésére és elemzésére, így feltárhatók a csúszások gyakori kiváltó okai.

Miért fontos?

Egyértelműen jelzi, hogy a határidő teljesült-e, így egyszerűbbé teszi a teljesítmény elemzését, és közvetlenül támogatja a határidőre történő teljesítést mérő KPI-ket.

Hol szerezhető be?

Ez az attribútum nem szerepel a forrásrendszerben. Az adatátalakítás során számítjuk ki az 'ActualCompletionDate' <= 'TargetCompletionDate' összehasonlításával.

Példák
truefalse
Tényleges befejezési dátum
ActualCompletionDate
Az az időpont, amikor a változtatás megvalósítása ténylegesen befejeződött, és a befejezést ellenőrizték.
Leírás

A tényleges befejezési dátum azt jelöli, amikor a változtatási kérelem megvalósítási munkái befejeződtek. Ez fontos mérföldkő, amelyet a tervezett határidővel összevetve mérhető a teljesítmény.

A tervezett befejezési dátummal együtt használva megállapítható, hogy a változtatás időben elkészült-e. Ez az attribútum alapadat az időben befejezett változtatások arányát mérő KPI kiszámításához és a megvalósítási szakasz késéseinek elemzéséhez.

Miért fontos?

Rögzíti a tényleges befejezési időt, amely szükséges a határidőre történő teljesítés arányának kiszámításához és a késések mértékének elemzéséhez.

Hol szerezhető be?

Ezt a dátumot gyakran akkor rögzítik, amikor a változtatási kérelem állapota „Implemented” vagy „Completed” lesz. Külön mezőben is szerepelhet, de az állapotváltás időbélyegéből is kikövetkeztethető.

Példák
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
Üzleti egység
BusinessUnit
Az a szervezeti egység vagy részleg, amely kérte a változtatást, vagy amely annak előnyeit élvezi.
Leírás

Ez az attribútum a változtatási kérelmet a szervezet egy adott részéhez, például a pénzügyhöz, a marketinghez vagy az üzemeltetéshez kapcsolja. Így üzleti összefüggésbe helyezi az egyébként műszaki folyamatot.

Az üzleti egység szerinti elemzés megmutatja, honnan ered a változtatási igény. Támogathatja a költségek üzleti egységek közötti felosztását, segíthet megérteni, hogyan érintik az IT-változtatások az egyes üzleti területeket, és feltárhatja, hogy bizonyos egységeknél összetettebbek vagy lassabbak-e a változtatások.

Miért fontos?

Üzleti összefüggésbe helyezi az adatokat, így szervezeti szempontból elemezhető a változtatási igény, a hatás és a teljesítmény.

Hol szerezhető be?

Ez lehet a Change Request objektum egyik mezője, vagy származhat a kérelmező felhasználói profiljából.

Példák
PénzügyHumánerőforrásÉrtékesítés és marketingÜzemeltetés
Változtatás prioritása
ChangePriority
A változtatási kérelem prioritási szintje, amely a sürgősségét és az üzleti hatását jelzi.
Leírás

A változtatás prioritása a sürgősség és a hatás együttes értékelésén alapul. Segít a csapatoknak a munka rangsorolásában és az erőforrások hatékony elosztásában, hogy először a legkritikusabb változtatásokkal foglalkozzanak.

Az elemzésben a prioritás alapján összehasonlítható, hogy a magas prioritású változtatások gyorsabban haladnak-e, mint az alacsony prioritásúak. Az ettől való eltérés a rangsorolás vagy a végrehajtás hatékonysági problémáira, illetve szűk keresztmetszeteire utalhat.

Miért fontos?

Segít megállapítani, hogy a folyamat megfelelően előre sorolja-e a nagy hatású változtatásokat, és valóban gyorsabban haladnak-e ezek a tervek szerint.

Hol szerezhető be?

Általában a Change Request objektum „Priority” nevű mezője. Kézzel is megadható, de a hatás és a sürgősség mezőiből is származhat.

Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
Változtatási kérelmet benyújtó személy
ChangeSubmitter
Az a felhasználó, aki eredetileg létrehozta vagy benyújtotta a változtatási kérelmet.
Leírás

Ez az attribútum azonosítja a változtatási kérelmet kezdeményező személyt. Ez eltérhet a változtatás felelősétől, aki a folyamat későbbi szakaszában vállal felelősséget a megvalósításért.

A kérelmet benyújtó személy elemzésével feltárhatók a kérelem minőségével kapcsolatos mintázatok. Például kiderülhet, hogy bizonyos személyek vagy csapatok gyakran hiányos kérelmeket nyújtanak be, amelyek elutasításhoz vagy ismételt munkához vezetnek. Ez alapján célzott képzés szervezhető, és javítható a benyújtások általános minősége.

Miért fontos?

Segít visszakövetni, honnan indultak a változtatási kérelmek. Így személyenként vagy csapatonként elemezhető a benyújtások minősége, és azonosíthatók a képzési lehetőségek.

Hol szerezhető be?

Ez általában a Change Request objektum „Created By” vagy „Requested By” mezője.

Példák
Susan MillerDavid ChenMaria Garcia
Kötelező Javasolt Nem kötelező

A módosításkezelés tevékenységei

A pontos folyamattérképezéshez és teljesítményméréshez ezeket a fő folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban.
7 Javasolt 7 Nem kötelező
Tevékenység Leírás
A CAB jóváhagyta a változtatást
Fontos mérföldkő: a Change Advisory Board (CAB) vagy a kijelölt jóváhagyó engedélyezi a változtatás végrehajtását. Ez akkor állapítható meg, amikor a változtatási kérelem állapota „Approved” értékre vált.
Miért fontos?

Ez a tevékenység jelöli a jóváhagyási ciklusidő mérésének végét. Lehetővé teszi a folyamat továbblépését a tervezés és a bevezetés felé, és alapja a változtatások jóváhagyási ciklusideje KPI mérésének.

Hol szerezhető be?

A Change Request objektum auditelőzményeiből állapítható meg, pontosabban abból az időbélyegből, amikor a „Status” mező „Approved” értékre változik.

Rögzítés

Az „Approved” állapotra váltásból állapítható meg.

Eseménytípus inferred
A megvalósítás utáni felülvizsgálat elvégzése
Ez a tevékenység azt jelzi, hogy a befejezett változtatást hivatalosan felülvizsgálták, értékelték az eredményét, és rögzítették a tanulságokat. Gyakran a „Post Implementation Review” állapotba váltásból következtethető ki.
Miért fontos?

A nyomon követés biztosítja, hogy a változtatásokkal kapcsolatos visszajelzési folyamat lezáruljon. Ez elengedhetetlen a folyamatos fejlesztéshez, és közvetlenül támogatja a megvalósítás utáni felülvizsgálatok arányát mérő KPI-t.

Hol szerezhető be?

A Change Request objektum előzményeiből következtethető ki. Azt az időbélyeget kell rögzíteni, amikor a „Status” értéke például „Post Implementation Review” lesz.

Rögzítés

A „Post Implementation Review” állapotba váltásból következtethető ki.

Eseménytípus inferred
A változtatás lezárása
Ez a változáskezelési folyamat végső, sikeres lezárása. Akkor rögzíthető, amikor a változtatási kérelem állapota „Closed” lesz, vagyis minden munka befejeződött.
Miért fontos?

A sikeresen befejezett változtatások elsődleges végpontjaként ez a tevékenység szükséges a teljes átfutási idő kiszámításához. Megerősíti, hogy a folyamat minden lépése lezárult.

Hol szerezhető be?

A Change Request objektum naplózott előzményeiben szereplő, végső „Closed” állapotba váltás időbélyegéből következtethető ki.

Rögzítés

A végső „Closed” állapotba váltásból következtethető ki.

Eseménytípus inferred
A változtatás megvalósult
Ez a mérföldkő azt jelzi, hogy a változtatás műszaki munkái befejeződtek. Akkor rögzíthető, amikor a változtatási kérelem állapota „Implemented” vagy egy ellenőrzésre váró, hasonló állapot lesz.
Miért fontos?

Ez fontos sikermérföldkő, és az időben befejezett változtatások aránya, valamint az átlagos megvalósítási idő KPI kiszámításának egyik alapadata. A végrehajtási szakasz végét jelzi.

Hol szerezhető be?

A Change Request objektum naplója alapján következtethető ki, a „Implemented” vagy „Pending Verification” állapotba váltás időbélyegéből.

Rögzítés

Az „Implemented” állapotba váltásból következtethető ki.

Eseménytípus inferred
Hatás- és kockázatértékelés elvégezve
Ez a tevékenység jelzi, hogy befejeződött a változtatási kérelem kockázat- és hatáselemzése. Általában akkor állapítható meg, amikor a kérelem állapota jóváhagyásra kész állapotra, például „Awaiting Approval” értékre vált.
Miért fontos?

A tevékenység nyomon követésével mérhető az értékelési szakasz időtartama, és ellenőrizhető, hogy a jóváhagyás előtt következetesen elvégzik-e a kockázatelemzést. Ez támogatja a kockázatértékelési megfelelési arány KPI mérését.

Hol szerezhető be?

A Change Request objektum előzményeiből állapítható meg. Az időbélyeg azt rögzíti, amikor a „Status” mező „Assessing” értékről például „Awaiting CAB Approval” értékre változik.

Rögzítés

Az „Awaiting CAB Approval” állapotra váltásból állapítható meg.

Eseménytípus inferred
Változtatás ütemezve
Ez a tevékenység azt jelöli, amikor a változtatás bevezetésének dátumát és időpontját hivatalosan megerősítik és rögzítik. Akkor kerül rögzítésre, amikor az állapot „Scheduled” értékre változik.
Miért fontos?

Ez fontos mérföldkő a változtatás vállalásában. Az elfogadott elképzelésből tervezett intézkedés lesz, és ez a megvalósítás előfeltétele.

Hol szerezhető be?

A Change Request objektum előzményeiből következtethető ki: azt az időbélyeget kell rögzíteni, amikor a „Status” mező értéke „Scheduled” lesz.

Rögzítés

A „Scheduled” állapotba váltásból következtethető ki.

Eseménytípus inferred
Változtatási kérelem létrehozva
Ez a tevékenység jelzi, hogy új változtatási kérelem jött létre a rendszerben. Általában akkor rögzítik, amikor új rekord készül a Change Request üzleti objektumban. Ez jelöli a teljes folyamat kezdetét.
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 életciklus hossza, és feltárhatók a folyamat elején keletkező késések.

Hol szerezhető be?

Az esemény a Change Request rekord létrehozásának időbélyegéből származik. Az Ivanti Cherwell rendszerben ezt általában a Change Request üzleti objektum „CreatedDateTime” mezője tárolja.

Rögzítés

Közvetlenül a rekord létrehozásának időbélyegéből származik.

Eseménytípus explicit
A változtatás ellenőrzésének elvégzése
A tesztelési és ellenőrzési szakaszt jelzi, amelynek célja annak megerősítése, hogy a változtatás sikeres volt, és nem okozott kedvezőtlen hatásokat. A „Verification” vagy „Testing” állapotba váltásból következtethető ki.
Miért fontos?

A tevékenység gyakoriságának és időtartamának elemzésével ellenőrizhető, hogy nem maradnak-e ki a minőségbiztosítási lépések. Ez fontos a változtatások okozta incidensek megelőzésében.

Hol szerezhető be?

A Change Request objektum állapotváltásának időbélyegéből rögzíthető, például amikor az állapot „Verification” vagy „User Acceptance Testing” lesz.

Rögzítés

A „Verification” állapotba váltásból következtethető ki.

Eseménytípus inferred
A változtatás megvalósításának megkezdése
A változtatás műszaki megvalósításának kezdetét jelzi. Erre általában abból lehet következtetni, hogy a változtatási kérelem állapota „In Progress” vagy „Implementing” értékre vált.
Miért fontos?

Ez a tevékenység jelzi a megvalósítási időszak kezdetét. Az ettől a „Change Implemented” eseményig eltelt idő a tényleges megvalósítási idő, amely a teljes átfutási idő egyik fontos összetevője.

Hol szerezhető be?

A Change Request objektum naplózott előzményeiből következtethető ki. Az időbélyeg azt mutatja, mikor vált a „Status” mező értéke például „In Progress” vagy „Implementing” állapotra.

Rögzítés

Az „In Progress” állapotba váltásból következtethető ki.

Eseménytípus inferred
A változtatás visszavonása
Olyan végállapotot jelöl, amikor egy jóváhagyott vagy folyamatban lévő változtatási kérelmet a befejezés előtt visszavonnak. Akkor rögzíthető, amikor az állapot „Cancelled” lesz.
Miért fontos?

Ez a folyamat egyik lehetséges végpontja. A visszavonások okainak és időpontjának elemzése feltárhatja a tervezés, az erőforrás-elosztás vagy a változó üzleti prioritások problémáit.

Hol szerezhető be?

A naplózott előzményekből következtethető ki: azt az időbélyeget kell rögzíteni, amikor a Change Request objektum „Status” mezőjének értéke „Cancelled” lesz.

Rögzítés

A „Cancelled” állapotba váltásból következtethető ki.

Eseménytípus inferred
Bevezetési terv elkészült
A változtatás részletes tervezésének befejezését jelöli. Ide tartozik a feladatok és az erőforrások meghatározása, valamint a visszaállítási terv elkészítése. Gyakran abból állapítható meg, hogy a változtatás állapota „Approved” értékről „Scheduled” értékre vált.
Miért fontos?

A tevékenység időtartama megmutatja, mennyire hatékony a változtatás tervezési szakasza. Az itt keletkező késések a jóváhagyás után is meghosszabbíthatják a teljes folyamatot.

Hol szerezhető be?

Az „Approved” állapotról „Scheduled” állapotra váltás időbélyegéből állapítható meg. Másik lehetőségként meghatározott tervezési mezők kitöltéséhez is köthető.

Rögzítés

Az „Approved” állapotról „Scheduled” állapotra váltásból állapítható meg.

Eseménytípus inferred
Változtatás jóváhagyásra vár
Ez a tevékenység azt az időszakot jelöli, amikor a változtatási kérelem hivatalosan a Change Advisory Board (CAB) vagy más jóváhagyó döntésére vár. Ez például a „Pending Approval” vagy „Awaiting CAB” állapotból állapítható meg.
Miért fontos?

Ez egy fontos várakozási tevékenység. Az időtartam elemzésével feltárhatók a jóváhagyási workflow szűk keresztmetszetei, amelyek gyakran okoznak késést a változáskezelésben.

Hol szerezhető be?

A Change Request üzleti objektum „Status” mezője „Pending Approval” vagy azzal egyenértékű értékre váltásának időbélyegéből származik.

Rögzítés

A „Pending Approval” állapotba lépés alapján azonosítható.

Eseménytípus inferred
Változtatási kérelem benyújtva értékelésre
Az újonnan létrehozott változtatási kérelem hivatalos benyújtása az első értékelésre. Ez általában akkor állapítható meg, amikor a kérelem állapota „New” vagy „Draft” értékről például „Assessing” értékre változik.
Miért fontos?

Ez a tevékenység jelzi a hivatalos változáskezelési folyamat kezdetét az adatok első rögzítése után. A létrehozás és a benyújtás közötti idő képzési igényre vagy a folyamat akadályaira utalhat.

Hol szerezhető be?

A Change Request objektum auditnaplójából vagy előzményeiből állapítható meg: azt az időbélyeget kell azonosítani, amikor a „Status” mező értéke például „Assessing” vagy „Submitted” lesz.

Rögzítés

A „New” állapotról „Assessing” állapotra váltásból állapítható meg.

Eseménytípus inferred
Változtatási kérelem elutasítva
Ez a tevékenység a változtatási kérelem jóváhagyási szakaszban hozott végleges elutasító döntését jelöli. Akkor rögzítik, amikor a kérelem állapota „Rejected” értékre változik.
Miért fontos?

Ez a folyamat egyik fontos sikertelen végpontja. Az elutasított változtatások és azok okainak elemzése segít javítani a kérelmek kezdeti minőségét, és támogatja a változtatási kérelmek elutasítási arányának KPI mérését.

Hol szerezhető be?

A Change Request objektum auditelőzményeiben rögzített időbélyegből állapítható meg, amikor a „Status” mező „Rejected” értékre változik.

Rögzítés

A „Rejected” állapotra váltásból állapítható meg.

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

Útmutatók az adatok kinyeréséhez

Adatok kinyerése az Ivanti Cherwellből

Készen áll a kezdésre?

Használja ezt a sablont a módosításkezelési folyamat elemzésének elindításához és a fejlesztési lehetőségek feltárásához. Tegye meg az első lépést a hatékonyabb módosítások felé még ma.

Érje el a 95%-os módosítási sikerrátát: optimalizálja most az Ivanti Cherwellt

Szüntesse meg a szűk keresztmetszeteket, csökkentse a kockázatokat, és érjen el 95%-os sikerrátát a módosításoknál.

Próbálja ki ingyen

Nincs szükség bankkártyára. Azonnal elkezdheti.