Değişim Yönetimi Veri Şablonunuz
Değişim Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Ivanti Cherwell'den veri çıkarma rehberliği
Değişiklik Yönetimi Öznitelikleri
| 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 Değişiklik Talebi Kimliği'ni kullanarak
Neden önemli
Bu, ilgili tüm
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,
Neden önemli
Bu öznitelik,
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
Nereden alınır
Tipik olarak Ivanti Cherwell'deki Değişiklik Talebi nesnesiyle ilişkili durum değişiklik
Ö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, 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 Bu,
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
Ö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
Neden önemli
Bireysel sorumluluğu izler, iş yükü dağılımının, devir teslim sıklığının ve kaynağa özgü
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
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 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
Ö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' Bu hesaplanan süre, 'Değişiklik Onay Döngü Süresi'
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
Ö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'
Neden önemli
Gerçek uygulama aşamasının performansını izole eder, onay gecikmelerinden ayrı olarak teknik veya kaynak tabanlı
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 Bu bayrak, 'Zamanında Değişiklik Tamamlama Oranı' KPI'sını hesaplamak için temeldir.
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.
Örnekler
truefalse
|
|||
Değişiklik Yönetimi Aktiviteleri
| 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
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
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
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ıç
Nereden alınır
Bu
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
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
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
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
Nereden alınır
Değişiklik Talebi nesnesinin denetim
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
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
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
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
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
Nereden alınır
Bu, 'Onaylandı'dan 'Zamanlandı'ya durum değişikliğinin
Yakala
Durumun 'Onaylandı'dan 'Zamanlandı'ya değişmesinden çıkarılmıştır.
Event tipi
inferred
|
|||