Değişim Yönetimi Veri Şablonunuz
Değişim Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Doğru süreç keşfi için izlenecek temel faaliyetler
- ServiceNow'dan veri çıkarma rehberliği
Değişiklik Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Değişiklik Talebi Kimliği
ChangeRequestNumber
|
Değişiklik talebi için benzersiz tanımlayıcı, ilgili tüm olayları gruplandırmak için birincil vaka kimliği olarak hizmet eder. | ||
|
Açıklama
Değişiklik Talebi Kimliği (ID), değişiklik yönetimi süreç analizinin temel taşıdır. Her değişiklik talebine atanan, 'CHG0030001' gibi, tüm faaliyetleri, onayları ve görevleri birbirine bağlayan benzersiz bir numaradır. Süreç madenciliğinde bu öznitelik, her bir değişikliğin uçtan uca yolculuğunu yeniden yapılandırmak için kullanılır. Analistlerin oluşturulmasından kapanışına kadar tüm yaşam döngüsünü izlemesine olanak tanır ve her değişikliğin sistemde nasıl ilerlediğine dair tutarlı bir görünüm sunar. Süreçlerin bu kimliğe göre gruplandırılarak analiz edilmesi, döngü sürelerini hesaplamak, yeniden işleme döngülerini belirlemek ve süreç varyantlarını anlamak için esastır.
Neden önemli
Bu ID, bir değişikliğin tüm yaşam döngüsünü takip etmek için esastır, her talep için süreç akışının, süresinin ve uyumluluğunun eksiksiz bir analizini sağlar.
Nereden alınır
ServiceNow tablosu: change_request, Alan: number
Örnekler
CHG0030001CHG0030045CHG0030112
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya olayın meydana geldiği kesin zaman damgası. | ||
|
Açıklama
Olay Zamanı, bir aktivitenin gerçekleştirildiği veya bir durum değişikliğinin kaydedildiği kesin tarih ve saati kaydeder. Bu zaman damgası, olayları kronolojik olarak sıralamak ve tüm süreye dayalı analizler için kritik öneme sahiptir. Process Mining'de bu öznitelik, döngü sürelerinin, işlem sürelerinin ve aktiviteler arasındaki bekleme sürelerinin hesaplanmasını sağlar. Değişiklik Onay Döngüsü Süresi ve Uçtan Uca Değişiklik Süreci Akışı gibi performansı analiz eden
Neden önemli
Bu zaman damgası, olayları doğru bir şekilde sıralamak ve döngü süreleri, süreler ve SLA uyumu dahil olmak üzere tüm zamana dayalı metrikleri hesaplamak için çok önemlidir.
Nereden alınır
ServiceNow tablosu: sys_audit, Alan: sys_created_on. Bu, kaydedilen her değişiklik için zaman damgasını sağlar.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
|
|||
|
Faaliyet Adı
ActivityName
|
Değişiklik yönetimi süreci içinde meydana gelen belirli bir olayın veya görevin adı. | ||
|
Açıklama
Faaliyet Adı, bir değişiklik talebinin yaşam döngüsündeki ayrı bir adımı veya durum değişikliğini açıklar. Örnekler arasında 'Değişiklik Değerlendirme Bekliyor', 'Onay Talep Edildi' ve 'Değişiklik Uygulandı' yer alır. Bu faaliyetler, keşfedilen süreç haritasındaki düğümleri oluşturur. Bu faaliyetleri analiz etmek, süreç akışının ayrıntılı bir şekilde incelenmesini sağlar. Faaliyetlerin sırasını ve sıklığını takip ederek kuruluşlar, yaygın yolları, standart süreçten sapmaları ve değişikliklerin sıklıkla takıldığı darboğazları belirleyebilir. Bu, süreci görselleştirmek ve adımlar arasındaki geçiş süreleri gibi metrikleri hesaplamak için temeldir.
Neden önemli
Süreç akışının görselleştirilmesini, darboğazların belirlenmesini ve sapmaların analizini sağlayarak süreç haritasının omurgasını oluşturur.
Nereden alınır
Örnekler
Değişiklik OnaylandıUygulama BaşladıDeğişiklik KapatıldıDeğişiklik İptal Edildi
|
|||
|
Atama Grubu
AssignmentGroup
|
Değişiklik talebinden sorumlu ekip veya grup. | ||
|
Açıklama
Atama Grubu, 'CAB Approval', 'Network Engineering' veya 'Database Administrators' gibi değişiklik talebinden şu anda hangi ekibin sorumlu olduğunu gösterir. Bu, farklı fonksiyonel alanlardaki süreç performansını analiz etmek için kritik bir boyuttur. Bu öznitelik, ekip düzeyinde verimliliği ölçmek, belirli gruplardaki darboğazları belirlemek ve ekipler arasındaki geçişlerin etkinliğini analiz etmek için kullanılır. 'Çapraz Fonksiyonel Geçiş Verimliliği' ve 'Değişiklik Uygulama Akış Hızı' gibi Dashboard'lar, ekipler arası bağımlılıkların neden olduğu gecikmeleri tespit etmek için bu verilere büyük ölçüde güvenir.
Neden önemli
Ekiplere göre performans analizine olanak tanır, gruba özgü
Nereden alınır
ServiceNow tablosu: change_request, Alan: assignment_group
Örnekler
CAB OnayıAğ EkibiSunucu DesteğiVeritabanı Yöneticileri
|
|||
|
Bitiş Saati
EndTime
|
Bir faaliyetin sona erdiği zaman damgası. Genellikle sonraki faaliyetin başlangıç zamanından türetilir. | ||
|
Açıklama
Bitiş Zamanı, bir faaliyetin tamamlandığını işaret eder. Kaynak sistemler genellikle bir olayın başlangıcını kaydetse de, bitiş zamanı sıklıkla çıkarılır. Genellikle aynı vaka için sıradaki bir sonraki faaliyetin zaman damgası olarak hesaplanır. Bu öznitelik, işlem süresi olarak bilinen her faaliyetin süresini hesaplamak için esastır. Her adımın ne kadar sürdüğünü anlamak, süreçteki darboğazları ve verimsizlikleri belirlemek için temeldir. Bir vakadaki son faaliyet için Bitiş Zamanı, Başlangıç Zamanı ile aynıdır.
Neden önemli
Aktivite işleme süresinin hesaplanmasını sağlar; bu,
Nereden alınır
Bu öznitelik genellikle veri dönüşümü sırasında, aynı CaseId için bir sonraki olayın StartTime'ı alınarak hesaplanır.
Örnekler
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Değişiklik Durumu
ChangeState
|
Değişiklik talebinin mevcut veya geçmiş durumu, örneğin 'Assess', 'Authorize', 'Implement' veya 'Closed'. | ||
|
Açıklama
Değişiklik Durumu özniteliği, belirli bir zamanda bir değişiklik talebinin durumunu temsil eder. Değişikliğin yaşam döngüsünde nerede olduğuna dair üst düzey bir özet sunar. Belirli bir olayı temsil eden Faaliyetin aksine, Durum o olayın sonucunda ortaya çıkan koşuldur. Analizde, Değişiklik Durumu vakaları kategorize etmek ve sonuçlarını anlamak için kullanılır. Değişiklikleri filtrelemek için temeldir; örneğin, yalnızca 'Closed' değişiklikleri analiz etmek veya birçok değişikliğin neden 'Authorize' durumunda takılı kaldığını araştırmak için. 'Failed' bir durum mevcut olduğunda Değişiklik Başarısızlık Oranı gibi KPI'ları doğrudan destekler.
Neden önemli
Değişiklik talebinin durumunun anlık görüntüsünü sağlar, sonuçların analizini, vakaların filtrelenmesini ve takılı kalan değişikliklerin belirlenmesini mümkün kılar.
Nereden alınır
ServiceNow tablosu: change_request, Alan: state
Örnekler
DeğerlendirYetkilendirPlanlandıUygulaİncelemeKapalıİptal Edildi
|
|||
|
Değişiklik Türü
ChangeType
|
Değişikliğin sınıflandırması, örneğin 'Standard', 'Normal' veya 'Emergency'. | ||
|
Açıklama
Değişiklik Türü, değişiklik talebini niteliğine, riskine ve onay gereksinimlerine göre kategorize eder. Standart değişiklikler önceden onaylanır, Normal değişiklikler tam süreci takip eder ve Acil değişiklikler hızlandırılmış bir yol kullanır. Bu, süreç analizi için temel bir boyuttur, çünkü farklı değişiklik türleri farklı, yasal süreç modellerine sahiptir. Normal ve Acil değişikliklerin performansını karşılaştırmak, süreç uyumu ve verimlilik hakkında önemli içgörüler ortaya çıkarabilir. Ayrıca, benzer değişikliklerin tutarlı bir şekilde ele alınmasını sağlamak için 'Risk Değerlendirmesi Standardizasyonu' gibi
Neden önemli
Farklı değişiklik türleri farklı yetkili süreç akışlarını takip ettiğinden ve benzersiz performans beklentilerine sahip olduğundan, analizin segmentasyonuna olanak tanır.
Nereden alınır
ServiceNow tablosu: change_request, Alan: type
Örnekler
StandartNormalAcil
|
|||
|
Konfigürasyon Öğesi
ConfigurationItem
|
Değişikliğin konusu olan belirli IT bileşeni, hizmeti veya sistemi. | ||
|
Açıklama
Konfigürasyon Öğesi (CI), Konfigürasyon Yönetimi Veritabanı'ndan (CMDB) değişiklikten etkilenecek olan varlıktır. Bu bir sunucu, yazılım uygulaması, ağ cihazı veya iş hizmeti olabilir. Bu öznitelik, değişiklik için kritik bağlam sağlar. Süreç madenciliğinde, analizin değiştirilen varlık türüne göre segmentlere ayrılmasına olanak tanır. Örneğin, 'Change Testing Duration Analysis' dashboard'u, farklı uygulamalar veya sistemler için test sürelerini karşılaştırmak amacıyla bu özniteliği kullanır ve hangi CI'ların daha uzun test döngüleriyle ilişkili olduğunu belirlemeye yardımcı olur.
Neden önemli
Temel iş bağlamı sağlar, analizin etkilenen uygulama, hizmet veya sisteme göre filtrelenmesine olanak tanır ve bileşene özgü sorunları belirlemeye yardımcı olur.
Nereden alınır
ServiceNow tablosu: change_request, Alan: cmdb_ci
Örnekler
`SAP ERP`Oracle Database 19cE-posta ServisiWebServer-01
|
|||
|
Öncelik
Priority
|
Değişiklik talebinin öncelik seviyesi, etkisi ve aciliyeti tarafından belirlenir. | ||
|
Açıklama
Öncelik, bir değişiklik talebinin önemini belirtir ve hangi sırayla ele alınması gerektiğini belirler. Genellikle değişikliğin etkisi ve aciliyetinden türetilir; 'Kritik', 'Yüksek', 'Orta' ve 'Düşük' gibi değerler alır. Önceliğe göre analiz yapmak, yüksek öncelikli değişikliklerin düşük öncelikli olanlardan daha hızlı işlenmesini sağlamak için hayati öneme sahiptir. Analistlerin en önemli değişiklikler için döngü sürelerini ve başarısızlık oranlarını takip etmelerine olanak tanıyarak 'Kritik Değişiklik Performansı' dashboard'unu destekler. Düşük öncelikli değişikliklerin yüksek öncelikli olanlardan daha hızlı tamamlandığı herhangi bir sapma, kaynak tahsisi veya süreç yürütmede bir sorun olduğunu gösterir.
Neden önemli
Kaynakların en kritik değişikliklere doğru bir şekilde tahsis edilip edilmediğini değerlendirmek ve performanslarını ayrı ayrı izlemek için çok önemlidir.
Nereden alınır
ServiceNow tablosu: change_request, Alan: priority
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
Risk Seviyesi
RiskLevel
|
Değişikliğin değerlendirilen risk seviyesi, örneğin 'Yüksek', 'Orta' veya 'Düşük'. | ||
|
Açıklama
Risk Seviyesi, bir değişiklik talebi için risk değerlendirme sürecinin çıktısıdır. Değişiklik uygulanırsa olumsuz sonuçların potansiyelini nicelendirir, gerekli inceleme ve onay seviyesini belirlemeye yardımcı olur. Bu öznitelik, benzer değişikliklerin tutarlı risk derecelendirmeleri alıp almadığını kontrol etmek için kullanıldığı 'Risk Değerlendirme Standardizasyonu' dashboard'u için anahtardır. Süreç akışlarını risk seviyesine göre analiz etmek, yüksek riskli değişikliklerin düşük riskli değişikliklere kıyasla daha titiz bir onay ve test yolunu doğru bir şekilde izleyip izlemediğini de ortaya çıkarabilir, bu da önemli bir uyumluluk kontrolüdür.
Neden önemli
Uyumluluk analizi ve yüksek riskli değişikliklerin uygun düzeyde incelenmesini ve daha titiz bir süreci takip etmesini sağlamak için esastır.
Nereden alınır
ServiceNow tablosu: change_request, Alan: risk
Örnekler
YüksekOrtaDüşük
|
|||
|
Aciliyet
Urgency
|
Bir değişikliğin ne kadar hızlı çözülmesi gerektiği, Yüksek, Orta veya Düşük gibi bir ölçekte derecelendirilir. | ||
|
Açıklama
Aciliyet, bir değişikliğin ne kadar hızlı uygulanması gerektiğini tanımlar. Talebin iş perspektifinden zaman hassasiyetini yansıtır. Etki ile birlikte, genel Önceliği hesaplamak için kullanılır. Öncelik, analiz için birincil alan olsa da, Aciliyet ek bağlam sağlar. Belirli değişikliklerin neden acil olarak işaretlendiğini ve sürecin istikrarı tehlikeye atmadan bunları etkili bir şekilde karşılayıp karşılamadığını araştırmak için kullanılabilir. Kuruluşun çok sık reaktif, yüksek aciliyet modunda olup olmadığına dair soruları yanıtlamaya yardımcı olur.
Neden önemli
Bir değişikliğin zaman hassasiyeti hakkında bağlam sağlar, sürecin zaman kritik talepleri etkili bir şekilde ele alıp almadığını analiz etmeye yardımcı olur.
Nereden alınır
ServiceNow tablosu: change_request, Alan: urgency
Örnekler
1 - Yüksek2 - Orta3 - Düşük
|
|||
|
Döngü Süresi
CycleTime
|
Bir değişiklik talebinin oluşturulmasından kapanışına kadar geçen toplam süre. | ||
|
Açıklama
Döngü Süresi, bir değişiklik talebinin yaşam döngüsünün toplam süresini ölçen bir vaka düzeyinde metriktir. Belirli bir değişiklik talebi için ilk olayın zaman damgası ile en son olayın zaman damgası arasındaki fark olarak hesaplanır. Bu, genel süreç hızını ölçmek için kritik bir KPI'dır. Süreç performansına üst düzey bir bakış sağlamak için 'Uçtan Uca Değişiklik Süreci Akışı'
Neden önemli
Değişiklik sürecinin uçtan uca süresini ölçerek, genel süreç hızı ve verimliliğinin temel bir göstergesini sağlar.
Nereden alınır
Veri analizi sırasında vaka düzeyinde, her bir CaseId için maksimum Başlangıç Zamanından minimum Başlangıç Zamanı çıkarılarak hesaplanır.
Örnekler
60480012096002592000
|
|||
|
Etki
Impact
|
Değişikliğin iş operasyonları üzerindeki potansiyel etkisi, Yüksek, Orta veya Düşük gibi bir ölçekte derecelendirilir. | ||
|
Açıklama
Etki, değişiklik talebinin doğru ele alınmaması durumunda işletme üzerindeki potansiyel etkiyi ölçer. Aciliyet ile birlikte, değişikliğin genel Önceliğini belirlemek için temel bir girdidir. Etkiye göre analiz yapmak, kritik hizmetleri etkileyen değişikliklerin uygun özenle yönetilmesini sağlamaya yardımcı olur. Yüksek iş etkisi olan değişiklikleri izole etmek ve izlemek için 'Kritik Değişiklik Performansı' Dashboard'unda kullanılır. Ayrıca risk değerlendirme tutarlılığını doğrulamak ve yüksek etkili değişikliklere gerekçesiz düşük risk seviyesi atanmamasını sağlamak için de kullanılır.
Neden önemli
Değişiklikleri potansiyel iş etkilerine göre önceliklendirmeye yardımcı olur ve yüksek etkili değişikliklerin gereken özenle yönetildiğini doğrulamak için kullanılır.
Nereden alınır
ServiceNow tablosu: change_request, Alan: impact
Örnekler
1 - Yüksek2 - Orta3 - Düşük
|
|||
|
İşlem Süresi
ProcessingTime
|
Tek bir faaliyetin süresi, Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır. | ||
|
Açıklama
İşlem Süresi, aynı zamanda faaliyet süresi olarak da bilinir, belirli bir görev üzerinde aktif olarak harcanan süreyi ölçer. Faaliyetin Başlangıç Zamanı'ndan Bitiş Zamanı'nın çıkarılmasıyla hesaplanır. Bu hesaplanmış metrik, performans analizi için temeldir. Süreçteki en zaman alıcı adımların belirlenmesini sağlar; bunlar genellikle optimizasyon çabaları için birincil hedeflerdir. Test süresi veya risk değerlendirme döngü süresini analiz eden Dashboard'lar, ilgili faaliyetler için doğrudan bu metriğe dayanır.
Neden önemli
Bireysel faaliyetlerin süresini ölçer, bu da optimizasyon için başlıca aday olan en zaman alıcı adımları belirlemeyi mümkün kılar.
Nereden alınır
Veri dönüşümü sırasında hesaplanır: Bitiş Zamanı - Başlangıç Zamanı.
Örnekler
259200360086400
|
|||
|
Kapanış Kodu
CloseCode
|
Değişiklik talebi kapatıldığında sonucu belirten bir kod, örneğin 'Başarılı' veya 'Başarısız'. | ||
|
Açıklama
Kapanış Kodu, tamamlanmış bir değişiklik talebi için nihai bir karar sağlar. Değişikliğin başarılı bir şekilde, sorunlarla birlikte mi uygulandığını yoksa geri mi alındığını resmi olarak kaydeder. Bu öznitelik, 'Change Failure Rate' KPI'ı için doğrudan bir girdidir. Kapanış kodlarının dağılımını analiz ederek kuruluşlar, değişiklik girişimlerinin başarısını nicelendirebilir. Süreç haritasını 'Unsuccessful' bir kapanış koduyla filtrelemek, kök neden analizi için güçlü bir tekniktir ve başarısızlığa yol açan yaygın süreç kalıplarını ortaya çıkarır.
Neden önemli
Bir değişikliğin sonucunu doğrudan ölçer, değişiklik başarısızlık oranını hesaplamak ve başarısız değişikliklerin temel nedenlerini analiz etmek için gerekli birincil verileri sağlar.
Nereden alınır
ServiceNow tablosu: change_request, Alan: close_code
Örnekler
BaşarılıSorunlarla BaşarılıBaşarısız / Geri Alındı
|
|||
|
Kaynak Sistem
SourceSystem
|
Verinin çıkarıldığı sistem, tipik olarak 'ServiceNow'. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirler. Bu durumda ServiceNow olması beklenirken, veri yönetişimi ve birden fazla sistemden gelen verilerin birleştirilebileceği senaryolar için kritik bir alandır. Analizde, veri kökeninin net olmasını sağlar ve verinin kaynağını doğrulamaya yardımcı olur. Birden fazla ITSM aracı veya entegre sisteme sahip kuruluşlar için bu öznitelik, farklı platformlardaki süreçleri filtrelemeye ve karşılaştırmaya olanak tanır.
Neden önemli
Net veri kökeni sağlar, süreç verilerinin kaynağının belgelenmesini temin eder; bu da veri yönetişimi ve çoklu sistem analizi için hayati önem taşır.
Nereden alınır
Bu, genellikle veri çıkarma ve dönüşüm (ETL) süreci sırasında eklenen statik bir değerdir.
Örnekler
ServiceNowServiceNow_PRODSNOW_ITSM
|
|||
|
Kullanıcıya Atandı
AssignedToUser
|
Belirli bir zamanda değişiklik talebinden sorumlu bireysel kullanıcı. | ||
|
Açıklama
Bu öznitelik, değişiklik talebi üzerinde çalışmak üzere atanan belirli kişiyi tanımlar. Talep farklı aşamalar ve ekipler arasında ilerledikçe yaşam döngüsü boyunca birden çok kez değişebilir. Kullanıcıya göre analiz yapmak, iş yükü dağılımını, bireysel performansı anlamaya ve eğitim ihtiyaçlarını belirlemeye yardımcı olur. Ayrıca, işin bireyler arasında ne kadar verimli aktarıldığını görmek için Atama Grubu ile birleştirildiğinde geçişleri analiz etmek için de anahtardır.
Neden önemli
Bireysel kullanıcı iş yükünü ve performansını izlemeye yardımcı olur; farklı kaynaklar arasındaki geçiş gecikmelerini analiz etmek için çok önemlidir.
Nereden alınır
ServiceNow tablosu: change_request, Alan: assigned_to
Örnekler
Beth AnglinDavid LooAbel Tuter
|
|||
|
SLA Durumu
SlaState
|
Değişiklik talebinin Hizmet Seviyesi Anlaşması (SLA) ile ilgili durumu, örneğin 'Yolunda', 'Riskli' veya 'İhlal Edildi'. | ||
|
Açıklama
SLA Durumu, değişiklik talebinin SLA tarafından tanımlanan zaman dilimleri içinde ilerleyip ilerlemediğini gösterir. Bu durum, sürecin her aşamasında takip edilebilir. Bu öznitelik, hizmet seviyesi taahhütlerine uyumu izlemek için hayati öneme sahiptir. 'Değişiklik SLA Performansına Genel Bakış' dashboard'u ve 'Değişiklik SLA Uygunluk Oranı' KPI'ı için birincil veri kaynağıdır. SLA'ların nerede ve neden ihlal edildiğini analiz etmek, kuruluşun sistemik gecikmeleri ele almasına ve hizmet teslimatının öngörülebilirliğini artırmasına olanak tanır.
Neden önemli
Teslim tarihlerine karşı performansın doğrudan bir ölçüsünü sağlar, hizmet teslimatını iyileştirmek için SLA ihlallerinin proaktif izlenmesini ve analizini mümkün kılar.
Nereden alınır
Bu, ServiceNow'daki değişiklik talepleri gibi görevlerle ilgili SLA'ları takip eden 'task_sla' tablosundan veya vade tarihi alanlarına göre hesaplanarak elde edilebilir.
Örnekler
YolundaRisk Altındaİhlal Edildi
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu kayda ait verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, son veri çıkarma işleminin zaman damgasını sağlar. Analiz edilen verilerin güncelliğini anlamak için kritik öneme sahip bir metadata alanıdır. Analistler, güncel bilgilerle çalıştıklarını doğrulamak ve verilerin yakınlığını anlamak için bu zaman damgasını kullanır. Özellikle devam eden süreç performansını izleyen operasyonel dashboard'lar için önemlidir, kararların eski verilere dayanmamasını sağlar.
Neden önemli
Veri güncelliğini gösterir, analizlerin ve dashboard'ların güncel ve ilgili bilgilere dayanmasını sağlar.
Nereden alınır
Bu, veri çıkarma ve dönüşüm (ETL) süreci sırasında oluşturulan, veri çekme zamanını gösteren bir metadata alanıdır.
Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir aktivitenin aynı vakadaki önceki bir adımın tekrarını temsil etmesi durumunda doğru olan bir boolean işaretidir. | ||
|
Açıklama
Bu hesaplanmış öznitelik, yeniden işleme oluşturan faaliyetleri tanımlar. Yeniden işleme, sürecin onaylandıktan sonra reddedilen bir değişiklik gibi zaten tamamlanmış bir adıma geri dönmek zorunda kalmasıyla meydana gelir ve yeniden değerlendirme için geri gönderilir. Bu bayrak, süreç verimsizliğini nicelendirmek için hayati öneme sahiptir. 'Change Rework Rate' KPI'ını ve 'Change Failure and Rework Analysis' dashboard'unu doğrudan destekler. 'Is Rework' true olan faaliyetleri filtreleyerek analistler, eksik ilk değerlendirmeler veya değişen gereksinimler gibi yeniden işleme nedenlerini izole edebilir ve inceleyebilir, atık miktarını azaltmak için harekete geçebilirler.
Neden önemli
Tekrarlanan işleri işaretleyerek süreç verimsizliğini doğrudan nicelendirir, süreç döngülerinin ve boşa harcanan çabanın temel nedenlerini belirlemeye ve ele almaya yardımcı olur.
Nereden alınır
Veri dönüşümü sırasında, belirli CaseId için aynı aktivitenin (veya standart akışta daha önceki bir aktivitenin) zaten gerçekleşip gerçekleşmediği tespit edilerek hesaplanır.
Örnekler
truefalse
|
|||
Değişiklik Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Değişiklik İptal Edildi
|
Değişiklik talebi, uygulama tamamlanmadan önce bir noktada geri çekildi veya iptal edildi. Bu, durum 'Canceled' olarak ayarlandığında yakalanan alternatif bir son durumdur. | ||
|
Neden önemli
İptal edilen değişiklikleri analiz etmek, gereksiz yere oluşturulan veya onayda çok uzun süre takılı kalan ve eskiyen talepler gibi süreç verimsizliklerini ortaya çıkarabilir.
Nereden alınır
change_request tablosundaki 'state' alanının 'Canceled' olarak ayarlanmasından çıkarılır. Zaman damgası, bu durum değişikliği için denetim günlüğünden alınır.
Yakala
'State' alanı 'Canceled' olarak güncellendiğinde zaman damgasını yakalayın.
Event tipi
inferred
|
|||
|
Değişiklik Kapatıldı
|
Değişiklik talebi başarıyla tamamlandı, incelendi ve şimdi bitmiş kabul ediliyor. Bu, süreç için birincil başarı son noktasıdır ve değişiklik durumu 'Closed'a geçtiğinde yakalanır. | ||
|
Neden önemli
Bu faaliyet, değişiklik yaşam döngüsünün başarılı bir şekilde tamamlandığını işaret eder. Uçtan uca süreç süresini ve SLA uyumunu ölçmek için son olaydır.
Nereden alınır
change_request tablosundaki 'state' alanının 'Closed' olarak ayarlanmasından çıkarılır. Zaman damgası, bu nihai durum değişikliği için denetim geçmişinden alınır.
Yakala
'State' alanı 'Closed' olarak güncellendiğinde zaman damgasını yakalayın.
Event tipi
inferred
|
|||
|
Değişiklik Onaylandı
|
Değişiklik talebi, planlama ve uygulama aşamalarına geçmek için gerekli tüm yetkilendirmeleri almıştır. Bu kritik bir dönüm noktasıdır ve nihai onay verildiğinde ve 'approval' alanı 'approved' olarak ayarlandığında yakalanır. | ||
|
Neden önemli
Bu dönüm noktası, onay aşamasını sonlandırır. Onay döngüsü sürelerini ölçmek ve karar alma sürecindeki darboğazları belirlemek için esastır.
Nereden alınır
change_request tablosunun 'approval' alanının 'approved' olarak değişmesinden çıkarılır. Zaman damgası, bu değişiklik için denetim geçmişinden alınır.
Yakala
'Approval' alanı 'approved' olduğunda zaman damgasını yakalayın.
Event tipi
inferred
|
|||
|
Değişiklik Planlandı
|
Onaylanan değişikliğe planlanmış bir başlangıç ve bitiş tarihi atanmış olup, artık resmi olarak uygulama takvimindedir. Bu, değişiklik talebi durumu 'Scheduled'a geçtiğinde çıkarılır. | ||
|
Neden önemli
Bu faaliyet, planlama ve onay aşamalarını aktif uygulama aşamasından ayırır. Bu durumda geçirilen süre, onay ile işin başlangıcı arasındaki gecikmeleri gösterebilir.
Nereden alınır
change_request tablosundaki 'state' alanının 'Scheduled' olarak değişmesinden çıkarılır. Zaman damgası ilgili denetim günlüğü girişinden alınır.
Yakala
change_request tablosunun denetim geçmişindeki 'state' alanı değişikliklerini 'Scheduled'a kadar takip edin.
Event tipi
inferred
|
|||
|
Değişiklik Talebi Oluşturuldu
|
Bu faaliyet, sistemde yeni bir değişiklik talebi kaydının oluşturulmasını işaret eder. Değişiklik yönetimi sürecinin resmi başlangıcıdır ve change_request tablosuna yeni bir giriş eklendiğinde yakalanır. | ||
|
Neden önemli
Bu, süreç için birincil başlangıç olayıdır. Bu faaliyetten diğerlerine kadar geçen süreyi analiz etmek, toplam teslim süresini ortaya koyar ve sürecin en başında oluşan gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
Bu olay, ServiceNow change_request tablosundaki kayıt oluşturma zaman damgasına (sys_created_on) karşılık gelir.
Yakala
change_request tablosundaki sys_created_on zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Değişiklik Uygulandı
|
Uygulama çalışmaları tamamlandı ve değişiklik inceleme, doğrulama veya test için hazır. Bu faaliyet, değişiklik talebinin durumu 'Implement'ten 'Review'ye geçtiğinde çıkarılır. | ||
|
Neden önemli
Bu, uygulama aşamasını sonlandıran kritik bir dönüm noktasıdır. 'Change Failure Rate' ve 'Change Rework Rate' KPI'larını hesaplamak için önemli bir olaydır.
Nereden alınır
'Implement'ten 'Review' gibi sonraki bir duruma geçişten çıkarılır. Zaman damgası, change_request tablosundaki 'state' alanının denetim geçmişinden alınır.
Yakala
'state' alanı 'Implement'ten 'Review'ye değiştiğinde belirleyin.
Event tipi
inferred
|
|||
|
Risk ve Etki Değerlendirildi
|
Değişiklik talebi için risk ve etki analizinin tamamlanmasını temsil eder. Bu, onay almadan önce kritik bir dönüm noktasıdır ve genellikle değişiklik 'Assess' durumundan 'Authorize' veya 'Awaiting Approval' durumuna geçtiğinde çıkarılır. | ||
|
Neden önemli
Değerlendirme aşamasının süresini takip etmek, 'Ort. Risk Değerlendirme Döngü Süresi' KPI'ı için anahtardır. Değerlendirme sürecini standartlaştırmaya ve analizlerin nerede çok uzun sürdüğünü belirlemeye yardımcı olur.
Nereden alınır
change_request tablosundaki 'state' alanının 'Assess'ten 'Authorize'ye geçişinden çıkarılır. Olay zaman damgası, bu durum değişikliğinin denetim günlüğünden alınır.
Yakala
'state' alanı 'Assess'ten 'Authorize' gibi sonraki bir duruma değiştiğinde belirleyin.
Event tipi
inferred
|
|||
|
Değerlendirme Bekleyen Değişiklik
|
Değişiklik talebi gönderildi ve şimdi teknik ve iş değerlendirmesini beklemektedir. Bu genellikle değişiklik talebinin durumu 'Assess'e veya benzer bir duruma geçtiğinde çıkarılır, bu da taslak aşamasından çıktığını gösterir. | ||
|
Neden önemli
Bu faaliyet, talep sahibinden değerlendirme ekibine ilk geçiş süresini ölçmeye yardımcı olur. Buradaki gecikmeler, ilk veri kalitesi veya değerlendirme için kaynak kullanılabilirliği ile ilgili sorunları gösterebilir.
Nereden alınır
change_request tablosundaki 'state' alanının, tipik olarak 'Assess' gibi bir değere değişmesinden çıkarılır. Zaman damgası, bu alan değişikliği için denetim geçmişinden (sys_audit) alınır.
Yakala
change_request tablosunun denetim geçmişindeki 'state' alanı değişikliklerini 'Assess'e kadar takip edin.
Event tipi
inferred
|
|||
|
Değişiklik Reddedildi
|
Değişiklik talebi, bir onaylayan veya CAB tarafından reddedilmiştir. Bu faaliyet, yeniden işlenip tekrar gönderilmediği sürece talep için son bir durumu temsil eder. 'approval' alanı 'rejected' olarak ayarlandığında yakalanır. | ||
|
Neden önemli
Reddetmeleri takip etmek, eksik bilgi veya yüksek risk gibi yaygın reddedilme nedenlerini belirlemeye yardımcı olur. Bu analiz, gelecekteki değişiklik başvurularının kalitesini artırabilir.
Nereden alınır
change_request tablosundaki 'approval' alanının 'rejected' olarak değişmesinden çıkarılır. Zaman damgası denetim geçmişinden alınır.
Yakala
'Approval' alanı 'rejected' olduğunda zaman damgasını yakalayın.
Event tipi
inferred
|
|||
|
Değişiklik Yeniden Açıldı
|
Değişiklik talebi, daha sonraki bir aşamaya ulaştıktan sonra 'Implement' veya 'Assess' gibi önceki bir duruma geri taşınmıştır. Bu olay, doğrusal olmayan bir durum geçişinden çıkarılır ve yeniden işleme anlamına gelir. | ||
|
Neden önemli
Bu faaliyet, yeniden işleme döngülerini belirlemek ve 'Değişiklik Yeniden İşleme Oranı'nı hesaplamak için çok önemlidir. Sık yeniden açma olayları, uygulama kalitesi, test veya planlama ile ilgili sorunları gösterir.
Nereden alınır
change_request denetim geçmişindeki durum değişiklikleri dizisi analiz edilerek çıkarılır. Daha sonraki bir durumdan (örn. 'Review') daha önceki bir duruma (örn. 'Implement') geçiş, bir yeniden açma olayını gösterir.
Yakala
'State' alanının geçmişinde sıralı olmayan, geriye doğru bir geçişi tespit edin.
Event tipi
inferred
|
|||
|
İnceleme Devam Ediyor
|
Değişikliğin başarılı olup olmadığını ve hedeflerine ulaşıp ulaşmadığını belirlemek için bir uygulama sonrası inceleme (PIR) yapılmaktadır. Bu, değişiklik talebi durumu 'İnceleme' olarak ayarlandığında yakalanır. | ||
|
Neden önemli
İnceleme aşamasının süresini analiz etmek, değişiklik başarısını doğrulama gecikmelerini belirlemeye yardımcı olur. Ayrıca, bu adımın atlandığı uyumsuz değişiklikleri de vurgular.
Nereden alınır
change_request tablosundaki 'state' alanının 'Review' olarak değişmesinden çıkarılır. Zaman damgası, bu durum değişikliği için denetim günlüğünden alınır.
Yakala
Durum değişikliğinin 'Review' olarak
Event tipi
inferred
|
|||
|
Onay Talep Edildi
|
Bu faaliyet, değişiklik talebinin resmi olarak onay için gönderildiğini, tipik olarak bir yöneticiye veya Değişiklik Danışma Kurulu'na (CAB) gönderildiğini gösterir. Bu olay, değişiklik talebinin onay durumu 'requested' olarak ayarlandığında yakalanır. | ||
|
Neden önemli
Bu, onay döngüsünün başlangıcını işaret eder. Bu olaydan 'Change Approved'a kadar geçen süreyi ölçmek, 'Average Change Approval Time' KPI'ını doğrudan hesaplar.
Nereden alınır
change_request tablosundaki 'approval' alanının 'requested' olarak değişmesinden çıkarılır. Zaman damgası, bu alan için sys_audit tablosundan kaydedilir.
Yakala
change_request tablosundaki 'approval' alanının 'requested' olarak ayarlandığı zaman damgası.
Event tipi
inferred
|
|||
|
Uygulama Başladı
|
Değişikliğin uygulanması için aktif olarak çalışmaya başlanmıştır. Bu durum, değişim talebinin durumu 'Uygula' olarak güncellendiğinde kaydedilir ve planlamadan yürütmeye geçişi simgeler. | ||
|
Neden önemli
Bu, uygulamalı uygulama çalışmalarının başlangıcını işaret eder. 'Average Implementation Duration' KPI'ını ölçmek ve ekip verimliliğini analiz etmek için başlangıç noktasıdır.
Nereden alınır
change_request tablosundaki 'state' alanının 'Implement' olarak değişmesinden çıkarılır. Zaman damgası, bu durum geçişi için denetim günlüğünden alınır.
Yakala
Durum değişikliğinin 'Implement' olarak
Event tipi
inferred
|
|||