Değişim Yönetimi Veri Şablonunuz

Ivanti Cherwell
Değişim Yönetimi Veri Şablonunuz

Değişim Yönetimi Veri Şablonunuz

Bu `template`, Değişiklik Yönetimi sürecinizi analiz etmek için gereken temel `data`'yı toplamak için net bir yol haritası sunar. Toplanması gereken kritik `attributes`'leri, izlenecek temel etkinlikleri özetler ve bu bilgileri kaynak sisteminizden ayıklamak için özel rehberlik sağlar. `Process Mining` girişimleriniz için sağlam bir `event log` oluşturmak üzere bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • Ivanti Cherwell'den 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, kapsamlı değişiklik yönetimi analizi ve içgörülü süreç keşfi için `event log`'unuza dahil etmeniz önerilen `data` alanlarıdır.
5 Gerekli 6 Önerilen 9 İsteğe Bağlı
Ad Açıklama
Değişiklik Talebi Kimliği
ChangeRequestId
Tek bir değişiklik talebi `case`'i için, başlatmadan kapanışa kadar tüm ilgili etkinlikleri gruplandıran benzersiz tanımlayıcı.
Açıklama

Değişiklik Talebi Kimliği, her değişiklik girişimini yaşam döngüsü boyunca benzersiz bir şekilde tanımlayan birincil anahtardır. Process Mining'de case tanımlayıcısı olarak hizmet eder, gönderim, değerlendirme, onay ve uygulama gibi tüm event'leri tek, uyumlu bir süreç örneğine bağlar.

Değişiklik Talebi Kimliği'ni kullanarak data analizi, değişiklik yönetimi sürecinin baştan sona eksiksiz bir görünümünü sağlar. Bu, bireysel değişikliklerin izlenmesini, toplam döngü sürelerinin hesaplanmasını ve her talebe özgü süreç sapmalarının veya bottleneck'lerin belirlenmesini mümkün kılar.

Neden önemli

Bu, ilgili tüm event'leri birbirine bağlayan, bir değişiklik talebinin tüm yolculuğunu izlemeyi ve performansını analiz etmeyi mümkün kılan temel case tanımlayıcısıdır.

Nereden alınır

Bu, tipik olarak Ivanti Cherwell'deki Değişiklik Talebi iş nesnesinin birincil tanımlayıcısıdır.

Örnekler
CR-105421CR-105422CR-105423
Faaliyet Adı
ActivityName
Değişiklik yönetimi süreci içinde belirli bir zamanda meydana gelen belirli `event` veya görevin adı.
Açıklama

Etkinlik Adı, 'Değerlendirme İçin Gönderilen Değişiklik' veya 'CAB Tarafından Onaylanan Değişiklik' gibi bir değişiklik talebinin yaşam döngüsündeki belirli bir adımı veya kilometre taşını tanımlar. Bu etkinlikler, keşfedilen süreç haritasındaki düğümleri oluşturur.

Analizde, bu öznitelik süreç akışını görselleştirmek, event dizisini belirlemek ve standart prosedürden sapmaları tespit etmek için temeldir. Etkinlikler arasındaki geçiş sürelerini hesaplamak ve gecikmelerin nerede meydana geldiğini anlamak için kullanılır.

Neden önemli

Bu öznitelik, bottleneck'leri, yeniden işleme döngülerini ve uyumlu olmayan yolları belirlemeye olanak tanıyan, gerçek süreç akışını keşfetmek ve görselleştirmek için çok önemlidir.

Nereden alınır

Ivanti Cherwell'deki Değişiklik Talebi nesnesiyle ilgili durum değişikliklerinden, günlük girişlerinden veya belirli olay günlüklerinden oluşturulur.

Örnekler
Değerlendirme İçin Gönderilen DeğişiklikOnay Bekleyen DeğişiklikDeğişiklik Uygulandı
Olay Zamanı
EventTime
Değişiklik talebi için belirli bir etkinliğin veya `event`'in ne zaman meydana geldiğini gösteren `timestamp`.
Açıklama

Olay Zamanı, aynı zamanda zaman damgası olarak da bilinir, bir aktivitenin gerçekleştiği kesin tarihi ve saati kaydeder. Bu zamansal veri, olayları kronolojik olarak sıralamak için esastır ve tüm zamana dayalı süreç madenciliği analizlerinin temelini oluşturur.

Bu öznitelik, aktiviteler arasındaki süreleri hesaplamak, genel vaka döngü sürelerini ölçmek ve süreçteki bekleme sürelerini veya gecikmeleri belirlemek için kullanılır. Değişiklik Onay Süresi gibi zamana dayalı hedeflere karşı performansı izleyen gösterge tabloları oluşturmak için temeldir.

Neden önemli

Bu timestamp, tüm performans ve süre analizi için temeldir; döngü sürelerinin hesaplanmasını, bottleneck'lerin belirlenmesini ve SLA'ların izlenmesini sağlar.

Nereden alınır

Tipik olarak Ivanti Cherwell'deki Değişiklik Talebi nesnesiyle ilişkili durum değişiklik log'larında, denetim izlerinde veya günlük giriş timestamp'lerinde bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
Kaynak Sistem
SourceSystem
Verinin çekildiği kayıt sistemi. Bu görünüm için 'Ivanti Cherwell' olacaktır.
Açıklama

Bu öznitelik, event verileri için kaynak sistemi belirler. Heterojen ortamlarda, farklı kaynaklardan gelen verileri ayırt etmeye yardımcı olur. Bu özel veri modeli için, verilerin Ivanti Cherwell'den geldiğini gösteren sabit bir değer olacaktır.

Tek kaynaklı bir modelde statik gibi görünse de, veri yönetişimi, izlenebilirlik ve diğer sistemlerle gelecekteki entegrasyonlar için çok önemlidir. Veri kökeni hakkında netlik sağlar ve veri kalitesini yönetmeye yardımcı olur.

Neden önemli

Verinin kökeni hakkında temel bağlam sağlar; bu da veri yönetişimi, sorun giderme ve izlenebilirliği sağlamak için çok önemlidir.

Nereden alınır

Bu genellikle veri çıkarma ve dönüştürme süreci sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir.

Örnekler
Ivanti Cherwell
Son Veri Güncellemesi
LastDataUpdate
Bu `event` için verilerin kaynak sistemden en son ne zaman çekildiğini veya yenilendiğini gösteren `timestamp`.
Açıklama

Bu öznitelik, verilerin Ivanti Cherwell'den en son ne zaman çekildiğini kaydeder. Sürecin kendisinde bir event'i temsil etmez, ancak verilerin güncelliği hakkında metadata'dır.

Bu, dashboard tüketicilerinin analizin ne kadar güncel olduğunu anlamaları için önemlidir. Veri yenileme programlarını yönetmeye yardımcı olur ve kararların bilinen yaşta verilere dayanmasını sağlar.

Neden önemli

Verilerin güncelliğini gösterir; bu, kullanıcıların analize güvenmesi ve mevcut operasyon durumuna uygunluğunu anlaması için kritik öneme sahiptir.

Nereden alınır

Bu timestamp, data çekme, dönüştürme ve yükleme (ETL) süreci sırasında her kayda oluşturulur ve damgalanır.

Örnekler
2024-05-21T02:00:00Z
Değişiklik Durumu
ChangeStatus
Değişiklik talebinin 'Kapalı', 'Reddedildi' veya 'Devam Ediyor' gibi güncel veya nihai durumu.
Açıklama

Değişiklik Durumu, belirli bir zaman noktasındaki bir değişiklik talebinin durumunu veya nihai sonucunu gösterir ve vaka çözümünü anlamak, istisnaları belirlemek için kritik bir özniteliktir.

Süreç analizinde, bu öznitelik yalnızca reddedilen veya iptal edilen değişiklikleri analiz etmek gibi belirli sonuçlar için filtreleme yapmak amacıyla kullanılır. 'Değişiklik Talebi Reddedilme Oranı' gibi KPI'ları destekler ve değişiklik yönetimi sürecinin genel sağlığını ve verimliliğini anlamak için esastır.

Neden önemli

Bir değişiklik talebinin sonucunu tanımlar, ret oranları, tamamlama oranları ve açık ile kapalı vakaların dağılımı üzerine kritik analizler yapılmasını sağlar.

Nereden alınır

Bu, Ivanti Cherwell'deki Değişiklik Talebi iş nesnesindeki 'Durum' alanına karşılık gelir.

Örnekler
OnaylandıReddedildiKapalıİptal EdildiOnay Bekliyor
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 Sahibine benzer şekilde, bu da süreç boyunca değişebilir ve hizmet masasından bir ağ mühendisliği ekibine gibi ekipler arasında sorumluluk transferini gösterir.

Bu öznitelik, ekipler arası devir teslimleri analiz etmek ve belirli ekiplerden kaynaklanan sistemik gecikmeleri belirlemek için çok önemlidir. Hangi ekiplerin aşırı yüklendiği veya iletişim kopukluklarının nerede meydana geldiği sorularını yanıtlamaya yardımcı olur, 'Değişiklik Devir Teslimi ve Kaynak Kullanımı' analizini doğrudan destekler.

Neden önemli

Süreç darboğazlarını analiz etmek, ekip performansını ölçmek ve gruplar arası devir gecikmelerini anlamak için anahtar olan ekip düzeyindeki sorumluluğu belirler.

Nereden alınır

Bu bilgi genellikle Değişiklik Talebi nesnesindeki 'Sorumlu Ekip' veya benzer bir grup atama alanında saklanır.

Örnekler
Ağ OperasyonlarıVeritabanı YönetimiUygulama Desteği
Değişiklik Risk Seviyesi
ChangeRiskLevel
Değişiklikle ilişkili değerlendirilmiş risk seviyesi, örneğin 'Düşük', 'Orta' veya 'Yüksek'.
Açıklama

Değişiklik Risk Seviyesi, değerlendirme aşamasında bir değişikliğin potansiyel olumsuz etkisini nicelleştirmek için atanan bir sınıflandırmadır. Bu değerlendirme genellikle onay sürecini ve gereken inceleme düzeyini etkiler.

Süreç madenciliğinde, bu öznitelik risk değerlendirmelerinin tutarlılığını analiz etmek ve riski süreç davranışı ile ilişkilendirmek için kullanılır. Örneğin, yüksek riskli değişikliklerin daha sıkı bir onay yolunu izleyip izlemediği veya daha uzun uygulama sürelerine sahip olup olmadığı kontrol edilebilir. Doğrudan 'Değişiklik Risk Değerlendirme Tutarlılığı' gösterge tablosunu destekler.

Neden önemli

Riskin süreç akışını, onay döngülerini ve başarı oranlarını nasıl etkilediğinin analiz edilmesini sağlayarak, yüksek riskli değişikliklerin uygun şekilde incelenmesini sağlamaya yardımcı olur.

Nereden alınır

Bu değer, Değişiklik Talebi nesnesindeki 'Risk Seviyesi' veya benzer bir alanda saklanır ve tipik olarak risk değerlendirme etkinliği sırasında doldurulur.

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

Değişiklik Sahibi, belirli bir aşamada değişiklik talebine atanan ve ondan sorumlu olan kişidir. Bu öznitelik, talep yaşam döngüsü boyunca ilerledikçe sık sık değişir ve bireyler arasında bir devir teslimi olduğunu gösterir.

Değişiklik Sahibini analiz etmek, kaynak iş yükünü anlamaya ve belirli bireylerle ilgili bottleneck'leri belirlemeye yardımcı olur. Ayrıca, önemli gecikme kaynağı olabilecek devir teslimlerini analiz etmek için de temeldir. Bu öznitelik, 'Değişiklik Devir Teslimi ve Kaynak Kullanımı' dashboard'ını destekler.

Neden önemli

Bireysel sorumluluğu izler, iş yükü dağılımının, devir teslim sıklığının ve kaynağa özgü bottleneck'lerin analizini sağlar.

Nereden alınır

Tipik olarak Değişiklik Talebi iş nesnesindeki 'Sahibi' veya 'Atanan' alanıdır.

Örnekler
Alice JohnsonBob Williams`Charlie Brown`
Değişiklik Türü
ChangeType
Değişikliğin sınıflandırması, örneğin 'Standart', 'Normal' veya 'Acil'.
Açıklama

Değişiklik Türü, değişiklik talebini niteliğine, aciliyetine ve etkisine göre kategorize eder. Yaygın türler arasında Standart (önceden onaylı, düşük riskli), Normal (tam değerlendirme ve onay gerektiren) ve Acil (acil uygulama gerektiren) bulunur.

Bu öznitelik, farklı kategorilerdeki süreç performansını karşılaştırmak için segmentli analize olanak tanır. Örneğin, acil değişikliklerin farklı, daha hızlı bir yolu izleyip izlemediğini veya standart değişikliklerin gerçekten minimum sürtünmeyle işlenip işlenmediğini belirlemeye yardımcı olabilir. 'Sorunlu Değişiklik Türü Performansı' gösterge tablosu için anahtardır.

Neden önemli

Süreci Değişiklik Türü'ne göre segmentlere ayırmak, performansı karşılaştırmak ve 'Acil' gibi belirli kategorilerin bottleneck'lere veya sapmalara neden olup olmadığını belirlemek için çok önemlidir.

Nereden alınır

Değişiklik Talebi iş nesnesinde 'Değişiklik Türü' veya 'Kategori' olarak adlandırılması muhtemel bir sınıflandırma alanına karşılık gelir.

Örnekler
StandartNormalAcil Durum
Hedef Tamamlama Tarihi
TargetCompletionDate
Değişiklik uygulamasının tamamlanması için planlanan veya üzerinde anlaşılan son tarih.
Açıklama

Hedef Tamamlama Tarihi, değişikliğin tamamen uygulanması ve doğrulanmasının beklendiği timestamp'tir. Bu tarih genellikle bir Hizmet Seviyesi Anlaşmasının (SLA) bir parçasıdır ve performans için birincil ölçüt olarak hizmet eder.

Bu öznitelik, zamanında uyumu ve teslim tarihlerine bağlılığı izlemek için esastır. 'Zamanında Değişiklik Tamamlama Oranı' ve 'Değişiklik SLA Uyum Oranı' KPI'larını hesaplamak için gerçek tamamlama tarihine göre karşılaştırılır. Hedeflerini kaçırma riski taşıyan değişiklikleri proaktif olarak belirlemeye yardımcı olur.

Neden önemli

Zamanında performansın ve SLA uyumluluğunun ölçümü için temel sağlar; bunlar süreç verimliliğinin ve güvenilirliğinin kritik göstergeleridir.

Nereden alınır

Bu, genellikle Değişiklik Talebi nesnesinde 'Hedef Tarih', 'Son Tarih' veya 'SLA Hedefi' olarak etiketlenmiş belirli bir tarih alanıdır.

Örnekler
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
Değişiklik 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 belirler. Bu, sürecin ilerleyen aşamalarında uygulamasından sorumlu olan Değişiklik Sahibinden farklı olabilir.

Değişiklik Başvurusunu yapanı analiz etmek, talep kalitesiyle ilgili kalıpları belirlemeye yardımcı olabilir. Örneğin, belirli kişilerin veya ekiplerin sıklıkla ret veya yeniden işleme yol açan eksik talepler gönderdiğini ortaya çıkarabilir. Bu içgörü, hedeflenen eğitim sağlamak ve başvuruların genel kalitesini iyileştirmek için kullanılabilir.

Neden önemli

Değişiklik taleplerinin kökenini takip etmeye yardımcı olur, birey veya ekip bazında gönderim kalitesi analizine ve eğitim fırsatlarının belirlenmesine olanak tanır.

Nereden alınır

Bu genellikle Değişiklik Talebi nesnesindeki 'Oluşturan' veya 'Talep Eden' alanıdır.

Örnekler
Susan MillerDavid ChenMaria Garcia
Değişiklik Önceliği
ChangePriority
Değişiklik talebinin öncelik seviyesi, aciliyetini ve iş etkisini gösterir.
Açıklama

Değişiklik Önceliği, bir değişikliğin aciliyetini ve etkisini birleştirerek belirlenen bir sınıflandırmadır. Ekiplerin işlerini önceliklendirmesine ve kaynakları etkin bir şekilde tahsis etmesine yardımcı olarak en kritik değişikliklerin ilk önce ele alınmasını sağlar.

Analizde, öncelik, 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 herhangi bir sapma, önceliklendirme veya yürütme sürecinde verimsizliklere veya darboğazlara işaret edebilir.

Neden önemli

Sürecin yüksek etkili değişiklikleri doğru şekilde önceliklendirip önceliklendirmediğini ve bu değişikliklerin gerçekten amaçlandığı gibi hızlandırılıp hızlandırılmadığını analiz etmeye yardımcı olur.

Nereden alınır

Tipik olarak Değişiklik Talebi nesnesinde 'Öncelik' adında bir alandır. Manuel olarak ayarlanabilir veya etki ve aciliyet alanlarından türetilebilir.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Etkilenen Hizmet
ServiceAffected
Değişiklikten etkilenen birincil iş hizmeti veya konfigürasyon öğesi (CI).
Açıklama

Bu öznitelik, değişiklik talebinin hedeflediği ana BT hizmetini, uygulamasını veya altyapı parçasını belirler. 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'sı için çok önemlidir, çünkü hangi hizmetlerin en sık değişiklik geçirdiğini ve hangilerinin yüksek ret oranları veya gecikmelerle ilişkili olduğunu belirlemeye yardımcı olur. Bu, hizmet sahiplerine istikrarı iyileştirmek ve teknik borcu yönetmek için değerli içgörüler sağlar.

Neden önemli

Değişiklikleri belirli iş hizmetlerine bağlar, hangi hizmetlerin en istikrarsız olduğunu veya en sorunlu değişiklikleri ürettiğini belirlemek için analiz yapılmasına olanak tanır.

Nereden alınır

Bu genellikle Konfigürasyon Yönetim Veritabanı'ndan (CMDB) bağlanır ve Değişiklik Talebi nesnesindeki 'Birincil CI' veya 'Hizmet' alanında saklanır.

Örnekler
E-posta Hizmeti (Exchange)ERP Sistemi (SAP)Çekirdek Ağ Anahtarı (CISCO-4500X)
Gerçek Tamamlama Tarihi
ActualCompletionDate
Değişikliğin fiilen uygulandığı ve tamamlandığı doğrulanan `timestamp`.
Açıklama

Gerçek Tamamlama Tarihi, değişiklik talebi için uygulama çalışmasının tamamlandığı anı işaretler. Bu, performansı ölçmek için planlanan son teslim tarihine göre karşılaştırılan önemli bir kilometre taşıdır.

Bu öznitelik, bir değişikliğin zamanında tamamlanıp tamamlanmadığını belirlemek için Hedef Tamamlama Tarihi ile birlikte kullanılır. 'Zamanında Değişiklik Tamamlama Oranı' gibi KPI'ları hesaplamak ve uygulama aşamasındaki gecikmelerin nedenlerini analiz etmek için temel bir girdidir.

Neden önemli

Gerçek tamamlama zamanını yakalar; bu, zamanında teslimat oranlarını hesaplamak ve gecikmelerin büyüklüğünü analiz etmek için gereklidir.

Nereden alınır

Bu tarih genellikle değişiklik talebi durumu 'Uygulandı' veya 'Tamamlandı' olarak taşındığında kaydedilir. Özel bir alan olabilir veya o durum değişikliğinin timestamp'inden çı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 faydalanacak olan iş birimi veya departman.
Açıklama

Bu öznitelik, değişiklik talebini 'Finans', 'Pazarlama' veya 'Operasyonlar' gibi kuruluşun belirli bir bölümüyle ilişkilendirir. Bu, aksi takdirde teknik bir sürece iş bağlamı sağlar.

İş Birimine göre analiz, değişiklik talebinin nerede ortaya çıktığına dair bir görünüm sağlar. Geri ödeme modellerinde, BT değişikliklerinin farklı iş fonksiyonları üzerindeki etkisini anlamada ve belirli birimlerin diğerlerinden daha karmaşık veya gecikmeli değişikliklere sahip olup olmadığını belirlemede yardımcı olabilir.

Neden önemli

Değişiklik talebini, etkisini ve performansını organizasyonel bir perspektiften analiz etmeyi sağlayan iş bağlamı sağlar.

Nereden alınır

Bu, Değişiklik Talebi nesnesindeki bir alan olabilir veya talep sahibinin kullanıcı profilinden miras alınmış olabilir.

Örnekler
Finansİnsan KaynaklarıSatış ve PazarlamaOperasyonlar
Onay Çevrim Süresi
ApprovalCycleTime
Bir değişikliğin onay için gönderildiği andan nihai onayı aldığı ana kadar hesaplanan süre.
Açıklama

Bu metrik, temel onay kilometre taşları arasında geçen süreyi ölçer. 'Değerlendirme İçin Gönderilen Değişiklik' event'i ile 'CAB Tarafından Onaylanan Değişiklik' event'i arasındaki zaman farkı bulunarak case düzeyinde hesaplanır.

Bu hesaplanan süre, 'Değişiklik Onay Döngü Süresi' dashboard'ının ve ilişkili KPI'nın temel metriğidir. Dağılımını analiz etmek, onay aşamasındaki bottleneck'leri belirlemeye yardımcı olur; bunlar belirli onaylayanlarla, ekiplerle veya değişiklik türleriyle ilgili olabilir.

Neden önemli

Onay aşamasının verimliliğini doğrudan ölçer, değişikliklerin uygulanması için yetkilendirilmesindeki gecikmeleri belirlemeye ve ortadan kaldırmaya yardımcı olur.

Nereden alınır

Veri ön işleme sırasında veya süreç madenciliği aracı içinde, belirli onayla ilgili aktivitelerin zaman damgaları arasındaki sürenin ölçülmesiyle hesaplanır.

Örnekler
2 gün 4 saat18 saat 30 dakika5 gün
Ret Nedeni
ChangeRejectionReason
Bir değişiklik talebinin neden reddedildiğini açıklayan metinsel bir açıklama veya kategori.
Açıklama

Bir değişiklik talebi reddedildiğinde, bu öznitelik onaylayıcı tarafından belirtilen nedeni yakalar. Bu, önceden tanımlanmış bir listeden bir seçim veya serbest metin açıklaması olabilir.

Bu bilgiler, 'Reddedilen Değişiklik Talebi Analizi' dashboard'u için hayati öneme sahiptir. Reddetme nedenlerini kategorize edip analiz ederek, kuruluşlar eksik bilgi, yetersiz risk değerlendirmesi veya iş çatışmaları gibi değişiklik gönderimlerindeki yaygın sorunları belirleyebilirler. Bu içgörüler, gelecekteki değişiklik taleplerinin kalitesini artırmak için kullanılabilir.

Neden önemli

Değişikliklerin neden başarısız olduğuna dair doğrudan içgörü sağlar, genel ret oranını azaltmak için başvuru ve değerlendirme sürecinde hedeflenen iyileştirmeleri mümkün kılar.

Nereden alınır

Bu data genellikle özel bir 'Reddetme Nedeni' alanında veya durum 'Reddedildi' olarak değiştirildiğinde doldurulan bir notlar alanında yakalanır.

Örnekler
Uygulama planında yetersiz detayRisk değerlendirmesi eksikDiğer planlanmış değişikliklerle çakışmalar
Uygulama Döngü Süresi
ImplementationCycleTime
Bir değişiklik uygulamasının başladığı andan tamamlandığı ana kadar hesaplanan süre.
Açıklama

Bu metrik, değişikliğin uygulama aşaması için geçen süreyi nicelleştirir. 'Değişiklik Uygulaması Başlatıldı' etkinliği ile 'Değişiklik Uygulandı' etkinliği arasındaki süre olarak hesaplanır.

Bu öznitelik, 'Ortalama Değişiklik Uygulama Süresi' KPI'sını hesaplamak için kullanılır ve 'Değişiklik Uygulama Akışı ve Gecikmeleri' dashboard'ını destekler. Planlama gecikmelerini yürütme gecikmelerinden ayırmaya yardımcı olur, ekiplerin iyileştirme çabalarını teknik uygulama çalışmasının kendisine odaklamasına olanak tanır.

Neden önemli

Gerçek uygulama aşamasının performansını izole eder, onay gecikmelerinden ayrı olarak teknik veya kaynak tabanlı bottleneck'leri belirlemeye yardımcı olur.

Nereden alınır

Süreç madenciliği aracında veya veri dönüşümü sırasında, uygulama başlangıç ve bitiş olay zaman damgaları arasındaki zaman farkı bulunarak hesaplanır.

Örnekler
4 saat 15 dakika1 gün 2 saat30 dakika
Zamanında Tamamlandı mı
IsOnTimeCompletion
Değişikliğin hedef tarihine kadar veya öncesinde tamamlandığı durumlarda doğru olan hesaplanmış bir bayrak.
Açıklama

Bu, 'ActualCompletionDate' ile 'TargetCompletionDate' karşılaştırılarak türetilen bir boolean özniteliğidir. Her değişiklik talebi için zamanında performansın net, ikili bir göstergesini sağlayarak analizi basitleştirir.

Bu bayrak, 'Zamanında Değişiklik Tamamlama Oranı' KPI'sını hesaplamak için temeldir. Dashboard'larda geciken değişiklikleri kolayca izole etmek ve analiz etmek için bir filtre olarak kullanılabilir, gecikmelerin ortak kök nedenlerini belirlemeye yardımcı olur.

Neden önemli

Teslim tarihlerini karşılama konusunda net bir başarı veya başarısızlık sonucu sağlayarak performans analizini basitleştirir, zamanında tamamlama KPI'larını doğrudan destekler.

Nereden alınır

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

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

Değişiklik Yönetimi Aktiviteleri

Bunlar, doğru Process Discovery ve performans ölçümü için Event Log'unuza kaydetmeniz gereken temel süreç adımları ve dönüm noktalarıdır.
7 Önerilen 7 İsteğe Bağlı
Aktivite Açıklama
CAB Tarafından Onaylanan Değişiklik
Değişiklik Danışma Kurulu (CAB) veya belirlenmiş yetkilinin değişikliğin ilerlemesi için onay verdiği önemli bir dönüm noktasıdır. Bu, değişiklik talebi durumu 'Onaylandı' olarak güncellendiğinde çıkarılır.
Neden önemli

Bu etkinlik, onay döngüsü süresini ölçmek için bitiş noktasıdır. Süreci engeli kaldırır, planlama ve uygulamanın başlamasına izin verir ve Değişiklik Onay Döngü Süresi KPI'sı için çok önemlidir.

Nereden alınır

Değişiklik Talebi nesnesinin denetim geçmişinden, özellikle 'Durum' alanının 'Onaylandı' olarak değiştiği timestamp yakalanarak çıkarılmıştır.

Yakala

Durumun 'Onaylandı'ya değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Kapatıldı
Bu etkinlik, değişiklik yönetimi sürecinin son, başarılı bitiş noktasıdır. Değişiklik talebi durumu 'Kapalı' olarak ayarlandığında yakalanır ve tüm işlerin tamamlandığını gösterir.
Neden önemli

Birincil başarı bitiş noktası olarak, bu aktivite başarıyla tamamlanmış değişikliklerin uçtan uca döngü süresini hesaplamak için gereklidir. Tüm süreç adımlarının tamamlandığını doğrular.

Nereden alınır

Bu, Değişiklik Talebi nesnesinin denetim geçmişindeki nihai durumun 'Kapalı'ya değişmesinin timestamp'inden çıkarılır.

Yakala

Nihai durumun 'Kapalı'ya değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Planlandı
Bu etkinlik, değişiklik için uygulama tarihinin ve saatinin resmi olarak onaylandığı ve kaydedildiği noktayı işaret eder. Durum 'Zamanlandı' olarak güncellendiğinde yakalanır.
Neden önemli

Bu, önemli bir taahhüt kilometre taşıdır. Değişikliği onaylanmış bir konseptten planlı bir eyleme geçirir ve uygulama için bir ön koşuldur.

Nereden alınır

Değişiklik Talebi nesnesinin geçmişinden, 'Durum' alanının 'Zamanlandı' olarak güncellendiği timestamp yakalanarak çıkarılmıştır.

Yakala

Durumun 'Zamanlandı'ya değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Talebi Oluşturuldu
Bu etkinlik, sistemde yeni bir değişiklik talebinin başlatılmasını işaret eder. Genellikle Değişiklik Talebi iş nesnesinde yeni bir kayıt oluşturulduğunda yakalanır ve tüm süreç için başlangıç noktasını belirler.
Neden önemli

Bu, sürecin birincil başlangıç event'idir. Bu etkinlikten diğerlerine kadar geçen sürenin analizi, toplam yaşam döngüsü süresini ortaya koyar ve ön uç gecikmelerini belirlemeye yardımcı olur.

Nereden alınır

Bu event, Değişiklik Talebi kaydının oluşturulma timestamp'inden yakalanır. Ivanti Cherwell'de bu, tipik olarak Değişiklik Talebi iş nesnesinin 'CreatedDateTime' alanında saklanır.

Yakala

Kayıt oluşturma zaman damgasından doğrudan yakalanır.

Event tipi explicit
Değişiklik Uygulandı
Bu kilometre taşı, değişiklik için teknik çalışmanın tamamlandığını gösterir. Değişiklik talebi durumu 'Uygulandı' veya doğrulama bekleyen benzer bir duruma güncellendiğinde yakalanır.
Neden önemli

Bu, kritik bir başarı kilometre taşı ve Zamanında Değişiklik Tamamlama Oranı ile Ortalama Değişiklik Uygulama Süresi KPI'ları için önemli bir girdidir. Yürütme aşamasının sonunu işaret eder.

Nereden alınır

Değişiklik Talebi nesnesinin denetim log'undan, durumun 'Uygulandı' veya 'Doğrulama Bekleniyor' olarak değiştiği timestamp kullanılarak çıkarılmıştır.

Yakala

Durumun 'Uygulandı'ya değişmesinden çıkarılmıştır.

Event tipi inferred
Etki ve Risk Değerlendirildi
Bu etkinlik, değişiklik talebi için risk ve etki analizinin tamamlandığını gösterir. Bu, tipik olarak değişiklik talebi durumunun 'Onay Bekleniyor' gibi bir onay hazır olma durumuna geçmesiyle çıkarılır.
Neden önemli

Bu etkinliği izlemek, değerlendirme aşamasının süresini ölçmeye yardımcı olur ve risk analizinin onaydan önce tutarlı bir şekilde yapılmasını sağlayarak Risk Değerlendirme Uyumluluk Oranı KPI'sını destekler.

Nereden alınır

Değişiklik Talebi nesnesinin geçmişinden çıkarılmıştır. Bu, 'Durum' alanının 'Değerlendirmede' durumundan 'CAB Onayı Bekleniyor' gibi bir duruma güncellendiği timestamp'te yakalanır.

Yakala

Durumun 'CAB Onayı Bekleniyor'a değişmesinden çıkarılmıştır.

Event tipi inferred
Uygulama Sonrası Değerlendirme Yapıldı
Bu etkinlik, tamamlanan değişikliğin başarısını değerlendirmek ve öğrenilen dersleri almak için resmi bir incelemenin yapıldığını gösterir. Genellikle durumun 'Uygulama Sonrası Değerlendirme'ye değişmesiyle çıkarılır.
Neden önemli

Bunu izlemek, değişiklikler üzerindeki geri bildirim döngüsünün kapanmasını sağlar. Sürekli iyileştirme için esastır ve Uygulama Sonrası Değerlendirme Oranı KPI'sını doğrudan destekler.

Nereden alınır

Değişiklik Talebi nesnesinin denetim geçmişinden, 'Durum'un 'Uygulama Sonrası Değerlendirme' gibi bir duruma geçtiği timestamp yakalanarak çıkarılmıştır.

Yakala

Durumun 'Uygulama Sonrası Değerlendirme'ye değişmesinden çıkarılmıştır.

Event tipi inferred
Değerlendirme İçin Gönderilen Değişiklik
Yeni oluşturulan bir değişiklik talebinin ilk değerlendirme için resmi başvurusunu temsil eder. Bu genellikle değişiklik talebinin durumu 'Yeni' veya 'Taslak' durumundan 'Değerlendirmede' gibi bir duruma geçtiğinde çıkarılır.
Neden önemli

Bu etkinlik, ilk data girişinden sonra resmi değişiklik sürecinin başlangıcını işaret eder. Oluşturma ve gönderim arasındaki süre, kullanıcı eğitim ihtiyaçlarını veya süreçteki sürtünmeyi gösterebilir.

Nereden alınır

Değişiklik Talebi nesnesinin denetim log'undan veya geçmişinden, 'Durum' alanının 'Değerlendirmede' veya 'Gönderildi' gibi bir değere değiştiği timestamp belirlenerek çıkarılmıştır.

Yakala

Durumun 'Yeni'den 'Değerlendirmede'ye değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Doğrulaması Yapıldı
Değişikliğin başarılı olduğunu ve herhangi bir olumsuz etkiye neden olmadığını doğrulamak için test ve doğrulama aşamasını temsil eder. Bu, durumun 'Doğrulama' veya 'Test Ediliyor'ya değişmesinden çıkarılır.
Neden önemli

Bu aktivitenin sıklığı ve süresinin analizi, kalite güvence adımlarının atlanmamasını sağlar. Değişikliğin neden olduğu olayları önlemek için kritik bir adımdır.

Nereden alınır

Değişiklik Talebi nesnesinde durum değişikliğinin zaman damgasından yakalanır; örneğin, 'Doğrulama' veya 'Kullanıcı Kabul Testi' durumuna geçiş gibi.

Yakala

Durumun 'Doğrulama'ya değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik İptal Edildi
Onaylanmış veya devam eden bir değişiklik talebinin tamamlanmadan önce geri çekildiği bir son durumu temsil eder. Bu `event`, durum 'İptal Edildi' olarak güncellendiğinde yakalanır.
Neden önemli

Bu, alternatif bir süreç 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, Değişiklik Talebi nesnesindeki 'Durum' alanının 'İptal Edildi' olarak güncellendiği timestamp yakalanarak çıkarılmıştır.

Yakala

Durumun 'İptal Edildi'ye değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Reddedildi
Bu etkinlik, onay aşamasında değişiklik talebini reddetme yönündeki nihai kararı temsil eder. Değişiklik talebi durumu 'Reddedildi' olarak ayarlandığında yakalanır.
Neden önemli

Bu kritik bir başarısızlık bitiş noktasıdır. Reddedilen değişiklikleri ve nedenlerini analiz etmek, ilk taleplerin kalitesini artırmaya yardımcı olur ve Değişiklik Talebi Ret Oranı KPI'sını destekler.

Nereden alınır

Denetim geçmişinde Değişiklik Talebi nesnesindeki 'Durum' alanının 'Reddedildi' olarak güncellendiği timestamp'ten çıkarılmıştır.

Yakala

Durumun 'Reddedildi'ye değişmesinden çıkarılmıştır.

Event tipi inferred
Değişiklik Uygulaması Başlatıldı
Değişikliğin teknik yürütmesinin başlangıcını temsil eder. Bu genellikle değişiklik talebi durumunun 'Devam Ediyor' veya 'Uygulanıyor'a taşınmasıyla çıkarılır.
Neden önemli

Bu etkinlik, uygulama penceresinin başlangıcını işaret eder. Bu etkinlikle 'Değişiklik Uygulandı' arasındaki süre, genel döngü süresinin temel bir bileşeni olan gerçek uygulama süresidir.

Nereden alınır

Değişiklik Talebi nesnesinin denetim geçmişinden çıkarılmıştır. 'Durum' alanının 'Devam Ediyor' veya 'Uygulanıyor' gibi bir değere güncellendiği timestamp'tir.

Yakala

Durumun 'Devam Ediyor'a değişmesinden çıkarılmıştır.

Event tipi inferred
Onay Bekleyen Değişiklik
Bu etkinlik, bir değişiklik talebinin resmi olarak Değişiklik Danışma Kurulu'ndan (CAB) veya başka bir onay makamından bir karar beklediği dönemi temsil eder. 'Onay Bekleniyor' veya 'CAB Bekleniyor' gibi bir durumdan çıkarılır.
Neden önemli

Bu kritik bir bekleme süresi etkinliğidir. Süresini analiz etmek, değişiklik yönetiminde yaygın bir gecikme kaynağı olan onay workflow'undaki bottleneck'leri 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 yakalanır.

Yakala

'Onay Bekliyor' durumuna girişle belirlenir.

Event tipi inferred
Uygulama Planı Geliştirildi
Görevin, kaynakların ve geri alma planlarının tanımlanması dahil olmak üzere değişiklik için ayrıntılı planlamanın tamamlandığını işaretler. Bu genellikle değişiklik 'Onaylandı'dan 'Zamanlandı'ya geçtiğinde çıkarılır.
Neden önemli

Bu etkinliğin süresi, değişiklik planlama aşamasının verimliliğini ortaya koyar. Buradaki gecikmeler, onay verildikten sonra bile genel değişiklik timeline'ını etkileyebilir.

Nereden alınır

Bu, 'Onaylandı'dan 'Zamanlandı'ya durum değişikliğinin timestamp'inden çıkarılabilir. Alternatif olarak, belirli planlama alanlarının doldurulmasına bağlı olabilir.

Yakala

Durumun 'Onaylandı'dan 'Zamanlandı'ya değişmesinden çıkarılmıştır.

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

Veri Çekim Kılavuzları

Verilerinizi Ivanti Cherwell'den Nasıl Alırsınız?