Değişiklik yönetimi Veri Templateiniz

Ivanti Cherwell
Değişiklik yönetimi Veri Templateiniz

Değişiklik yönetimi Veri Templateiniz

Bu Template, değişiklik yönetimi sürecinizi analiz etmek için gereken temel verileri toplamanıza yardımcı olur. Toplanması gereken önemli öznitelikleri ve izlenecek temel etkinlikleri açıklar; ayrıca bu bilgileri kaynak sisteminizden nasıl çıkaracağınıza dair yönergeler sunar. Process Mining çalışmalarınız için bir Event Log oluştururken bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek temel etkinlikler
  • Ivanti Cherwell’den veri çıkarma yönergeleri
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önetimini ayrıntılı biçimde analiz etmek ve süreci keşfetmek için Event Logunuza eklemeniz önerilen veri alanları.
5 Zorunlu 6 Önerilen 8 İsteğe bağlı
Ad Açıklama
Değişiklik talebi kimliği
ChangeRequestId
Başlatılmasından kapatılmasına kadar ilgili tüm etkinlikleri bir araya getiren tek bir değişiklik talebi vakasının benzersiz tanımlayıcısıdır.
Açıklama

Change Request ID, her değişiklik girişimini yaşam döngüsü boyunca benzersiz biçimde tanımlayan birincil anahtardır. Process Mining çalışmalarında vaka tanımlayıcısı olarak kullanılır; gönderim, değerlendirme, onay ve uygulama gibi tüm olayları tek bir süreç örneğinde birleştirir.

Change Request ID ile yapılan veri analizi, değişiklik yönetimi sürecini baştan sona görmenizi sağlar. Böylece her değişikliği izleyebilir, toplam çevrim sürelerini hesaplayabilir ve her talebe özgü süreç sapmalarını veya darboğazları belirleyebilirsiniz.

Neden önemli?

İlgili tüm olayları birbirine bağlayan bu temel vaka tanımlayıcısı, değişiklik talebinin tüm yolculuğunu izlemeyi ve performansını analiz etmeyi sağlar.

Nereden alınır?

Bu, genellikle Ivanti Cherwell içindeki Change Request iş nesnesinin birincil tanımlayıcısıdır.

Örnekler
CR-105421CR-105422CR-105423
Etkinlik adı
ActivityName
Değişiklik yönetimi sürecinde belirli bir zamanda gerçekleşen olayın veya görevin adıdır.
Açıklama

Etkinlik adı, değişiklik talebinin yaşam döngüsündeki belirli bir adımı veya aşamayı tanımlar. Örneğin Change Submitted For Assessment veya Change Approved by CAB. Keşfedilen süreç haritasındaki düğümleri bu etkinlikler oluşturur.

Analiz sırasında bu öznitelik, süreç akışını görselleştirmek, olayların sırasını belirlemek ve standart prosedürden sapmaları tespit etmek için temel alınır. Etkinlikler arasındaki geçiş sürelerini hesaplamaya ve gecikmelerin nerede yaşandığını anlamaya yardımcı olur.

Neden önemli?

Bu öznitelik, gerçek süreç akışını keşfetmek ve görselleştirmek için önemlidir. Darboğazları, yeniden çalışma döngülerini ve uyumluluk dışı yolları belirlemenizi sağlar.

Nereden alınır?

Ivanti Cherwell içindeki Change Request nesnesiyle ilişkili durum değişikliklerinden, günlük kayıtlarından veya belirli olay günlüklerinden oluşturulur.

Örnekler
Değişiklik değerlendirme için gönderildiDeğişiklik onay bekliyorDeğişiklik uygulandı
Olay zamanı
EventTime
Değişiklik talebiyle ilgili belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgasıdır.
Açıklama

Olay zamanı, diğer adıyla zaman damgası, bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. Bu zamansal veri, olayları kronolojik sıraya koymak için gereklidir ve zamana dayalı tüm Process Mining analizlerinin temelini oluşturur.

Bu öznitelik, etkinlikler arasındaki süreleri hesaplamak, toplam vaka çevrim sürelerini ölçmek ve süreçteki bekleme sürelerini veya gecikmeleri belirlemek için kullanılır. Değişiklik Onay Çevrim Süresi gibi zamana dayalı hedeflere göre performansı izleyen Dashboardlar oluşturmanın temelini oluşturur.

Neden önemli?

Bu zaman damgası, performans ve süre analizlerinin temelini oluşturur; çevrim sürelerinin hesaplanmasını, darboğazların belirlenmesini ve SLA’ların izlenmesini sağlar.

Nereden alınır?

Genellikle Ivanti Cherwell içindeki Change Request nesnesiyle ilişkili durum değişikliği günlüklerinde, denetim izlerinde veya günlük kayıtlarının zaman damgalarında bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Kaynak sistem
SourceSystem
Verilerin alındığı kayıt sistemidir. Bu görünümde değer Ivanti Cherwell olacaktır.
Açıklama

Bu öznitelik, olay verilerinin geldiği sistemi belirtir. Farklı sistemlerin bulunduğu ortamlarda, çeşitli kaynaklardan gelen verileri ayırt etmeye yardımcı olur. Bu veri modeli için Ivanti Cherwell kaynağını belirten sabit bir değer kullanılır.

Tek kaynaklı bir modelde sabit görünse de veri yönetişimi, izlenebilirlik ve gelecekteki sistem entegrasyonları açısından önemlidir. Verinin kaynağını açıkça belirtir ve veri kalitesinin yönetilmesine yardımcı olur.

Neden önemli?

Verinin kaynağı hakkında gerekli bağlamı sağlar. Bu bilgi, veri yönetişimi, sorun giderme ve izlenebilirlik için önemlidir.

Nereden alınır?

Genellikle veri çıkarma ve dönüştürme sırasında, veri setinin kaynağını belirtmek için eklenen sabit bir değerdir.

Örnekler
Ivanti Cherwell
Son veri güncellemesi
LastDataUpdate
Bu olaya ait verilerin kaynak sistemden en son ne zaman çıkarıldığını veya yenilendiğini gösteren zaman damgasıdır.
Açıklama

Bu öznitelik, verilerin Ivanti Cherwell’den en son alındığı tarih ve saati kaydeder. Sürecin kendisindeki bir olayı değil, verinin güncelliğine ilişkin üst verileri gösterir.

Dashboard kullanıcılarının analizin ne kadar güncel olduğunu anlaması açısından önemlidir. Veri yenileme takvimlerinin yönetilmesine yardımcı olur ve kararların verinin güncelliği bilinirken alınmasını sağlar.

Neden önemli?

Verinin güncelliğini gösterir. Kullanıcıların analize güvenmesi ve analizin mevcut operasyonlarla ne kadar ilgili olduğunu anlaması için bu bilgi önemlidir.

Nereden alınır?

Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) işlemi sırasında oluşturulur ve her kayda eklenir.

Örnekler
2024-05-21T02:00:00Z
Değişiklik durumu
ChangeStatus
Değişiklik talebinin mevcut veya nihai durumudur. Örneğin Closed, Rejected veya In Progress.
Açıklama

Değişiklik durumu, değişiklik talebinin belirli bir andaki durumunu veya nihai sonucunu gösterir. Vakaların nasıl sonuçlandığını anlamak ve istisnaları belirlemek için önemli bir özniteliktir.

Süreç analizinde bu öznitelik, yalnızca reddedilen veya iptal edilen değişiklikleri incelemek gibi belirli sonuçlara göre filtreleme yapmak için kullanılır. Değişiklik Talebi Reddedilme Oranı gibi KPI’ları destekler ve değişiklik yönetimi sürecinin genel durumunu ve verimliliğini anlamak için gereklidir.

Neden önemli?

Değişiklik talebinin sonucunu tanımlar. Reddedilme ve tamamlanma oranlarının, ayrıca açık ve kapalı vakaların dağılımının analiz edilmesini sağlar.

Nereden alınır?

Ivanti Cherwell içindeki Change Request iş nesnesinin Status alanına karşılık gelir.

Örnekler
OnaylandıReddedildiKapatıldıİptal edildiOnay bekleniyor
Değişiklik ekibi
ChangeTeam
Değişiklik talebinden şu anda sorumlu olan ekip veya grup.
Açıklama

Değişiklik ekibi, değişiklik talebine atanan grup veya departmandır. Değişiklik sorumlusu gibi bu öznitelik de süreç boyunca değişebilir. Örneğin sorumluluğun Hizmet Masasından ağ mühendisliği ekibine devredilmesini gösterebilir.

Bu öznitelik, ekipler arası devir teslimleri analiz etmek ve belirli ekiplerin yol açtığı sistemik gecikmeleri belirlemek için önemlidir. Hangi ekiplerin aşırı yüklü olduğunu veya iletişim sorunlarının nerede yaşandığını anlamaya yardımcı olur ve Değişiklik Devir Teslimi ve Kaynak Kullanımı analizini doğrudan destekler.

Neden önemli?

Ekip düzeyindeki sorumluluğu gösterir. Süreç darboğazlarını analiz etmek, ekip performansını ölçmek ve gruplar arasındaki devir teslim gecikmelerini anlamak için önemlidir.

Nereden alınır?

Bu bilgi genellikle Change Request nesnesindeki Owned By Team alanında veya benzer bir grup atama alanında tutulur.

Örnekler
Ağ operasyonlarıVeritabanı yönetimiUygulama desteği
Değişiklik risk düzeyi
ChangeRiskLevel
Değişiklikle ilişkili ve Low, Medium veya High gibi değerlerle belirtilen risk düzeyidir.
Açıklama

Değişiklik risk düzeyi, değişikliğin olası olumsuz etkisini ölçmek için değerlendirme aşamasında belirlenen sınıflandırmadır. Bu değerlendirme, onay sürecini ve gereken inceleme düzeyini etkiler.

Process Mining çalışmalarında bu öznitelik, risk değerlendirmelerinin tutarlılığını analiz etmek ve riski süreç davranışıyla ilişkilendirmek için kullanılır. Örneğin yüksek riskli değişikliklerin daha sıkı bir onay sürecinden geçip geçmediğini veya uygulama sürelerinin daha uzun olup olmadığını inceleyebilirsiniz. Değişiklik Risk Değerlendirmesi Tutarlılığı Dashboardunu doğrudan destekler.

Neden önemli?

Riskin süreç akışını, onay döngülerini ve başarı oranlarını nasıl etkilediğini analiz etmeyi sağlar. Böylece yüksek riskli değişikliklerin uygun düzeyde incelenmesine yardımcı olur.

Nereden alınır?

Bu değer, Change Request nesnesindeki Risk Level veya benzer bir alanda tutulur ve genellikle risk değerlendirme etkinliği sırasında doldurulur.

Örnekler
DüşükOrtaYüksekKritik
Değişiklik sorumlusu
ChangeOwner
Değişiklik talebinden şu anda sorumlu olan kullanıcı veya kişi.
Açıklama

Değişiklik sorumlusu, belirli bir aşamada değişiklik talebine atanan ve talebin sorumluluğunu üstlenen kişidir. Talep yaşam döngüsünde ilerledikçe bu öznitelik değişebilir ve kişiler arasındaki devir teslimi gösterir.

Değişiklik sorumlusunu analiz etmek, kaynak iş yükünü anlamaya ve belirli kişilerle ilişkili darboğazları belirlemeye yardımcı olur. Ayrıca, önemli gecikmelere yol açabilen devir teslimleri analiz etmek için temel bir özniteliktir. Değişiklik Devir Teslimi ve Kaynak Kullanımı Dashboardunu destekler.

Neden önemli?

Kişi bazında sorumluluğu izler; iş yükü dağılımını, devir teslim sıklığını ve kaynaklara özgü darboğazları analiz etmeyi sağlar.

Nereden alınır?

Genellikle Change Request iş nesnesindeki Owned By veya Assigned To alanıdır.

Örnekler
Alice JohnsonBob WilliamsCharlie Brown
Değişiklik türü
ChangeType
Değişikliğin Standard, Normal veya Emergency gibi sınıflandırmasıdır.
Açıklama

Değişiklik türü, değişiklik talebini niteliğine, aciliyetine ve etkisine göre sınıflandırır. Yaygın türler arasında Standard (önceden onaylanmış, düşük riskli), Normal (tam değerlendirme ve onay gerektiren) ve Emergency (hemen uygulanması gereken) bulunur.

Bu öznitelik, farklı kategorilerdeki süreç performansını karşılaştırmak için segmentlere ayrılmış analiz yapılmasını sağlar. Örneğin acil değişikliklerin daha hızlı ve farklı bir yol izleyip izlemediğini veya standart değişikliklerin gerçekten az engelle karşılaşıp karşılaşmadığını belirlemeye yardımcı olur. Sorunlu Değişiklik Türü Performansı Dashboardu için temel bir özniteliktir.

Neden önemli?

Süreci değişiklik türüne göre segmentlere ayırmak, performansı karşılaştırmak ve Emergency gibi belirli kategorilerin darboğazlara veya sapmalara yol açıp açmadığını belirlemek için önemlidir.

Nereden alınır?

Change Request iş nesnesindeki Change Type veya Category adlı sınıflandırma alanına karşılık gelir.

Örnekler
StandartNormalAcil
Hedef tamamlanma tarihi
TargetCompletionDate
Değişikliğin uygulanmasının tamamlanması için planlanan veya üzerinde anlaşmaya varılan son tarih.
Açıklama

Hedef tamamlanma tarihi, değişikliğin tamamen uygulanıp doğrulanmasının beklendiği zaman damgasıdır. Bu tarih genellikle bir Hizmet Seviyesi Anlaşmasının (SLA) parçasıdır ve performans için temel ölçüt olarak kullanılır.

Bu öznitelik, zamanında tamamlanmayı ve son tarihlere uyumu izlemek için gereklidir. Zamanında Değişiklik Tamamlama Oranı ve Değişiklik SLA Uyum Oranı KPI’larını hesaplamak için gerçek tamamlanma tarihiyle karşılaştırılır. Hedef tarihini kaçırma riski olan değişiklikleri önceden belirlemeye yardımcı olur.

Neden önemli?

Zamanında tamamlanma performansını ve SLA uyumunu ölçmek için temel oluşturur. Bu ölçütler, süreç verimliliği ve güvenilirliğinin önemli göstergeleridir.

Nereden alınır?

Genellikle Change Request nesnesindeki Target Date, Due Date veya SLA Target adlı belirli bir tarih alanıdır.

Örnekler
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Değişikliği gönderen
ChangeSubmitter
Değişiklik talebini ilk oluşturan veya gönderen kullanıcı.
Açıklama

Bu öznitelik, değişiklik talebini başlatan kişiyi belirtir. Sürecin ilerleyen aşamalarında uygulama sorumluluğunu üstlenen değişiklik sorumlusundan farklı olabilir.

Değişikliği gönderen kişiyi analiz etmek, talep kalitesiyle ilgili örüntüleri belirlemeye yardımcı olur. Örneğin, bazı kişilerin veya ekiplerin sık sık eksik talepler göndererek ret ya da yeniden çalışmaya yol açtığı görülebilir. Bu bulgular, hedefli eğitimler düzenlemek ve gönderilen taleplerin genel kalitesini artırmak için kullanılabilir.

Neden önemli?

Değişiklik taleplerinin kaynağını izlemeye yardımcı olur. Böylece kişi veya ekip bazında gönderim kalitesi analiz edilebilir ve eğitim fırsatları belirlenebilir.

Nereden alınır?

Genellikle Change Request nesnesindeki Created By veya Requested By alanıdır.

Örnekler
Susan MillerDavid ChenMaria Garcia
Değişiklik önceliği
ChangePriority
Değişiklik talebinin aciliyetini ve iş üzerindeki etkisini gösteren öncelik düzeyidir.
Açıklama

Değişiklik önceliği, değişikliğin aciliyeti ve etkisi birlikte değerlendirilerek belirlenir. Ekiplerin işlerini önceliklendirmesine ve kaynakları etkili biçimde tahsis etmesine yardımcı olur; böylece en kritik değişiklikler önce ele alınır.

Analizde, yüksek öncelikli değişikliklerin düşük öncelikli olanlardan daha hızlı işlenip işlenmediğini görmek için kullanılabilir. Bu beklentiden sapmalar, önceliklendirme veya uygulama sürecindeki verimsizliklere ya da darboğazlara işaret edebilir.

Neden önemli?

Sürecin etkisi yüksek değişikliklere doğru önceliği verip vermediğini ve bu değişikliklerin beklendiği gibi hızlandırılıp hızlandırılmadığını analiz etmeye yardımcı olur.

Nereden alınır?

Genellikle Change Request nesnesindeki Priority adlı alandır. Elle ayarlanabilir veya etki ve aciliyet alanlarından türetilebilir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Etkilenen hizmet
ServiceAffected
Değişiklikten etkilenen temel iş hizmeti veya yapılandırma öğesi (CI).
Açıklama

Bu öznitelik, değişiklik talebinin hedeflediği temel BT hizmetini, uygulamayı veya altyapı bileşenini belirtir. Değişiklik yönetimi sürecini daha geniş BT hizmet yönetimi ortamına bağlar.

Etkilenen hizmete göre analiz, En Sorunlu Değişiklik Türleri KPI’ı için önemlidir. Hangi hizmetlerde en sık değişiklik yapıldığını ve hangilerinin yüksek ret oranlarıyla veya gecikmelerle ilişkili olduğunu belirlemeye yardımcı olur. Bu bilgiler, hizmet sorumlularının kararlılığı artırmasına ve teknik borcu yönetmesine katkı sağlar.

Neden önemli?

Değişiklikleri belirli iş hizmetleriyle ilişkilendirir. Böylece hangi hizmetlerin daha kararsız olduğunu veya en çok sorunlu değişikliğe yol açtığını analiz edebilirsiniz.

Nereden alınır?

Genellikle Yapılandırma Yönetimi Veritabanından (CMDB) alınır ve Change Request nesnesindeki Primary CI veya Service alanında tutulur.

Örnekler
E-posta hizmeti (Exchange)ERP sistemi (SAP)Ana ağ anahtarı (CISCO-4500X)
Gerçek tamamlanma tarihi
ActualCompletionDate
Değişikliğin gerçekten uygulanıp tamamlandığının doğrulandığı zaman damgasıdır.
Açıklama

Gerçek tamamlanma tarihi, değişiklik talebinin uygulama çalışmalarının bittiği anı gösterir. Performansı ölçmek için planlanan son tarihle karşılaştırılan önemli bir aşamadır.

Bu öznitelik, değişikliğin zamanında tamamlanıp tamamlanmadığını belirlemek için hedef tamamlanma tarihiyle birlikte kullanılır. Zamanında Değişiklik Tamamlama Oranı gibi KPI’ların hesaplanmasında ve uygulama aşamasındaki gecikme nedenlerinin analizinde temel girdilerden biridir.

Neden önemli?

Gerçek tamamlanma zamanını kaydeder. Zamanında teslimat oranlarını hesaplamak ve gecikmelerin boyutunu analiz etmek için gereklidir.

Nereden alınır?

Bu tarih genellikle değişiklik talebinin durumu Implemented veya Completed olarak güncellendiğinde kaydedilir. Ayrı bir alanda tutulabilir veya durum değişikliğinin zaman damgasından çıkarılabilir.

Örnekler
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
İş birimi
BusinessUnit
Değişikliği talep eden veya değişiklikten yararlanacak iş birimi ya da departman.
Açıklama

Bu öznitelik, değişiklik talebini Finans, Pazarlama veya Operasyon gibi kuruluşun belirli bir bölümüyle ilişkilendirir. Böylece teknik bir sürece iş bağlamı kazandırır.

İş birimine göre analiz, değişiklik talebinin hangi birimlerden geldiğini gösterir. Maliyet dağıtım modellerine, BT değişikliklerinin farklı işlevler üzerindeki etkisini anlamaya ve bazı birimlerdeki değişikliklerin diğerlerine göre daha karmaşık veya gecikmeli olup olmadığını belirlemeye yardımcı olabilir.

Neden önemli?

İş bağlamı sağlar; değişiklik talebini, etkisini ve performansını kuruluş genelinde analiz etmeyi mümkün kılar.

Nereden alınır?

Bu bilgi Change Request nesnesindeki bir alanda tutulabilir veya talep sahibinin kullanıcı profilinden alınabilir.

Örnekler
Finansİnsan kaynaklarıSatış ve pazarlamaOperasyonlar
Ret nedeni
ChangeRejectionReason
Değişiklik talebinin neden reddedildiğini açıklayan metin veya kategori.
Açıklama

Bir değişiklik talebi reddedildiğinde bu öznitelik, onaylayanın belirttiği nedeni kaydeder. Önceden tanımlanmış bir listeden seçim yapılabilir veya serbest metinle açıklama girilebilir.

Bu bilgi, Reddedilen Değişiklik Talepleri Analizi Dashboardu için önemlidir. Kuruluşlar ret nedenlerini sınıflandırıp analiz ederek eksik bilgi, yetersiz risk değerlendirmesi veya iş öncelikleriyle çakışma gibi değişiklik taleplerindeki yaygın sorunları belirleyebilir. Bu bulgular, gelecekteki değişiklik taleplerinin kalitesini artırmak için kullanılabilir.

Neden önemli?

Değişikliklerin neden başarısız olduğuna doğrudan ışık tutar. Gönderim ve değerlendirme süreçlerinde hedefli iyileştirmeler yaparak genel ret oranını düşürmeyi sağlar.

Nereden alınır?

Bu veri genellikle özel bir Rejection Reason alanında veya durum Rejected olarak değiştirildiğinde doldurulan bir not alanında tutulur.

Örnekler
Uygulama planında yeterli ayrıntı yokRisk değerlendirmesi tamamlanmadıPlanlanan diğer değişikliklerle çakışıyor
Uygulama çevrim süresi
ImplementationCycleTime
Değişiklik uygulamasının başlamasından tamamlanmasına kadar geçen hesaplanmış süre.
Açıklama

Bu metrik, değişiklik uygulama aşamasının ne kadar sürdüğünü ölçer. 'Change Implementation Started' etkinliği ile 'Change Implemented' etkinliği arasındaki süre hesaplanır.

Bu öznitelik, 'Ortalama Değişiklik Uygulama Süresi' KPI’ını hesaplamak ve 'Değişiklik Uygulama Akışı ve Gecikmeler' panosunu desteklemek için kullanılır. Planlama gecikmelerini uygulama gecikmelerinden ayırmaya yardımcı olur; böylece ekipler iyileştirme çalışmalarını teknik uygulama işlerine odaklayabilir.

Neden önemli?

Gerçek uygulama aşamasının performansını ayrı olarak gösterir. Onay gecikmelerinden bağımsız teknik veya kaynak kaynaklı darboğazları belirlemenize yardımcı olur.

Nereden alınır?

Uygulama başlangıcı ve bitiş olaylarının zaman damgaları arasındaki fark bulunarak Process Mining aracında veya veri dönüştürme sırasında hesaplanır.

Örnekler
4 saat 15 dakika1 gün 2 saat30 dakika
Zamanında tamamlandı mı
IsOnTimeCompletion
Hesaplanan bu bayrak, değişiklik hedef tarihte veya daha önce tamamlandıysa true değerini alır.
Açıklama

Bu boole özniteliği, 'ActualCompletionDate' ile 'TargetCompletionDate' karşılaştırılarak elde edilir. Her değişiklik talebinin zamanında tamamlanıp tamamlanmadığını net biçimde göstererek analizi kolaylaştırır.

Bu bayrak, 'Zamanında Tamamlanan Değişiklik Oranı' KPI’ını hesaplamak için kullanılır. Panolarda filtre olarak kullanıp geciken değişiklikleri kolayca ayırabilir ve analiz edebilirsiniz. Böylece gecikmelerin yaygın nedenlerini belirleyebilirsiniz.

Neden önemli?

Son teslim tarihlerine uyulup uyulmadığını net bir başarı veya başarısızlık göstergesiyle ortaya koyar ve zamanında tamamlanma KPI’larının hesaplanmasını sağlar.

Nereden alınır?

Bu öznitelik kaynak sistemde bulunmaz. Veri dönüştürme sırasında 'ActualCompletionDate' <= 'TargetCompletionDate' karşılaştırılarak hesaplanır.

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

Değişiklik yönetimi etkinlikleri

Süreci doğru biçimde keşfetmek ve performansı ölçmek için Event Logda kaydetmeniz gereken temel süreç adımları ve kilometre taşları.
7 Önerilen 7 İsteğe bağlı
Aktivite Açıklama
Değişiklik CAB tarafından onaylandı
Bu önemli aşamada Değişiklik Danışma Kurulu (CAB) veya yetkilendirilmiş merci, değişikliğin ilerlemesine onay verir. Değişiklik talebinin durumu 'Onaylandı' olarak güncellendiğinde anlaşılır.
Neden önemli?

Bu etkinlik, onay çevrim süresinin ölçümünü tamamlar. Sürecin ilerlemesini sağlayarak planlama ve uygulamanın başlamasına imkân verir; Değişiklik Onay Çevrim Süresi temel performans göstergesi için de önemlidir.

Nereden alınır?

Değişiklik Talebi nesnesinin denetim geçmişinden anlaşılır; özellikle 'Durum' alanının 'Onaylandı' olarak değiştiği zaman damgası kaydedilir.

Kaydedin

'Onaylandı' durumuna geçişten anlaşılır.

Olay türü inferred
Değişiklik kapatıldı
Bu etkinlik, değişiklik yönetimi sürecinin başarıyla tamamlandığı son aşamadır. Değişiklik talebinin durumu Closed olarak ayarlandığında kaydedilir; bu, tüm çalışmaların tamamlandığını gösterir.
Neden önemli?

Başarının temel göstergesi olan bu etkinlik, başarıyla tamamlanan değişikliklerin uçtan uca çevrim süresini hesaplamak için gereklidir. Sürecin tüm adımlarının tamamlandığını doğrular.

Nereden alınır?

Change Request nesnesinin denetim geçmişindeki son durum değişikliğinin Closed olarak ayarlandığı zaman damgasından çıkarılır.

Kaydedin

Son durumun Closed olarak değiştirilmesinden çıkarılır.

Olay türü inferred
Değişiklik planlandı
Bu etkinlik, değişikliğin uygulama tarih ve saatinin resmen kesinleştirilip kaydedildiği noktayı gösterir. Durum 'Planlandı' olarak güncellendiğinde kaydedilir.
Neden önemli?

Bu, değişiklik sürecinde önemli bir taahhüt aşamasıdır. Değişikliği onaylanmış bir fikirden planlanmış bir eyleme taşır ve uygulama için ön koşuldur.

Nereden alınır?

Change Request nesnesinin geçmişinden, Status alanının Scheduled olarak güncellendiği zaman damgası alınarak çıkarılır.

Kaydedin

Scheduled durumuna geçişten çıkarılır.

Olay türü inferred
Değişiklik talebi oluşturuldu
Bu etkinlik, sistemde yeni bir değişiklik talebinin başlatıldığını gösterir. Genellikle Değişiklik Talebi iş nesnesinde yeni bir kayıt oluşturulduğunda kaydedilir ve tüm sürecin başlangıç noktasını belirler.
Neden önemli?

Bu, sürecin temel başlangıç olayıdır. Bu etkinlikten diğerlerine kadar geçen süreyi analiz etmek, toplam yaşam döngüsü süresini gösterir ve sürecin ilk aşamalarındaki gecikmeleri belirlemeye yardımcı olur.

Nereden alınır?

Bu olay, Değişiklik Talebi kaydının oluşturulma zaman damgasından alınır. Ivanti Cherwell’de bu bilgi genellikle Değişiklik Talebi iş nesnesinin 'CreatedDateTime' alanında saklanır.

Kaydedin

Doğrudan kayıt oluşturma zaman damgasından alınır.

Olay türü explicit
Değişiklik uygulandı
Bu aşama, değişiklik için gereken teknik çalışmanın tamamlandığını gösterir. Değişiklik talebinin durumu Implemented veya doğrulama bekleyen benzer bir duruma güncellendiğinde kaydedilir.
Neden önemli?

Bu, başarının önemli bir göstergesidir ve Zamanında Değişiklik Tamamlama Oranı ile Ortalama Değişiklik Uygulama Süresi KPI’larının temel girdilerindendir. Uygulama aşamasının sonunu gösterir.

Nereden alınır?

Change Request nesnesinin denetim günlüğünden, durumun Implemented veya Pending Verification olarak değiştiği zaman damgası kullanılarak çıkarılır.

Kaydedin

Implemented durumuna geçişten çıkarılır.

Olay türü inferred
Etki ve risk değerlendirildi
Bu etkinlik, değişiklik talebine ilişkin risk ve etki analizinin tamamlandığını gösterir. Genellikle değişiklik talebinin durumu 'Onay bekliyor' gibi onaya hazır olduğunu belirten bir duruma geçtiğinde anlaşılır.
Neden önemli?

Bu etkinliği izlemek, değerlendirme aşamasının süresini ölçmeye ve onaydan önce risk analizinin tutarlı biçimde yapılmasını sağlamaya yardımcı olur. Ayrıca Risk Değerlendirmesine Uyum Oranı temel performans göstergesini destekler.

Nereden alınır?

Değişiklik Talebi nesnesinin geçmişinden anlaşılır. 'Durum' alanının 'Değerlendiriliyor' durumundan 'CAB onayı bekliyor' gibi bir duruma güncellendiği zaman damgası kaydedilir.

Kaydedin

'CAB onayı bekliyor' durumuna geçişten anlaşılır.

Olay türü inferred
Uygulama sonrası inceleme yapıldı
Bu etkinlik, tamamlanan değişikliğin başarısını değerlendirmek ve çıkarılan dersleri kaydetmek için resmî bir inceleme yapıldığını gösterir. Genellikle durumun Post Implementation Review olarak değişmesinden çıkarılır.
Neden önemli?

Bu etkinliği izlemek, değişikliklerle ilgili geri bildirim döngüsünün tamamlanmasını sağlar. Sürekli iyileştirme için önemlidir ve Uygulama Sonrası İnceleme Oranı KPI’ını doğrudan destekler.

Nereden alınır?

Change Request nesnesinin denetim geçmişinden, Status alanının Post Implementation Review gibi bir duruma geçtiği zaman damgası alınarak çıkarılır.

Kaydedin

Post Implementation Review durumuna geçişten çıkarılır.

Olay türü inferred
Değişiklik değerlendirme için gönderildi
Yeni oluşturulan bir değişiklik talebinin ilk değerlendirme için resmen gönderilmesini ifade eder. Genellikle değişiklik talebinin durumu 'Yeni' veya 'Taslak' durumundan 'Değerlendiriliyor' gibi bir duruma geçtiğinde anlaşılır.
Neden önemli?

Bu etkinlik, ilk veri girişinin ardından resmî değişiklik sürecinin başladığını gösterir. Oluşturma ile gönderim arasındaki süre, kullanıcı eğitimi ihtiyacına veya süreçteki aksaklıklara işaret edebilir.

Nereden alınır?

Değişiklik Talebi nesnesinin denetim günlüğü veya geçmişi incelenerek, 'Durum' alanının 'Değerlendiriliyor' ya da 'Gönderildi' gibi bir değere geçtiği zaman damgası belirlenir.

Kaydedin

'Yeni' durumundan 'Değerlendiriliyor' durumuna geçişten anlaşılır.

Olay türü inferred
Değişiklik doğrulaması yapıldı
Değişikliğin başarılı olduğunu ve olumsuz bir etkiye yol açmadığını doğrulamak için yapılan test ve doğrulama aşamasını gösterir. Durum Verification veya Testing olarak değiştiğinde çıkarılır.
Neden önemli?

Bu etkinliğin sıklığını ve süresini analiz etmek, kalite güvence adımlarının atlanmamasını sağlar. Değişikliklerden kaynaklanan olayları önlemek için önemli bir adımdır.

Nereden alınır?

Change Request nesnesindeki durum değişikliğinin zaman damgasından alınır. Örneğin durum Verification veya User Acceptance Testing olarak değiştiğinde kaydedilir.

Kaydedin

Verification durumuna geçişten çıkarılır.

Olay türü inferred
Değişiklik iptal edildi
Onaylanmış veya devam eden bir değişiklik talebinin tamamlanmadan geri çekildiği son durumu gösterir. Durum Cancelled olarak güncellendiğinde kaydedilir.
Neden önemli?

Bu, sürecin alternatif bir bitiş noktasıdır. Değişikliklerin neden ve ne zaman iptal edildiğini analiz etmek; planlama, kaynak tahsisi veya değişen iş öncelikleriyle ilgili sorunları ortaya çıkarabilir.

Nereden alınır?

Denetim geçmişinden, Change Request nesnesindeki Status alanının Cancelled olarak güncellendiği zaman damgası alınarak çıkarılır.

Kaydedin

Cancelled durumuna geçişten çıkarılır.

Olay türü inferred
Değişiklik onay bekliyor
Bu etkinlik, değişiklik talebinin Değişiklik Danışma Kurulundan (CAB) veya başka bir onay merciinden resmî olarak karar beklediği dönemi ifade eder. 'Onay bekliyor' veya 'CAB bekleniyor' gibi bir durumdan anlaşılır.
Neden önemli?

Bu etkinlikteki bekleme süresi özellikle önemlidir. Süreyi analiz etmek, değişiklik yönetiminde sık görülen gecikme nedenlerinden biri olan onay iş akışındaki darboğazları belirlemeye yardımcı olur.

Nereden alınır?

Değişiklik Talebi iş nesnesindeki 'Durum' alanının 'Onay bekliyor' veya eşdeğer bir değere güncellendiği zaman damgasından alınır.

Kaydedin

'Onay bekliyor' durumuna geçişle belirlenir.

Olay türü inferred
Değişiklik reddedildi
Bu etkinlik, onay aşamasında değişiklik talebinin reddedilmesine yönelik nihai kararı ifade eder. Değişiklik talebinin durumu 'Reddedildi' olarak ayarlandığında kaydedilir.
Neden önemli?

Bu, sürecin başarısızlıkla sonuçlandığı önemli bir noktadır. Reddedilen değişiklikleri ve ret nedenlerini analiz etmek, ilk başvuruların kalitesini artırmaya ve Değişiklik Talebi Ret Oranı temel performans göstergesini iyileştirmeye yardımcı olur.

Nereden alınır?

Denetim geçmişinde, Değişiklik Talebi nesnesindeki 'Durum' alanının 'Reddedildi' olarak güncellendiği zaman damgasından anlaşılır.

Kaydedin

'Reddedildi' durumuna geçişten anlaşılır.

Olay türü inferred
Değişiklik uygulaması başladı
Değişikliğin teknik uygulamasının başladığını gösterir. Genellikle değişiklik talebinin durumu In Progress veya Implementing olarak güncellendiğinde çıkarılır.
Neden önemli?

Bu etkinlik, uygulama döneminin başlangıcını gösterir. Bu etkinlikle Change Implemented arasındaki süre, toplam çevrim süresinin önemli bir bileşeni olan gerçek uygulama süresidir.

Nereden alınır?

Change Request nesnesinin denetim geçmişinden çıkarılır. Status alanının In Progress veya Implementing gibi bir değere güncellendiği zaman damgasıdır.

Kaydedin

In Progress durumuna geçişten çıkarılır.

Olay türü inferred
Uygulama planı hazırlandı
Görevlerin, kaynakların ve geri dönüş planlarının belirlenmesi dahil olmak üzere değişiklik için ayrıntılı planlamanın tamamlandığını gösterir. Değişiklik 'Onaylandı' durumundan 'Planlandı' durumuna geçtiğinde anlaşılabilir.
Neden önemli?

Bu etkinliğin süresi, değişiklik planlama aşamasının verimliliğini gösterir. Onay alınmış olsa bile bu aşamadaki gecikmeler genel değişiklik takvimini etkileyebilir.

Nereden alınır?

'Onaylandı' durumundan 'Planlandı' durumuna geçişin zaman damgasından anlaşılabilir. Alternatif olarak belirli planlama alanlarının doldurulmasıyla ilişkilendirilebilir.

Kaydedin

'Onaylandı' durumundan 'Planlandı' durumuna geçişten anlaşılır.

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

Veri çıkarma rehberleri

Ivanti Cherwell’den verilerinizi nasıl alırsınız?

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

Değişiklik yönetimi sürecinizi analiz etmeye hemen başlayın ve önemli iyileştirmeler için bu Templateten yararlanın. Daha verimli güncellemelere giden yolda bugün ilk adımı atın.

Değişiklik başarı oranını %95’e çıkarın: Ivanti Cherwell’i şimdi iyileştirin

Darboğazları ortadan kaldırın, riskleri azaltın ve değişikliklerde %95 başarıya ulaşın.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez. Hemen başlayın.