Değişiklik yönetimi veri Templateiniz

ServiceNow
Değişiklik yönetimi veri Templateiniz

Değişiklik yönetimi veri Templateiniz

Bu Template, değişiklik yönetimi iş akışınızı Process Mining ile etkili biçimde analiz etmek için gereken temel verileri toplamanıza yardımcı olur. İzlemeniz önerilen öznitelik ve etkinlikleri, verileri dışa aktarmaya yönelik pratik bilgilerle birlikte sunar. Verilerinizi ayrıntılı analiz ve iyileştirme için hazırlamak üzere bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • Süreci doğru biçimde keşfetmek için izlenecek temel etkinlikler
  • ServiceNow’dan veri aktarmaya yönelik bilgiler
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

Değişiklik yönetimi öznitelikleri

Değişiklik yönetimi sürecinizi ayrıntılı analiz etmek için olay günlüğünüze eklemeniz önerilen veri alanları.
3 Zorunlu 7 Önerilen 9 İsteğe bağlı
Ad Açıklama
Değişiklik talebi kimliği
ChangeRequestNumber
İlgili tüm olayları gruplandırmak için kullanılan ve her değişiklik talebine özel olarak atanan kimliktir.
Açıklama

Değişiklik talebi kimliği, değişiklik yönetimi süreci analizinin temelini oluşturur. 'CHG0030001' gibi her değişiklik talebine atanan benzersiz bir numaradır ve ilgili tüm etkinlikleri, onayları ve görevleri birbirine bağlar.

Process Mining sırasında bu öznitelik, her değişikliğin baştan sona izlediği yolu yeniden oluşturmak için kullanılır. Analistlerin oluşturulmasından kapatılmasına kadar tüm yaşam döngüsünü izlemesini ve her değişikliğin sistemde nasıl ilerlediğini bütünlüklü biçimde görmesini sağlar. Çevrim sürelerini hesaplamak, yeniden çalışma döngülerini belirlemek ve süreç varyantlarını anlamak için süreçleri bu kimliğe göre gruplandırarak analiz etmek önemlidir.

Neden önemli?

Bu kimlik, her talebin tüm yaşam döngüsünü izlemek ve süreç akışını, süresini ve uyumluluğunu eksiksiz analiz etmek için gereklidir.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: number

Örnekler
CHG0030001CHG0030045CHG0030112
Olay zamanı
EventTime
Belirli bir etkinliğin veya olayın gerçekleştiği kesin zaman damgası.
Açıklama

Olay zamanı, bir etkinliğin gerçekleştirildiği veya durum değişikliğinin kaydedildiği kesin tarih ve saati belirtir. Olayları kronolojik sıraya koymak ve süreye dayalı tüm analizleri yapmak için bu zaman damgası gerekir.

Process Mining sırasında bu öznitelik, etkinlikler arasındaki çevrim sürelerini, işlem sürelerini ve bekleme sürelerini hesaplamanızı sağlar. Değişiklik onay çevrim süresi ve uçtan uca değişiklik süreci akışı gibi performansı analiz eden Dashboardlar için önemlidir. Gecikmeleri belirlemek ve süreç verimliliğini SLA’lara göre ölçmek, doğru zaman damgalarına bağlıdır.

Neden önemli?

Bu zaman damgası, olayları doğru sıraya koymak ve çevrim süreleri, süreler ve SLA uyumluluğu dahil zamana dayalı tüm metrikleri hesaplamak için gereklidir.

Nereden alınır?

ServiceNow tablosu: sys_audit, Alan: sys_created_on. Her kaydedilen değişikliğin zaman damgasını sağlar.

Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
Etkinlik adı
ActivityName
Değişiklik yönetimi sürecinde gerçekleşen belirli bir olayın veya görevin adı.
Açıklama

Etkinlik adı, değişiklik talebinin yaşam döngüsündeki belirli bir adımı veya durum değişikliğini tanımlar. Örnekler arasında 'Değişiklik değerlendirme bekliyor', 'Onay talep edildi' ve 'Değişiklik uygulandı' yer alır. Keşfedilen süreç haritasındaki düğümleri bu etkinlikler oluşturur.

Bu etkinlikleri analiz ederek süreç akışını ayrıntılı biçimde inceleyebilirsiniz. Etkinliklerin sırasını ve sıklığını izlemek, kuruluşların yaygın yolları, standart süreçten sapmaları ve değişikliklerin sık sık takıldığı darboğazları belirlemesine yardımcı olur. Süreci görselleştirmek ve adımlar arasındaki geçiş süreleri gibi metrikleri hesaplamak için bu analiz temel oluşturur.

Neden önemli?

Süreç haritasının temelini oluşturur; süreç akışını görselleştirmenizi, darboğazları belirlemenizi ve sapmaları analiz etmenizi sağlar.

Nereden alınır?

'change_request' tablosundaki 'state' alanında veya diğer önemli durum alanlarında yapılan değişikliklerden elde edilir; bu değişiklikler genellikle 'sys_audit' tablosunda kaydedilir.

Örnekler
Değişiklik onaylandıUygulama başladıDeğişiklik kapatıldıDeğişiklik iptal edildi
Atama grubu
AssignmentGroup
Değişiklik talebinden sorumlu ekip veya grup.
Açıklama

Atama grubu, değişiklik talebinden o sırada hangi ekibin sorumlu olduğunu gösterir. Örneğin 'CAB Approval', 'Network Engineering' veya 'Database Administrators'. Farklı işlev alanlarındaki süreç performansını analiz etmek için önemli bir boyuttur.

Bu öznitelik, ekip düzeyinde verimliliği ölçmek, belirli gruplardaki darboğazları belirlemek ve ekipler arasındaki devir teslimlerin etkinliğini analiz etmek için kullanılır. 'İşlevler arası devir teslim verimliliği' ve 'Değişiklik uygulama işlem hacmi' gibi Dashboardlar, ekipler arası bağımlılıkların yol açtığı gecikmeleri belirlemek için bu verilerden yararlanır.

Neden önemli?

Ekip bazında performans analizi yapmanızı sağlar; gruplara özgü darboğazları ortaya çıkarır ve farklı işlev alanları arasındaki devir teslimlerin 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ş zamanı
EndTime
Bir etkinliğin tamamlandığı zaman damgası. Genellikle sonraki etkinliğin başlangıç zamanından elde edilir.
Açıklama

Bitiş zamanı, bir etkinliğin tamamlandığı anı gösterir. Kaynak sistemler genellikle olayların başlangıcını kaydeder; bitiş zamanı ise çoğunlukla çıkarımla belirlenir. Genellikle aynı vaka içindeki sıradaki etkinliğin zaman damgası olarak hesaplanır.

Bu öznitelik, işlem süresi olarak bilinen her etkinliğin süresini hesaplamak için gereklidir. Her adımın ne kadar sürdüğünü anlamak, süreçteki darboğazları ve verimsizlikleri belirlemenin temelidir. Bir vakadaki son etkinliğin bitiş zamanı, başlangıç zamanıyla aynıdır.

Neden önemli?

Etkinliklerin işlem süresini hesaplamanızı sağlar. Bu, darboğazları belirlemek ve belirli süreç adımlarının süresini ölçmek için önemlidir.

Nereden alınır?

Bu öznitelik genellikle veri dönüştürme sırasında, aynı CaseId için sonraki olayın StartTime değeri 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şteki durumu; örneğin 'Assess', 'Authorize', 'Implement' veya 'Closed'.
Açıklama

Değişiklik durumu özniteliği, değişiklik talebinin belirli bir andaki durumunu gösterir. Değişikliğin yaşam döngüsünde hangi aşamada olduğuna dair genel bir bilgi verir. Belirli bir olayı ifade eden etkinlikten farklı olarak durum, o olayın sonucunda ortaya çıkan koşulu belirtir.

Analizde değişiklik durumu, vakaları sınıflandırmak ve sonuçlarını anlamak için kullanılır. Örneğin yalnızca 'Closed' durumundaki değişiklikleri analiz etmek veya birçok değişikliğin neden 'Authorize' durumunda takıldığını araştırmak için değişiklikleri filtreleyebilirsiniz. 'Failed' durumu varsa bu öznitelik, değişiklik başarısızlık oranı gibi KPI’ları doğrudan destekler.

Neden önemli?

Değişiklik talebinin durumunu göstererek sonuçları analiz etmenizi, vakaları filtrelemenizi ve ilerlemeyen değişiklikleri belirlemenizi sağlar.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: state

Örnekler
DeğerlendirmeYetkilendirmePlanlandıUygulamaİncelemeKapalıİptal edildi
Değişiklik türü
ChangeType
Değişikliğin 'Standard', 'Normal' veya 'Emergency' gibi sınıflandırması.
Açıklama

Değişiklik türü, değişiklik talebini niteliğine, riskine ve onay gerekliliklerine göre sınıflandırır. Standart değişiklikler önceden onaylanır, normal değişiklikler sürecin tamamından geçer, acil değişiklikler ise hızlandırılmış bir yol izler.

Farklı değişiklik türlerinin kendine özgü ve geçerli süreç modelleri olduğundan, bu sınıflandırma süreç analizinin temel boyutlarından biridir. Normal ve acil değişikliklerin performansını karşılaştırmak, sürece uyum ve verimlilik hakkında önemli bilgiler sağlayabilir. Benzer değişikliklerin tutarlı biçimde ele alındığını doğrulamak için 'Risk değerlendirmesini standartlaştırma' gibi Dashboardlarda da kullanılır.

Neden önemli?

Farklı değişiklik türleri farklı onaylı süreç akışlarını izlediğinden ve performans beklentileri değiştiğinden, analizleri bu türlere göre ayırmanızı sağlar.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: type

Örnekler
StandartNormalAcil
Öncelik
Priority
Değişiklik talebinin etkisine ve aciliyetine göre belirlenen öncelik düzeyi.
Açıklama

Öncelik, değişiklik talebinin önemini gösterir ve hangi sırayla ele alınacağını belirler. Genellikle değişikliğin etkisine ve aciliyetine göre belirlenir; değerler 'Kritik', 'Yüksek', 'Orta' ve 'Düşük' olabilir.

Önceliğe göre analiz yapmak, yüksek öncelikli değişikliklerin düşük öncelikli olanlardan daha hızlı işlenmesini sağlamaya yardımcı olur. Analistlerin en önemli değişikliklerin çevrim sürelerini ve başarısızlık oranlarını izlemesine imkân vererek 'Kritik değişiklik performansı' Dashboardunu destekler. Düşük öncelikli değişikliklerin yüksek öncelikli olanlardan daha hızlı tamamlanması, kaynak dağılımında veya sürecin yürütülmesinde bir sorun olduğunu gösterir.

Neden önemli?

Kaynakların en kritik değişikliklere doğru biçimde ayrılıp ayrılmadığını değerlendirmek ve bu değişikliklerin performansını ayrı izlemek için önemlidir.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: priority

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Risk düzeyi
RiskLevel
Değişikliğin 'Yüksek', 'Orta' veya 'Düşük' gibi değerlendirilmiş risk düzeyi.
Açıklama

Risk düzeyi, değişiklik talebine yönelik risk değerlendirmesinin sonucudur. Değişiklik uygulanırsa olumsuz sonuçların ortaya çıkma olasılığını ölçer ve gereken inceleme ve onay düzeyinin belirlenmesine yardımcı olur.

Bu öznitelik, benzer değişikliklere tutarlı risk puanları verilip verilmediğini kontrol etmek için 'Risk değerlendirmesini standartlaştırma' Dashboardunda kullanılır. Süreç akışlarını risk düzeyine göre analiz ederek yüksek riskli değişikliklerin, düşük riskli değişikliklere kıyasla daha sıkı bir onay ve test sürecinden geçip geçmediğini de görebilirsiniz. Bu, uyumluluk denetiminin önemli bir parçasıdır.

Neden önemli?

Uyumluluk analizinde ve yüksek riskli değişikliklerin uygun düzeyde incelenerek daha sıkı bir süreçten geçmesini sağlamada önemlidir.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: risk

Örnekler
YüksekOrtaDüşük
Yapılandırma öğesi
ConfigurationItem
Değişikliğin konusu olan belirli BT bileşeni, hizmeti veya sistemi.
Açıklama

Yapılandırma öğesi (CI), değişiklikten etkilenecek Yapılandırma Yönetimi Veritabanındaki (CMDB) varlıktır. Bu varlık bir sunucu, yazılım uygulaması, ağ cihazı veya iş hizmeti olabilir.

Bu öznitelik, değişiklik hakkında önemli bir bağlam sağlar. Process Mining sırasında analizleri değiştirilen varlık türüne göre ayırmanıza imkân verir. Örneğin 'Değişiklik testi süresi analizi' Dashboardu, farklı uygulama veya sistemlerin test sürelerini karşılaştırmak ve daha uzun test çevrimleriyle ilişkili CI’ları belirlemek için bu özniteliği kullanır.

Neden önemli?

Önemli iş bağlamı sağlar; bileşene özgü sorunları belirlemek için analizleri etkilenen uygulama, hizmet veya sisteme göre filtrelemenize imkân verir.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: cmdb_ci

Örnekler
SAP ERPOracle Database 19cE-posta hizmetiWebServer-01
Aciliyet
Urgency
Değişikliğin ne kadar hızlı çözüme kavuşturulması gerektiğini Yüksek, Orta veya Düşük gibi düzeylerle belirtir.
Açıklama

Aciliyet, bir değişikliğin ne kadar hızlı uygulanması gerektiğini belirtir. Talebin iş açısından zamana duyarlılığını yansıtır. Etki ile birlikte genel Öncelik değerini hesaplamak için kullanılır.

Öncelik analizde temel alınan alan olsa da Aciliyet ek bağlam sağlar. Bazı değişikliklerin neden acil olarak işaretlendiğini ve sürecin kararlılığı riske atmadan bu talepleri etkili biçimde karşılayıp karşılamadığını incelemek için kullanılabilir. Kuruluşun sık sık yüksek aciliyetle, tepkisel biçimde çalışıp çalışmadığını anlamanıza yardımcı olur.

Neden önemli?

Değişikliğin zamana duyarlılığı hakkında bağlam sağlar ve sürecin zaman açısından kritik talepleri etkili biçimde karşılayıp karşılamadığını analiz etmenize yardımcı olur.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: urgency

Örnekler
1 - Yüksek2 - Orta3 - Düşük
Atanan kullanıcı
AssignedToUser
Belirli bir zamanda değişiklik talebinden sorumlu olan kullanıcı.
Açıklama

Bu öznitelik, değişiklik talebi üzerinde çalışmakla görevlendirilen kişiyi belirtir. Talep farklı aşamalardan ve ekiplerden geçerken bu kişi yaşam döngüsü boyunca birkaç kez değişebilir.

Kullanıcıya göre analiz yapmak, iş yükü dağılımını ve bireysel performansı anlamaya, eğitim ihtiyaçlarını belirlemeye yardımcı olur. Atama grubuyla birlikte kullanıldığında devir teslimleri analiz etmek ve işin kişiler arasında ne kadar verimli aktarıldığını görmek için de önemlidir.

Neden önemli?

Kullanıcıların iş yükünü ve performansını izlemenize yardımcı olur; farklı kaynaklar arasındaki devir teslim gecikmelerini analiz etmek için önemlidir.

Nereden alınır?

ServiceNow tablosu: change_request, Alan: assigned_to

Örnekler
Beth AnglinDavid LooAbel Tuter
Çevrim süresi
CycleTime
Bir değişiklik talebinin oluşturulmasından kapatılmasına kadar geçen toplam süre.
Açıklama

Çevrim süresi, bir değişiklik talebinin yaşam döngüsü boyunca geçen toplam süreyi ölçen vaka düzeyinde bir metriktir. İlgili değişiklik talebinin ilk olayının zaman damgası ile son olayının zaman damgası arasındaki fark alınarak hesaplanır.

Bu KPI, genel süreç hızını ölçmek için temel göstergelerden biridir. Süreç performansına üst düzey bir bakış sunmak için 'Uçtan uca değişiklik süreci akışı' Dashboardunda kullanılır. Çevrim süresi eğilimlerini analiz etmek ve Değişiklik türü ya da Öncelik gibi boyutlara göre karşılaştırmak, kuruluşların süreçlerini iyileştirme fırsatlarını belirlemesine yardımcı olur.

Neden önemli?

Değişiklik sürecinin uçtan uca ne kadar sürdüğünü ölçerek genel süreç hızı ve verimliliği için önemli bir gösterge sunar.

Nereden alınır?

Veri analizi sırasında vaka düzeyinde hesaplanır: her CaseId için en büyük StartTime değerinden en küçük StartTime değeri çıkarılır.

Örnekler
60480012096002592000
Etki
Impact
Değişikliğin iş operasyonları üzerindeki olası etkisi; Yüksek, Orta veya Düşük gibi bir ölçekte değerlendirilir.
Açıklama

Etki, değişiklik talebi doğru biçimde ele alınmazsa iş üzerindeki olası sonucu ölçer. Aciliyetle birlikte değişikliğin genel önceliğini belirlemek için temel girdilerden biridir.

Etkiye göre analiz yapmak, kritik hizmetleri etkileyen değişikliklerin gereken özenle yönetilmesini sağlar. 'Kritik değişiklik performansı' Dashboardunda, iş üzerindeki etkisi yüksek değişiklikleri ayırıp izlemek için kullanılır. Ayrıca risk değerlendirmesinin tutarlılığını doğrulamaya yardımcı olur; yüksek etkili değişikliklere gerekçe olmadan düşük risk düzeyi verilmesini önler.

Neden önemli?

Değişiklikleri iş üzerindeki olası etkilerine göre önceliklendirmenize 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
Kapatma kodu
CloseCode
Değişiklik talebi kapatıldığında sonucu belirten kod. Örneğin, 'Başarılı' veya 'Başarısız'.
Açıklama

Kapatma kodu, tamamlanan bir değişiklik talebinin nihai sonucunu belirtir. Değişikliğin başarıyla uygulandığını, sorunlarla tamamlandığını veya geri alındığını kaydeder.

Bu öznitelik, 'Değişiklik başarısızlık oranı' KPI’ının doğrudan girdisidir. Kuruluşlar, kapatma kodlarının dağılımını analiz ederek değişiklik girişimlerinin başarısını ölçebilir. Süreç haritasını 'Başarısız' kapatma koduna sahip değişikliklere göre filtrelemek, başarısızlığa yol açan yaygın süreç örüntülerini ortaya çıkararak temel nedenleri analiz etmenizi sağlar.

Neden önemli?

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 gereken başlıca veriyi 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
Verilerin çıkarıldığı sistem; genellikle 'ServiceNow'.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu örnekte kaynağın ServiceNow olması beklenir. Birden fazla sistemden alınan verilerin birleştirildiği senaryolarda ve veri yönetişimi açısından önemli bir alandır.

Analiz sırasında veri kökeninin açıkça izlenmesini ve verinin kaynağının doğrulanmasını sağlar. Birden fazla ITSM aracı veya entegre sistemi olan kuruluşlar, bu öznitelikle farklı platformlardaki süreçleri filtreleyip karşılaştırabilir.

Neden önemli?

Süreç verilerinin kaynağını belgeleyerek veri kökeninin açıkça izlenmesini sağlar. Bu, veri yönetişimi ve birden fazla sistemi kapsayan analizler için önemlidir.

Nereden alınır?

Bu değer genellikle veri çıkarma ve dönüştürme (ETL) sürecinde eklenen sabit bir değerdir.

Örnekler
ServiceNowServiceNow_PRODSNOW_ITSM
SLA durumu
SlaState
Değişiklik talebinin Hizmet Seviyesi Anlaşması (SLA) kapsamındaki durumunu belirtir. Örneğin, 'Planlandığı gibi ilerliyor', 'Risk altında' veya 'İhlal edildi'.
Açıklama

SLA durumu, değişiklik talebinin SLA’da tanımlanan süreler içinde ilerleyip ilerlemediğini gösterir. Bu durum, sürecin her aşamasında izlenebilir.

Bu öznitelik, hizmet seviyesi taahhütlerine uyumluluğu izlemek için gereklidir. 'Değişiklik SLA performansına genel bakış' Dashboardu ve 'Değişiklik SLA uyum oranı' KPI’ı için temel veri kaynağıdır. SLA ihlallerinin nerede ve neden gerçekleştiğini analiz ederek kuruluş, sistem genelindeki gecikmeleri giderebilir ve hizmet sunumunun öngörülebilirliğini artırabilir.

Neden önemli?

Son tarihlere göre performansı doğrudan ölçer; hizmet sunumunu iyileştirmek için SLA ihlallerini önceden izlemenizi ve analiz etmenizi sağlar.

Nereden alınır?

Bu bilgi, değişiklik talepleri gibi görevlerle ilişkili SLA’ları izleyen ServiceNow’daki 'task_sla' tablosundan alınabilir veya son tarih alanlarına göre hesaplanabilir.

Örnekler
Planlandığı gibi ilerliyorRisk altındaİhlal edildi
Son veri güncellemesi
LastDataUpdate
Bu kaydın verilerinin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası.
Açıklama

Bu öznitelik, verilerin en son ne zaman çıkarıldığını gösteren zaman damgasını sağlar. Analiz edilen verilerin ne kadar güncel olduğunu anlamak için kullanılan bir meta veri alanıdır.

Analistler, güncel bilgilerle çalıştıklarını doğrulamak ve verilerin ne kadar yeni olduğunu görmek için bu zaman damgasını kullanır. Devam eden süreç performansını izleyen operasyonel Dashboardlar için özellikle önemlidir; kararların güncelliğini yitirmiş verilere dayanmamasını sağlar.

Neden önemli?

Verilerin güncelliğini gösterir; analizlerin ve Dashboardların güncel ve ilgili bilgilere dayanmasını sağlar.

Nereden alınır?

Veri çıkarma ve dönüştürme (ETL) sürecinde oluşturulan bu meta veri alanı, verilerin alındığı zamanı belirtir.

Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Yeniden çalışma mı
IsRework
Bir etkinliğin aynı vakadaki önceki bir adımın tekrarı olduğunu belirten Boole türünde bir işaret.
Açıklama

Bu hesaplanan öznitelik, yeniden çalışma sayılan etkinlikleri belirler. Sürecin daha önce tamamlanmış bir adıma geri dönmesi gerektiğinde yeniden çalışma oluşur. Örneğin, onaylanan bir değişiklik reddedilip yeniden değerlendirme için geri gönderilebilir.

Bu işaret, süreç verimsizliğini ölçmek için önemlidir. 'Değişikliklerde yeniden çalışma oranı' KPI’ını ve 'Değişiklik başarısızlığı ve yeniden çalışma analizi' Dashboardunu doğrudan destekler. Analistler, 'Yeniden çalışma mı' değeri doğru olan etkinlikleri filtreleyerek eksik ilk değerlendirmeler veya değişen gereksinimler gibi yeniden çalışmaya yol açan nedenleri inceleyebilir ve israfı azaltmak için adım atabilir.

Neden önemli?

Tekrarlanan işleri işaretleyerek süreç verimsizliğini doğrudan ölçer; süreç döngülerinin ve boşa harcanan emeğin temel nedenlerini belirleyip gidermenize yardımcı olur.

Nereden alınır?

Veri dönüştürme sırasında, ilgili CaseId için aynı etkinliğin (veya standart akışta daha önceki bir etkinliğin) gerçekleşip gerçekleşmediği denetlenerek hesaplanır.

Örnekler
truefalse
Zorunlu Önerilen İsteğe bağlı

Değişiklik yönetimi etkinlikleri

Değişiklik yönetimi sürecini doğru biçimde keşfetmek için olay günlüğünüzde kaydetmeniz gereken temel süreç adımları ve kilometre taşları.
7 Önerilen 6 İsteğe bağlı
Aktivite Açıklama
Değişiklik iptal edildi
Değişiklik talebi, uygulama tamamlanmadan önce geri çekilmiş veya durdurulmuştur. Durum 'Canceled' olarak ayarlandığında kaydedilen alternatif bir bitiş durumudur.
Neden önemli?

İptal edilen değişiklikleri analiz ederek gereksiz yere oluşturulan taleplerin veya onay aşamasında uzun süre bekleyip geçerliliğini yitiren taleplerin yol açtığı verimsizlikleri belirleyebilirsiniz.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Canceled' olarak ayarlanmasından anlaşılır. Zaman damgası, bu durum değişikliğinin denetim kaydından alınır.

Kaydedin

'state' alanı 'Canceled' olarak güncellendiğinde zaman damgasını kaydedin.

Olay türü inferred
Değişiklik kapatıldı
Değişiklik talebi başarıyla tamamlanmış ve incelenmiştir; artık bitmiş kabul edilir. Sürecin temel başarı bitiş noktasıdır ve değişiklik durumu 'Closed' olduğunda kaydedilir.
Neden önemli?

Bu etkinlik, değişiklik yaşam döngüsünün başarıyla tamamlandığını gösterir. Sürecin başından sonuna kadar geçen süreyi ve SLA uyumluluğunu ölçmek için bitiş olayıdır.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Closed' olarak ayarlanmasından anlaşılır. Zaman damgası, bu son durum değişikliğinin denetim geçmişinden alınır.

Kaydedin

'state' alanı 'Closed' olarak güncellendiğinde zaman damgasını kaydedin.

Olay türü inferred
Değişiklik onaylandı
Değişiklik talebi, planlama ve uygulama aşamalarına geçmek için gereken tüm onayları almıştır. Bu önemli aşama, son onay verildiğinde ve 'approval' alanı 'approved' olarak ayarlandığında kaydedilir.
Neden önemli?

Bu aşama, onay sürecini tamamlar. Onay çevrim sürelerini ölçmek ve karar alma sürecindeki darboğazları belirlemek için gereklidir.

Nereden alınır?

change_request tablosundaki 'approval' alanının 'approved' olarak değişmesinden anlaşılır. Zaman damgası, bu değişikliğin denetim geçmişinden alınır.

Kaydedin

'approval' alanı 'approved' olduğunda zaman damgasını kaydedin.

Olay türü inferred
Değişiklik planlandı
Onaylanan değişiklik için planlanan başlangıç ve bitiş tarihleri belirlenmiş, değişiklik uygulama takvimine alınmıştır. Değişiklik talebinin durumu 'Scheduled' olduğunda bu aşamaya geçildiği anlaşılır.
Neden önemli?

Bu etkinlik, planlama ve onay aşamalarını uygulama aşamasından ayırır. Bu durumda geçen süre, onay ile işin başlaması arasındaki gecikmeleri gösterebilir.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Scheduled' olarak değişmesinden anlaşılır. Zaman damgası, ilgili denetim kaydından alınır.

Kaydedin

change_request tablosunun denetim geçmişinde 'state' alanının 'Scheduled' olarak değişmesini izleyin.

Olay türü inferred
Değişiklik talebi oluşturuldu
Bu etkinlik, sistemde yeni bir değişiklik talebi kaydının oluşturulduğunu gösterir. Değişiklik yönetimi sürecinin resmî başlangıcıdır ve change_request tablosuna yeni bir kayıt eklendiğinde kaydedilir.
Neden önemli?

Bu, sürecin temel başlangıç olayıdır. Bu etkinlikten diğer etkinliklere kadar geçen süreyi analiz ederek toplam çevrim süresini görebilir ve sürecin başındaki gecikmeleri belirleyebilirsiniz.

Nereden alınır?

Bu olay, ServiceNow change_request tablosundaki kayıt oluşturma zaman damgasına (sys_created_on) karşılık gelir.

Kaydedin

change_request tablosundaki sys_created_on zaman damgasını kullanın.

Olay türü explicit
Değişiklik uygulandı
Uygulama çalışmaları tamamlanmıştır. Değişiklik artık inceleme, doğrulama veya test için hazırdır. Değişiklik talebinin durumu 'Implement' durumundan 'Review' durumuna geçtiğinde bu etkinliğin gerçekleştiği anlaşılır.
Neden önemli?

Bu önemli aşama, uygulama sürecini tamamlar. 'Değişiklik başarısızlık oranı' ve 'Değişiklikte yeniden çalışma oranı' KPI’larını hesaplamak için temel bir olaydır.

Nereden alınır?

'Implement' durumundan 'Review' gibi sonraki bir duruma geçişten anlaşılır. Zaman damgası, change_request tablosundaki 'state' alanının denetim geçmişinden alınır.

Kaydedin

'state' alanının 'Implement' durumundan 'Review' durumuna geçtiği zamanı belirleyin.

Olay türü inferred
Risk ve etki değerlendirildi
Değişiklik talebine ilişkin risk ve etki analizinin tamamlandığını gösterir. Onay alınmadan önceki önemli bir aşamadır. Değişiklik 'Assess' durumundan 'Authorize' veya 'Awaiting Approval' durumuna geçtiğinde genellikle bu aşamanın tamamlandığı anlaşılır.
Neden önemli?

Değerlendirme aşamasının süresini izlemek, 'Ortalama risk değerlendirme çevrim süresi' KPI’ını hesaplamak için önemlidir. Bu, değerlendirme sürecini standartlaştırmanıza ve analizlerin nerede gereğinden uzun sürdüğünü belirlemenize yardımcı olur.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Assess' durumundan 'Authorize' durumuna geçmesinden anlaşılır. Olayın zaman damgası, bu durum değişikliğinin denetim kaydından alınır.

Kaydedin

'state' alanının 'Assess' durumundan 'Authorize' gibi sonraki bir duruma geçtiği zamanı belirleyin.

Olay türü inferred
Değişiklik değerlendirme bekliyor
Değişiklik talebi gönderilmiştir ve teknik ve iş açısından değerlendirilmek üzere beklemektedir. Bu durum genellikle talebin durumu 'Assess' veya benzer bir değere geçtiğinde anlaşılır; bu da taslak aşamasından çıktığını gösterir.
Neden önemli?

Bu etkinlik, talep sahibinden değerlendirme ekibine yapılan ilk devir teslimin ne kadar sürdüğünü ölçmenize yardımcı olur. Buradaki gecikmeler, ilk veri kalitesiyle veya değerlendirme için kaynak bulunabilirliğiyle ilgili sorunlara işaret edebilir.

Nereden alınır?

change_request tablosundaki 'state' alanının genellikle 'Assess' gibi bir değere değişmesinden anlaşılır. Zaman damgası, bu alan değişikliğinin denetim geçmişinden (sys_audit) alınır.

Kaydedin

change_request tablosunun denetim geçmişinde 'state' alanının 'Assess' olarak değişmesini izleyin.

Olay türü inferred
Değişiklik reddedildi
Değişiklik talebi, bir onay mercii veya CAB tarafından reddedilmiştir. Yeniden çalışma yapılıp tekrar gönderilmediği sürece bu etkinlik, talebin son durumunu gösterir. 'approval' alanı 'rejected' olarak ayarlandığında kaydedilir.
Neden önemli?

Retleri izlemek; eksik bilgi veya yüksek risk gibi yaygın ret nedenlerini belirlemenize yardımcı olur. Bu analiz, gelecekte gönderilecek değişiklik taleplerinin kalitesini artırabilir.

Nereden alınır?

change_request tablosundaki 'approval' alanının 'rejected' olarak değişmesinden anlaşılır. Zaman damgası, denetim geçmişinden alınır.

Kaydedin

'approval' alanı 'rejected' olduğunda zaman damgasını kaydedin.

Olay türü inferred
Değişiklik yeniden açıldı
Değişiklik talebi, daha ileri bir aşamaya ulaştıktan sonra 'Implement' veya 'Assess' gibi önceki bir duruma geri alınmıştır. Bu olay, doğrusal olmayan bir durum geçişinden anlaşılır ve yeniden çalışma yapıldığını gösterir.
Neden önemli?

Bu etkinlik, yeniden çalışma döngülerini belirlemek ve 'Değişiklikte yeniden çalışma oranı’nı hesaplamak için önemlidir. Sık sık yeniden açılması; uygulama kalitesi, test veya planlamayla ilgili sorunlara işaret eder.

Nereden alınır?

change_request denetim geçmişindeki durum değişikliklerinin sırası incelenerek anlaşılır. Daha ileri bir durumdan (ör. 'Review') önceki bir duruma (ör. 'Implement') geçiş, talebin yeniden açıldığını gösterir.

Kaydedin

'state' alanının geçmişinde sıralı olmayan, geriye dönük bir geçiş olup olmadığını belirleyin.

Olay türü inferred
İnceleme sürüyor
Değişikliğin başarılı olup olmadığını ve hedeflerine ulaşıp ulaşmadığını belirlemek için uygulama sonrası inceleme (PIR) yürütülmektedir. Değişiklik talebinin durumu 'Review' olarak ayarlandığında kaydedilir.
Neden önemli?

İnceleme aşamasının süresini analiz ederek değişikliğin başarısını doğrulamadaki gecikmeleri belirleyebilirsiniz. Bu analiz, bu adımın atlandığı ve uyumluluk gerekliliklerinin karşılanmadığı değişiklikleri de ortaya çıkarır.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Review' olarak değişmesinden anlaşılır. Zaman damgası, bu durum değişikliğinin denetim kaydından alınır.

Kaydedin

change_request denetim geçmişinden 'Review' durumuna geçişin zaman damgasını kaydedin.

Olay türü inferred
Onay talep edildi
Bu etkinlik, değişiklik talebinin genellikle bir yöneticiye veya Değişiklik Danışma Kuruluna (CAB) onay için resmen gönderildiğini gösterir. Değişiklik talebinin onay durumu 'requested' olarak ayarlandığında kaydedilir.
Neden önemli?

Bu, onay çevriminin başlangıcını gösterir. Bu olaydan 'Değişiklik onaylandı' etkinliğine kadar geçen süreyi ölçerek 'Ortalama değişiklik onay süresi' KPI’ını doğrudan hesaplayabilirsiniz.

Nereden alınır?

change_request tablosundaki 'approval' alanının 'requested' olarak değişmesinden anlaşılır. Zaman damgası, bu alan için sys_audit tablosundan alınır.

Kaydedin

change_request tablosundaki 'approval' alanının 'requested' olarak ayarlandığı zaman damgası.

Olay türü inferred
Uygulama başladı
Değişikliği uygulama çalışmaları başlamıştır. Değişiklik talebinin durumu 'Implement' olarak güncellendiğinde bu etkinlik kaydedilir ve planlamadan uygulamaya geçildiğini gösterir.
Neden önemli?

Bu etkinlik, uygulama çalışmalarının fiilen başladığı zamanı gösterir. 'Ortalama uygulama süresi' KPI’ını hesaplamanın ve ekip verimliliğini analiz etmenin başlangıç noktasıdır.

Nereden alınır?

change_request tablosundaki 'state' alanının 'Implement' olarak değişmesinden anlaşılır. Zaman damgası, bu durum geçişinin denetim kaydından alınır.

Kaydedin

change_request denetim geçmişinden 'Implement' durumuna geçişin zaman damgasını kaydedin.

Olay türü inferred
Önerilen İsteğe bağlı

Veri aktarma rehberleri

ServiceNow’dan verilerinizi nasıl alırsınız?

Başlamaya hazır mısınız?

Verilerinizi hazırlamak ve ServiceNow’daki değişiklik yönetimi süreciniz hakkında içgörüler edinmek için bu Templateten yararlanın. Verimliliği artırmak için bugün iyileştirmelere başlayın.

Başarısız değişiklikleri durdurun, ServiceNow başarısını hemen artırın!

Darboğazları belirleyerek değişikliklerde kolayca %95 başarı oranına ulaşın.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez, kurulum birkaç dakika sürer.