Változáskezelési adatsablon

A kezdési idő, vagyis az esemény időbélyege jelöli a változtatási kérelemhez tartozó tevékenység rögzítésének pontos dátumát és időpontját. Az eseménynapló minden tevékenységéhez, a létrehozástól a lezárásig, időbélyeg tartozik.

Ez az attribútum a process mining minden időalapú elemzéséhez szükséges. Ezzel számítható ki a folyamat átfutási ideje, a tevékenységek közötti időtartam és a várakozási idő, valamint az események sorrendje. Ez az alapja a teljesítmény nyomon követésének, az SLA-k teljesítése mérésének és a szűk keresztmetszetek feltárásának.

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ő és feltárhatók a késések.

A Jira-ügy előzménynaplójának minden bejegyzéséhez tartozó időbélyeg. A létrehozási eseménynél ez a created mező.

Ez az attribútum rögzíti, hogy egy adott időpontban milyen tevékenység történt a változtatási kérelemben. A tevékenységek a Jira állapotváltásaiból, munkafolyamat-lépéseiből vagy konkrét naplóbejegyzéseiből származnak, például „Változtatási kérelem felülvizsgálatra benyújtva” vagy „Bevezetés megkezdve”.

A process mining alapja a tevékenységek sorrendjének és gyakoriságának elemzése. Ez feltárja a tényleges folyamatútvonalakat, megmutatja a lépések közötti szűk keresztmetszeteket, és lehetővé teszi a folyamatváltozatok összevetését a szabványos működési eljárással.

Meghatározza a folyamat lépéseit, ami szükséges a folyamattérképek feltárásához, a változatok elemzéséhez és a szűk keresztmetszetek azonosításához.

Általában a Jira-ügy előzményeiből származik, különösen az állapotváltásokból vagy a folyamat mérföldköveit jelölő egyéni mezők frissítéseiből.

A változtatási kérelem azonosítója az elsődleges kulcs, amely egyedileg azonosítja a Jira Service Management minden változtatási kezdeményezését. Ez a process mining esetazonosítója: egyetlen, teljes folyamatnézetben kapcsolja össze az eseményeket, az állapotváltozásokat és a frissítéseket.

Az elemzés során ezzel az azonosítóval rekonstruálható minden változtatás teljes életciklusa. Segítségével nyomon követhetők az egyes változtatások a kockázatértékeléstől a jóváhagyáson és bevezetésen át a felülvizsgálatig. Minden mutató, KPI és dashboard erre az attribútumra támaszkodik, hogy az eseményadatokat a megfelelő változtatáshoz rendelje és összesítse.

Ez az alapvető esetazonosító, amely lehetővé teszi a változtatási kérelem teljes útjának nyomon követését és teljesítményének elemzését.

Ez a Jira-ügy szabványos kulcsa, amely a Change típusú ügyek key mezőjében található.

Ez az attribútum jelöli, melyik rendszerből származnak a folyamatadatok. Ebben az esetben az értéke mindig „Jira Service Management”.

Vállalati környezetben, ahol több rendszer adatait is összekapcsolhatják, ez a mező segít az adatok eredetének nyomon követésében, a hibakeresésben és a rendszerenként eltérő folyamatok megértésében. Egyértelművé teszi az elemzett adatok forrását.

Egyértelműen jelzi az adatok eredetét, ami több rendszer adatainak összekapcsolásakor és auditáláskor is fontos.

Ez egy statikus érték, amelyet az adatok kinyerésekor adnak hozzá az adatkészlet forrásának megjelölésére.

Ez az attribútum rögzíti, mikor kérdezték le utoljára az adatokat a forrásrendszerből. Azt mutatja, mennyire frissek az adatok a process mining eszközben.

Az attribútum elemzésével a felhasználók ellenőrizhetik, mennyire aktuálisak a folyamatadatok. Ez fontos a működési dashboardok és a valós idejű nyomon követés szempontjából. Az elemzéshez szükséges háttér-információt is megadja, így elkerülhető, hogy elavult adatok alapján szülessen döntés.

Jelzi az adatok frissességét, így az elemzések aktuális és releváns információkra épülnek.

Ez egy metaadatmező, amelyet az adatkinyerő eszköz tölt ki az adatok lekérésekor.

A Felelős az a felhasználó, aki a módosításkezelési munkafolyamat aktuális lépéséért vagy tevékenységéért felel. A módosítási kérelem életciklusa során többször is változhat a felelős, ahogy a munka más személyekhez vagy csapatokhoz kerül.

Ez az attribútum a munkaterhelés megoszlásának elemzésére, az egyes felhasználóknál jelentkező szűk keresztmetszetek azonosítására és az erőforrások elosztásának megértésére szolgál. A „Módosításkezelő csapatok tevékenységi terhelése” dashboard ezekből az adatokból mutatja meg, mely személyek vagy csoportok végzik a legtöbb tevékenységet.

Segít elemezni az erőforrások teljesítményét és a munkaterhelés megoszlását, valamint azonosítani az egyéni és csapatszintű szűk keresztmetszeteket.

Ez a Jira-ügyek alapértelmezett assignee mezője.

A kockázati szint felmérése a legtöbb módosításkezelési folyamatban kötelező. A módosítás lehetséges negatív hatását sorolja kategóriába. A szintet a kockázatfelmérés során határozzák meg, és gyakran ez befolyásolja a szükséges jóváhagyási munkafolyamatot.

A process mining során ez az attribútum a kockázatalapú elemzéshez szükséges. A „Kockázatfelmérés pontossága és eredménye” dashboardon összevethető a kezdeti kockázat a tényleges eredménnyel. A „Sikertelen módosítások aránya kockázati szint szerint” KPI elsődleges dimenziójaként azt is segít értékelni, hogy megfelelően kezelik-e a magas kockázatú módosításokat.

Segít megvizsgálni, hogy a folyamatkontrollok és a jóváhagyási munkafolyamatok hatékonyak-e az egyes kockázati profilok esetén, és összevetni a kockázatot a módosítások sikertelenségi arányával.

Ez általában egy egyéni mező a Jira Service Managementben. Gyakori neve a „Kockázati szint” vagy a „Hatás”.

A módosítás típusa annak jellege, sürgőssége és hatása alapján sorolja kategóriába a kérelmet. Gyakori típus a „Standard” az előzetesen jóváhagyott, alacsony kockázatú módosításokhoz, a „Normál” a teljes jóváhagyást igénylő, szokásos módosításokhoz, valamint a „Sürgősségi” az incidensek elhárításához szükséges, sürgős módosításokhoz.

Ez az attribútum fontos a folyamatelemzéshez, mert a különböző típusú módosítások gyakran eltérő útvonalon haladnak, és más SLA-k vonatkoznak rájuk. Az „Sürgősségi módosítások aránya” KPI kiszámításához, valamint a dashboardok szűréséhez is használható, így összehasonlítható az egyes típusok teljesítménye és kockázata.

Lehetővé teszi a folyamat különböző munkafolyamatok szerinti elemzését, például a standard és a sürgősségi módosítások összehasonlítását, amelyeknél eltérő teljesítményelvárások és kockázatok érvényesek.

Ez általában egy egyéni mező a Jira Service Management-projektekben. A mező neve változhat, de gyakran „Módosítás típusa”.

A Prioritás mező segít a csapatoknak meghatározni, milyen sorrendben foglalkozzanak a módosítási kérelmekkel. A hatást és a sürgősséget egyaránt tükrözi, és iránymutatást ad az ütemezéshez, valamint az erőforrások elosztásához.

A prioritás elemzésével összehasonlítható a magas és az alacsony prioritású módosítások teljesítménye. Megvizsgálható például, hogy a magas prioritású módosítások valóban rövidebb átfutási idővel zárulnak-e, vagy ugyanazoknál a szűk keresztmetszeteknél akadnak el, mint a többi. Ez segít az erőforrásokat a megfelelő feladatokra összpontosítani és teljesíteni az üzleti elvárásokat.

Lehetővé teszi a folyamat teljesítményének üzleti prioritás szerinti elemzését, így ellenőrizhető, hogy a kritikus módosítások a várakozásoknak megfelelően gyorsabban haladnak-e.

Ez a Jira-ügyek alapértelmezett priority mezője.

Ez a számított attribútum összeveti a módosítási kérelem tényleges lezárási dátumát a „Tervezett befejezési dátummal”. Az eredmény egyszerű állapot, például „Teljesült” vagy „Határidőn túl”.

A „Módosítási SLA teljesítményfigyelő” dashboardon egy pillantással áttekinthetővé teszi a teljesítményt. A KPI-k, például a „Módosítási SLA-teljesítési arány” létrehozását is egyszerűsíti, mert előre kiszámítja az egyes esetek állapotát. Az adatok könnyen szűrhetők és összesíthetők, így látható, mely módosítástípusokhoz, csapatokhoz vagy szolgáltatásokhoz kapcsolódik leggyakrabban az SLA túllépése.

Egyértelmű, kétértékű eredményt ad az egyes esetek SLA-teljesítéséről, így egyszerűbbé teszi a jelentéskészítést és az SLA-k betartásának elemzését.

A végső „Módosítás lezárva” tevékenység időbélyegének és a „TargetCompletionDate” attribútumnak az összevetésével számítható ki.

Ez az attribútum tárolja azt a dátumot, ameddig a módosítási kérelmet az SLA teljesítéséhez le kell zárni. Ehhez viszonyítják a tényleges befejezési időt.

Ez a dátum alapul szolgál a vállalások teljesítésének nyomon követéséhez. Erre épül a „Módosítási SLA teljesítményfigyelő” dashboard és a „Módosítási SLA-teljesítési arány” KPI. A tényleges lezárási dátum és a célidőpont összevetésével mérhető a szolgáltatásnyújtás hatékonysága.

Ez az adat szükséges az SLA-teljesítés kiszámításához és azoknak a módosításoknak az azonosításához, amelyeknél fennáll a határidő túllépésének kockázata.

Ez gyakran a Jira duedate mezője vagy a Jira Service Managementben beállított SLA-mutató értéke.

Ez az attribútum a módosítási kérelem állapotát jelzi, például: „Jóváhagyásra vár”, „Folyamatban” vagy „Lezárva”. A Jira állapotmezője alapvető szerepet tölt be a workflow-motor működésében, és a mező módosításai jelentősen befolyásolják a folyamat menetét.

Az állapot elemzésével nyomon követhető a folyamatban lévő módosítások előrehaladása, és megérthető a lezárt kérelmek eredménye, például a „Sikeresen lezárva” és a „Sikertelenül lezárva” közötti különbség. Az állapotadatok a teljesítmény dashboardok összeállításához és az újramunkálási körök elemzéséhez is szükségesek, például amikor egy kérelem visszakerül egy korábbi állapotba.

Jól követhetővé teszi a módosítási kérelem előrehaladását és végeredményét, ami elengedhetetlen az átfutás és az újramunka elemzéséhez.

Ez a Jira-ügyek alapértelmezett status mezője. Az elérhető állapotokat a projekt workflow-beállításai határozzák meg.

Ez az attribútum rögzíti a módosítás hátterében álló okot, például „Új funkció bevezetése”, „Hibajavítás” vagy „Infrastruktúra-frissítés”. A kérelem összefoglalóján és leírásán túl további kontextust ad.

Az elemzés során a módosítás oka összevethető más mutatókkal, például az átfutási idővel, a sikertelenségi aránnyal és a kockázati szinttel. Így megválaszolható például, hogy a hibajavítások gyorsabban kapnak-e jóváhagyást, mint az új funkciók bevezetése, vagy hogy az infrastruktúra-frissítések gyakrabban vezetnek-e sikertelenséghez.

Üzleti kontextust ad, így a módosítás célja összevethető a teljesítményével és az eredményével.

Ez általában egy egyéni mező a Jira Service Managementben, gyakran választólista vagy szövegmező.

A Bejelentő az a személy, aki létrehozta a módosítási kérelmet Jira-ügyként. Gyakran ő a módosítás felelőse, vagy az a személy, aki a csapata nevében kezdeményezi a módosítást.

A bejelentők elemzésével azonosítható, mely részlegek, csapatok vagy személyek kezdeményezik a legtöbb módosítást. A módosítási kérelmek forrásainak vizsgálata segíthet felismerni a trendeket, és visszajelzést vagy képzést nyújtani azoknak a csoportoknak, amelyek gyakran hiányos vagy gyenge minőségű kérelmeket nyújtanak be.

Segít azonosítani, honnan érkeznek a módosítási kérelmek, így javítható a kezdeti benyújtások minősége.

Ez a Jira-ügyek alapértelmezett reporter mezője.

Ez az attribútum azonosítja a módosításon dolgozó csapatot. A Jira az egyes személyekhez „Felelős” mezőt biztosít, a munkát azonban gyakran egy funkcionális csoporthoz rendelik a „Csapat” mezővel, például a „Hálózatüzemeltetés” vagy az „Adatbázis-adminisztrátorok” csoporthoz.

Ez az adat szükséges a „Módosításkezelő csapatok tevékenységi terhelése” dashboardhoz. Segítségével nemcsak egyéni, hanem csapatszinten is elemezhető a teljesítmény és a szűk keresztmetszetek alakulása. Ez gyakran hasznosabb az erőforrások tervezéséhez és kezeléséhez.

Lehetővé teszi a munkaterhelés és a teljesítmény elemzését csapat- vagy részlegszinten, és rávilágít a rendszerszintű szűk keresztmetszetekre.

Ez általában egy egyéni Jira-mező, mivel nincs alapértelmezett „Csapat” mező. Lehet „Group Picker” típusú mező vagy egyszerű választólista.

A módosítási kérelem lezárásakor a Megoldás mező pontosítja az eredményt. A „Kész” például sikert jelez, míg a „Nem kerül megvalósításra” vagy a „Duplikátum” más lezárási okot jelöl. Így több információt ad, mint önmagában a „Lezárva” állapot.

Ez az attribútum szükséges a módosítások sikerességi és sikertelenségi arányának elemzéséhez. A „Megvalósítás utáni problémák aránya” KPI például pontosabban értelmezhető, ha a „Sikertelen” vagy „Visszaállítva” megoldású módosításokra szűr. Segít megkülönböztetni a sikeresen megvalósított módosításokat azoktól, amelyeket jóváhagyás után visszavontak vagy elutasítottak.

Részletesen bemutatja a módosítás végeredményét, ami szükséges a sikerességi és sikertelenségi arány pontos kiszámításához.

Ez a Jira alapértelmezett resolution mezője, amelyet általában akkor állítanak be, amikor az ügy „Kész” állapotkategóriába kerül.

Ez az attribútum jelzi, hogy a módosítás negatív következménnyel járt-e, például éles üzemi incidenst okozott-e. Ehhez gyakran egy vagy több Jira-incidenst kapcsolnak a módosítási kérelemhez.

Ezek az adatok szükségesek a „Megvalósítás utáni problémák aránya” és a „Sikertelen módosítások aránya” KPI kiszámításához. Közvetlenül mérik a módosítások minőségét, valamint a tervezési, tesztelési és kockázatfelmérési folyamatok hatékonyságát. Ha megvizsgálja, mely módosítások vezetnek problémákhoz, pontosíthatja az ellenőrzéseket és megelőzheti a későbbi hibákat.

Közvetlenül méri a módosítás minőségét és sikerességét azzal, hogy nyomon követi, okozott-e későbbi működési problémákat.

Általában a Jira-ügyek közötti kapcsolatok ellenőrzésével állapítható meg, különösen azzal, hogy a módosítási ügyhöz kapcsolódik-e „okozta” kapcsolat incidensügyből.

Ez a számított attribútum azonosítja azokat a módosítási kérelmeket, amelyeket módosítás céljából visszaküldtek egy korábbi szakaszba, például a „Jóváhagyásra vár” állapotból a „Tervezés” szakaszba. Azt jelzi, hogy a kezdeti benyújtás hiányos vagy hibás volt, illetve nem felelt meg az elvárásoknak.

Ez a jelző szolgál alapul a „Módosítások újramunkálási aránya” KPI-hoz és a „Módosítások újramunkálásának és elutasításának elemzése” dashboardhoz. Az újramunkálást igénylő esetek megjelölésével az elemzők könnyen kiszűrhetik és megvizsgálhatják a kiváltó okokat, például a nem megfelelő kezdeti tervezést, a tisztázatlan követelményeket vagy a hiányos kockázatfelmérést.

Rámutat a folyamat hatékonysági problémáira azáltal, hogy megjelöli a nem tervezett többletmunkát igénylő eseteket. Így elemezhetők az újramunka kiváltó okai.

Az eseménynapló tevékenységsorrendjének elemzésével számítható ki. Újramunka történt, ha egy későbbi szakasz tevékenységét egy korábbi szakasz tevékenysége követi.

Ez az attribútum a módosítási kérelmet a konfigurációkezelési adatbázisban (CMDB) meghatározott üzleti szolgáltatáshoz kapcsolja, például az „E-mail-szolgáltatáshoz” vagy az „Ügyfél-CRM-hez”. Ez segít megérteni a módosítás üzleti hatását.

Az üzleti szolgáltatás szerinti elemzés segít a feladatok rangsorolásában és a hatások kommunikálásában az érintettek felé. Megmutatja, mely szolgáltatásokon történik a legtöbb módosítás, melyek vannak a legnagyobb kockázatnak kitéve, és hol összpontosulnak a módosításokhoz kapcsolódó incidensek. Ez fontos a műszaki módosítások üzleti szempontú kezeléséhez.

Összekapcsolja a műszaki módosításokat az üzleti hatásukkal, így az érintett szolgáltatás fontossága alapján rangsorolhatók a feladatok és elemezhető a kockázat.

Ez gyakran egy egyéni mező a JSM-ben, amely sokszor a Jira Assetshez (korábbi nevén Insight) vagy más CMDB-hez kapcsolódik.