Değişim Yönetimi Veri Şablonunuz

ServiceNow
Değişim Yönetimi Veri Şablonunuz

Değişim Yönetimi Veri Şablonunuz

Bu şablon, Değişiklik Yönetimi iş akışınızın etkili süreç madenciliği için gerekli temel verileri toplamak üzere yapılandırılmış bir yaklaşım sunar. Önerilen öznitelikleri ve izlenecek faaliyetleri, veri çıkarma için pratik rehberlikle birlikte özetler. Verilerinizi kapsamlı analiz ve optimizasyon için hazırlamak üzere bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Doğru süreç keşfi için izlenecek temel faaliyetler
  • ServiceNow'dan veri çıkarma rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Değişiklik Yönetimi Öznitelikleri

Bunlar, değişiklik yönetimi sürecinizin kapsamlı bir analizi için olay günlüğünüze dahil etmeniz önerilen veri alanlarıdır.
3 Gerekli 7 Önerilen 10 İsteğe Bağlı
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 dashboard'lar için elzemdir. Doğru zaman damgaları, gecikmeleri belirlemek ve süreç verimliliğini SLA'lara göre ölçmek için temel oluşturur.

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

change_request tablosundaki 'state' alanı veya diğer temel durum alanlarındaki değişikliklerden türetilmiştir; genellikle sys_audit tablosunda yakalanı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ü bottleneck'leri vurgular ve farklı fonksiyonel alanlar arasındaki aktarımların verimliliğini ölçer.

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, bottleneck'leri belirlemek ve belirli süreç adımlarının süresini ölçmek için çok önemlidir.

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 dashboard'larda da kullanılır.

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ışı' dashboard'unda kullanılır. Döngü süresi eğilimlerini analiz etmek ve bunları Değişiklik Türü veya Öncelik gibi farklı boyutlarda karşılaştırmak, kuruluşların stratejik süreç iyileştirme fırsatlarını belirlemesine yardımcı olur.

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
Gerekli Önerilen İsteğe Bağlı

Değişiklik Yönetimi Aktiviteleri

Bunlar, doğru değişiklik yönetimi süreç keşfi için olay günlüğünüzde yakalamanız gereken temel süreç adımları ve dönüm noktalarıdır.
7 Önerilen 6 İsteğe Bağlı
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 change_request denetim geçmişinden zaman damgasını yakalayın.

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 change_request denetim geçmişinden zaman damgasını yakalayın.

Event tipi inferred
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Verilerinizi ServiceNow'dan nasıl alırsınız?