Değişiklik Yönetimi Veri Template'inuz
Değişiklik Yönetimi Veri Template'inuz
Bu, Değişiklik Yönetimi süreci için genel Process Mining Veri Şablonu'imuzdur. Daha özel rehberlik. için sisteme özel Template'lerimizi kullanın.
Belirli bir sistem seçin- Değişiklik yönetimi event lognüz için standartlaştırılmış bir yapı.
- Detaylı analiz için önerilen veri alanları ve süreç adımları.
- Çeşitli BT hizmet yönetimi sistemlerinde somut bir temel.
Değişiklik Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite Adı ActivityName | Değişiklik yönetimi sürecinde meydana gelen belirli bir iş olayının, görevin veya durum değişikliğinin adı. | ||
| Açıklama Aktivite Adı, değişiklik talebi süreç döngüsündeki 'Risk Değerlendirmesi Tamamlandı' veya 'Değişiklik Onaylandı' gibi belirli bir adımı veya dönüm noktasını açıklar. Her aktivite, bir eylemin yapıldığı, bir kararın verildiği veya sürecin yeni bir aşamaya geçtiği bir zaman noktasını temsil eder. Bu nitelik, süreç haritasını oluşturmak için büyük önem taşır. Süreç grafiğindeki düğümleri tanımlayarak analistlerin olay dizisini görselleştirmesini, yaygın yolları belirlemesini ve standart prosedürden sapmaları tespit etmesini sunar. Aktiviteleri analiz etmek, değişiklik sürecinin farklı aşamaları arasındaki darboğazları, yeniden işleme döngülerini ve verimsiz geçişleri ortaya çıkarmaya yardımcı olur. Neden Önemli?dir? Süreçteki adımları tanımlar, süreç akışının görselleştirilmesini ve darboğazların, yeniden işleme ve sapmaların analizini sunar. Nereden Alınır?? Genellikle değişiklik talebiyle ilişkili bir etkinlik log'unda, olay geçmişinde veya denetim izi tablosunda bulunur. Örnekler::::::: Değişiklik İnceleme İçin GönderildiDeğişiklik OnaylandıUygulama BaşlatıldıDeğişiklik Kapatıldı | |||
| Değişiklik Talebi Kimliği ChangeRequestId | Bir değişiklik talebi için benzersiz sistem tarafından oluşturulan tanımlayıcı. Bu, ilgili tüm etkinlikleri ve olayları gruplandıran birincil vaka (case) tanımlayıcısı olarak olarak kullanılır. | ||
| Açıklama Değişiklik Talebi Kimliği, her değişiklik talebi oluşturulduğunda atanan benzersiz bir alfanümerik koddur. Tek bir değişiklik vakası için birincil anahtar görevi görür; başlatmadan kapanışa kadar ilgili tüm görevleri, onayları ve kayıtları birbirine bağlar. Process Mining'de bu öznitelik, her değişikliğin tüm sürecini yeniden yapılandırmak için gereklidir. Analistler, tüm olayları ortak bir Değişiklik Talebi Kimliği altında gruplandırarak süreç akışlarını görselleştirebilir, vaka sürelerini hesaplayabilir ve farklı değişiklik yaşam döngüleri arasındaki varyasyonları analiz edebilir. Bu, bireysel değişikliklerin sistem içinde nasıl ilerlediğine dair net bir görünüm sağlayan, tüm vaka düzeyindeki analizlerin temelini oluşturur. Neden Önemli?dir? Bu Kimlik, tek bir değişiklikle ilgili tüm olayları takip etmek ve ilişkilendirmek için büyük önem taşır, bu da onu süreç keşfi ve uyumluluk kontrolü için temel oluşturur. Nereden Alınır?? Genellikle bir değişiklik talebi işleminin başlığında veya birincil kaydında bulunur. Örnekler::::::: CHG0034501CRQ-10293789123ITSM-CHG-5501 | |||
| Olay Başlangıç Saati EventStartTime | Belirli bir etkinliğin veya olayın başladığı tam tarih ve saati gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Event Start Time, değişiklik talebinin süreç döngüsü içindeki bir etkinliğin başlangıcını işaretler. Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve etkinliklerin ve genel vakanın süresini hesaplamak için büyük önem taşır. Süreç analizinde bu öznitelik, etkinlikleri doğru bir şekilde sıralamak için kullanılır ve Event Log'un temelini oluşturur. Etkinlikler arası döngü süreleri, bekleme süreleri ve toplam vaka süresi gibi tüm zamanla ilgili metrikleri hesaplamak için gereklidir. Kuruluşlar bu zaman damgası (zaman damgası)'leri analiz ederek hangi adımların en çok zaman tükettiğini belirleyebilir ve süreç hızlandırma fırsatlarını tespit edebilir. Neden Önemli?dir? Bu zaman damgası (zaman damgası), olayları sıralamak, süreç akışını keşfetmek ve döngü süreleri ve bekleme süreleri gibi tüm performans metriklerini hesaplamak için gereklidir. Nereden Alınır?? Değişiklik talebi için event lognde veya denetim izinde bulunur. 'Oluşturma Tarihi', 'Başlangıç Tarihi' veya sadece 'Zaman Damgası' olarak adlandırılabilir. Örnekler::::::: 2023-10-26T09:00:00Z2023-10-26T14:22:10Z2023-10-27T11:05:00Z | |||
| Kaynak Sistem SourceSystem | Değişiklik yönetimi verilerinin çıkarıldığı sistemin veya uygulamanın adı. | ||
| Açıklama Kaynak Sistem özniteliği, olay verisinin kökenini tanımlar. Birden fazla ITSM aracı veya entegre sistemin olduğu ortamlarda, bu alan farklı kaynaklardan gelen verileri ayırt etmeye yardımcı olarak veri bütünlüğünü ve doğru bağlamı sunar. Birincil süreç akışı analizinde her zaman kullanılmasa da, veri doğrulama ve yönetişimi için büyük önem taşır. Veri alım sorunlarını gidermeye yardımcı olur ve farklı sistemler veya iş birimleri ayrı platformlar kullanıyorsa, süreç performansını karşılaştırmak için kullanılabilir. Örneğin, bir şirket altyapı değişiklikleri için bir sistem, uygulama değişiklikleri için başka bir sistem kullanabilir. Neden Önemli?dir? Veri doğrulama, sorun giderme ve birden fazla sistemi kapsayan süreçleri analiz etmek için kritik olan verinin kaynağını tanımlar. Nereden Alınır?? Bu bilgi, kaynak veride bir alan olarak saklanabilir veya veri çıkarma ve dönüştürme (ETL) süreci sırasında eklenebilir. Örnekler::::::: ServiceNowJira Service ManagementBMC Helix ITSMIvanti Cherwell | |||
| Son Veri Güncellemesi LastDataUpdate | Bu kayda ait verilerin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Son Veri Güncelleme zaman damgası (zaman damgası)'i, belirli bir kaydın kaynak sistemden en son ne zaman çekildiğini belirtir. Bu, veri hattını yönetmek ve analizin güncelliğini güçlüak için gerekli bir meta veri özniteliğidir. Bu öznitelik, veri mühendislerinin ve analistlerin üzerinde çalıştıkları verinin zamanında olup olmadığını anlamalarına yardımcı olur. Veri çıkarma sürecinin sağlığını izlemek ve Process Mining analizinin güncel ve alakalı bilgilere dayandığını doğrulamak için kullanılır. Genellikle süreç analizi için kullanılmaz, ancak veri yönetişimi ve güvenilirliği için büyük önem taşır. Neden Önemli?dir? Veri tazeliğini sunar ve süreç analizinin güvenilirliği için büyük önem taşıyan veri hattının sağlığını takip etmenizi sunar. Nereden Alınır?? Bu zaman damgası (zaman damgası) genellikle veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında oluşturulur ve eklenir. Örnekler::::::: 2024-05-20T12:00:00Z2024-05-20T12:05:10Z2024-05-20T12:10:00Z | |||
| Değişiklik Durumu ChangeStatus | Değişiklik talebinin süreç döngüsü içindeki mevcut veya nihai durumu; örneğin 'Devam Ediyor', 'Onay Bekliyor' veya 'Kapalı'. | ||
| Açıklama Değişiklik Durumu, bir değişiklik talebinin belirli bir zamandaki aşamasını veya nihai sonucunu gösterir. Durumlar genellikle süreçteki önemli kilometre taşlarına karşılık gelir ve ilerlemeye dair üst düzey bir görünüm sunar. Bu öznitelik iki şekilde kullanılabilir. Bir anlık görüntü özniteliği olarak, tüm açık değişikliklerin mevcut durumunu gösterir ve bu, iş akışı ile birikmiş işleri takip eden operasyonel Dashboard'lar için kullanışlıdır. Bir olay özniteliği olarak, durum değişikliğinin kendisi bir etkinlik olarak kabul edilebilir ve ayrıntılı etkinlik verisi azsa Event Log'u zenginleştirmeye yardımcı olur. Durum geçişlerini analiz etmek, süreç döngüsünü anlamaya ve değişikliklerin nerede takılıp kaldığını belirlemeye yardımcı olur. Neden Önemli?dir? Değişikliğin ilerlemesinin anlık bir görüntüsünü sunar, darboğazların, verimliliğin ve değişiklik birikiminin mevcut durumunun analiz edilmesini sunar. Nereden Alınır?? Değişiklik talebinin başlık kaydında bulunur. Tarihsel durum değişiklikleri bir denetim günlüğünde bulunabilir. Örnekler::::::: YeniDeğerlendirYetkilendirKapalıReddedildi | |||
| Değişiklik Türü ChangeType | Değişikliğin Standard, Normal veya Acil durum gibi sınıflandırması, genellikle izleyeceği süreç yolunu belirler. | ||
| Açıklama Değişiklik Türü, bir değişiklik talebinin gerektirdiği Workflow'u, onay adımlarını ve aciliyetini belirleyen önemli bir sınıflandırmadır. Standart değişiklikler genellikle önceden onaylanmış ve düşük risklidir, Normal değişiklikler tam değerlendirme ve onay sürecini izler ve Acil durum değişiklikleri, acil bir iş ihtiyacı nedeniyle hızlandırılmış işlem gerektirir. Değişiklik Türüne göre süreci analiz etmek, değişiklik yönetimi analizinde temel bir faaliyettir. Farklı değişiklik Workflow'larının performansını ve uyumluluğunu karşılaştırmaya sunar. Örneğin, analistler Acil durum değişikliklerinin gerçekten daha hızlı bir yolu izleyip izlemediğini veya Standart değişikliklerin basitleştirilmiş, önceden onaylanmış akışlarına uyup uymadığını doğrulayabilir. Bu segmentasyon, süreç varyasyonlarını anlamak ve doğru düzeyde yönetişimin uygulandığından emin olmak için temel rol oynar. Neden Önemli?dir? Bu öznitelik, analizleri bölümlere ayırmak için gereklidir, çünkü farklı değişiklik türleri belirgin, önceden tanımlanmış süreç akışlarına, onay gereksinimlerine ve performans beklentilerine sahiptir. Nereden Alınır?? Değişiklik talebinin ana kaydında veya başlık verilerinde bulunur. Örnekler::::::: StandartNormalAcil DurumBüyük | |||
| Etkilenen Hizmet AffectedBusinessService | Değişiklikten etkilenen birincil iş hizmeti veya Konfigürasyon Öğesi (CI). | ||
| Açıklama Etkilenen İş Hizmeti, değişikliğin değiştireceği 'E-posta Hizmeti' veya 'Online Bankacılık' gibi temel iş yeteneğini tanımlar. Bu aynı zamanda bir iş hizmetini destekleyen bir sunucu veya uygulama gibi belirli bir teknik Yapılandırma Öğesi (CI) de olabilir. Bu nitelik, değişiklik yönetimi sürecine kritik iş bağlamı sunar. Analizin sadece BT aktivitesi yerine iş etkisi açısından çerçevelenmesine sunar. Örneğin, analistler hangi hizmetlerin en sık değiştiğini belirleyebilir, bu da istikrarsızlık veya yüksek bir inovasyon oranını gösterebilir. Ayrıca, teknik değişiklikleri destekledikleri iş fonksiyonlarına bağlayarak değişiklikleri önceliklendirmeye ve riski değerlendirmeye yardımcı olur. Neden Önemli?dir? BT değişikliklerini iş bağlamına bağlar, hangi iş hizmetlerinin değişiklik aktivitesinden ve ilişkili risklerden en çok etkilendiğinin analiz edilmesini sunar. Nereden Alınır?? Değişiklik talebinin ana kaydında bulunur, genellikle bir Yapılandırma Yönetimi Veritabanından (CMDB) bağlantılıdır. Örnekler::::::: Online BankacılıkE-posta Servisi`SAP ERP`SRV_WebApp01 | |||
| Olay Bitiş Zamanı EventEndTime | Belirli bir etkinliğin veya olayın tamamlandığı tam tarih ve saati gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Event End Time, bir etkinliğin sonucunu işaret eder. Event Start Time ile eşleştirildiğinde, değişiklik süreç döngüsündeki her adım için işlem süresinin hassas bir şekilde hesaplanmasını sunar. Bu öznitelik, performans analizi için büyük önem taşır. Başlangıç ve bitiş zamanları arasındaki fark, bir etkinliğin 'işlem süresini' ortaya çıkarırken, bir etkinliğin bitişi ile bir sonraki etkinliğin başlangıcı arasındaki süre 'bekleme süresini' gösterir. Bu ayrım, gecikmelerin uzun görevlerden mi yoksa görevler arasındaki boşta kalma sürelerinden mi kaynaklandığını belirlemek ve hedeflenen iyileştirme çabalarına rehberlik. etmek için temel rol oynar. Neden Önemli?dir? Değer katan işlem süresi ile değer katmayan bekleme süresi arasında ayrım yapmaya yardımcı olan hassas aktivite sürelerinin hesaplanmasını sunar. Nereden Alınır?? Genellikle aktivite günlüğü veya denetim izi tablolarında bulunur. Mevcut değilse, bazen sonraki olayın başlangıç zamanından türetilebilir. Örnekler::::::: 2023-10-26T09:15:30Z2023-10-26T17:00:00Z2023-10-27T11:55:12Z | |||
| Öncelik ChangePriority | Değişiklik talebine atanan öncelik seviyesi, genellikle etkisi ve aciliyetinden türetilir. | ||
| Açıklama Değişiklik Önceliği, bir değişiklik talebinin göreceli önemini belirlemek için kullanılan bir sınıflandırmadır. Ekiplerin kaynakları etkin bir şekilde planlamasına ve tahsis etmesine yardımcı olarak, en kritik değişikliklerin önce ele alınmasını sunar. Öncelik genellikle değişikliğin iş üzerindeki potansiyel etkisi ve uygulama aciliyeti temelinde hesaplanır. Process Mining'de öncelik, filtreleme ve karşılaştırma için güçlü bir boyuttur. Analistler, yüksek öncelikli değişikliklerin düşük öncelikli olanlardan daha hızlı işlenip işlenmediğini araştırabilirler. Herhangi bir tutarsızlık, kaynak tahsisi, kritik değişiklikler için onay darboğazları veya önceliklendirme kurallarına tutarsız uyum ile ilgili sorunları gösterebilir. Neden Önemli?dir? Yüksek öncelikli değişikliklerin düşük öncelikli olanlardan daha hızlı işlenip işlenmediğini analiz etmeye sunar, bu da önceliklendirme politikalarının etkinliğini doğrular. Nereden Alınır?? Değişiklik talebinin ana kaydında veya başlık verilerinde bulunur. Örnekler::::::: 1 - Kritik2 - Yüksek3 - Orta4 - Düşük | |||
| Risk Seviyesi RiskLevel | Değişikliğin uygulanmasıyla ilişkili potansiyel riskin 'Düşük', 'Orta' veya 'Yüksek' gibi bir değerlendirmesi. | ||
| Açıklama Risk Seviyesi, bir değişikliğin başarısız olma olasılığını ve potansiyel olumsuz etkisini temsil eder. Bu değerlendirme, gerekli test, inceleme ve onay seviyesini etkiler. Yüksek riskli değişiklikler, düşük riskli değişikliklere kıyasla genellikle daha titiz bir inceleme süreci gerektirir. Bu öznitelik, risk tabanlı süreç analizini sunar. Yüksek riskli değişikliklerin, Değişiklik Danışma Kurulu (CAB) tarafından yapılan inceleme gibi uygun düzeyde inceleme alıp almadığını kontrol etmek için kullanılabilir. Ayrıca, risk seviyesini sonuçlarla ilişkilendirmeye de sunar; örneğin, yüksek riskli değişikliklerin daha yüksek bir başarısızlık oranına sahip olup olmadığını belirlemek, bu da risk değerlendirmesi veya azaltma sürecinin iyileştirilmesi gerektiğini düşündürebilir. Neden Önemli?dir? Süreç kontrolleri ve onay iş akışlarının, değişikliğin değerlendirilen riskiyle doğru bir şekilde uyumlu olup olmadığının analiz edilmesini sunar. Nereden Alınır?? Bir değişiklik talebinin başlık verilerinde veya risk değerlendirme detaylarında bulunur. Örnekler::::::: YüksekOrtaDüşükÇok Yüksek | |||
| Sorumlu Ekip ResponsibleTeam | Değişiklik talebinden veya süreç içindeki belirli bir etkinlikten sorumlu ekip, atama grubu veya kuyruk. | ||
| Açıklama Sorumlu Ekip, belirli bir aşamada değişiklik üzerinde çalışmak üzere atanan kişi grubunu tanımlar. Bu, bir değerlendirme ekibi, CAB gibi bir onay kurulu veya uygulamayı gerçekleştiren teknik ekip olabilir. Bu öznitelik, kaynak tahsisi, iş yükü dağıtımı ve ekipler arası geçişleri analiz etmek için gereklidir. Bir sosyal ağ analizi, farklı gruplar arasındaki iletişim kalıplarını ve darboğazları ortaya çıkarabilir. Her ekiple geçirilen süreyi ölçerek, kuruluşlar hangi grupların aşırı yüklendiğini veya sorumluluk devirleri sırasında gecikmelerin nerede sık sık meydana geldiğini belirleyebilir. Neden Önemli?dir? Bu, ekipler arası aktarımları analiz etmek, kaynak darboğazlarını belirlemek ve kuruluş genelindeki iş yükü dağılımını anlamak için büyük önem taşır. Nereden Alınır?? Değişiklik talebi kaydında veya aktivite seviyesindeki detaylarda bulunur. 'Atama Grubu' veya 'Ekip' olarak adlandırılabilir. Örnekler::::::: CABAğ MühendisliğiVeritabanı YöneticileriUygulama Destek Seviyesi 2 | |||
| Sorumlu Kullanıcı ResponsibleUser | Değişiklik talebinden veya belirli bir görevi tamamlamaktan sorumlu bireysel kullanıcı. | ||
| Açıklama Sorumlu Kullanıcı, bir değişiklik talebine veya etkinliğe atanan belirli kişidir. Bu öznitelik, ekip düzeyindeki atamadan daha ayrıntılı bir iş yükü ve sorumluluk görünümü sunar. Verileri kullanıcı düzeyinde analiz etmek, performans yönetiminde ve eğitim fırsatlarını belirlemede yardımcı olabilir. Süreç uzmanı olan veya belirli görevlerde zorlanan kişileri öne çıkarabilir. Ayrıca, belirli kişiler tarafından ele alınan değişikliklerin reddedilme veya düzeltme gerektirme olasılığının daha yüksek olup olmadığını görmek için yeniden işleme analizinde de kullanılır. Ancak, bu bilgiyi yapıcı bir şekilde ve cezalandırıcı önlemler için değil, dikkatlice kullanmak gerekir. Neden Önemli?dir? Bireysel iş yükü ve performans analizini sağlayan ayrıntılı bir görünüm sunar, ekipler içindeki uzmanları ve potansiyel eğitim ihtiyaçlarını belirlemeye yardımcı olur. Nereden Alınır?? Genellikle değişiklik talebi kaydında veya görev düzeyindeki ayrıntılarda bulunur, sıklıkla 'Atanan' veya 'Atandığı Kişi' olarak etiketlenir. Örnekler::::::: Can Demirjane.doeServiceAccountAtanmamış | |||
| Aciliyet ChangeUrgency | Değişikliğin aciliyeti, iş perspektifinden uygulamasının zaman hassasiyetini yansıtır. | ||
| Açıklama Değişiklik Aciliyeti, bir değişikliğin iş gereksinimlerini karşılamak için ne kadar hızlı uygulanması gerektiğini gösterir. Değişikliğin potansiyel etkisinden ayrı olarak, zaman kritikliğini yansıtır. Bir pazarlama kampanyası başlamadan önce küçük bir sorunu düzeltmek gibi, etkisi düşük ama aciliyeti yüksek bir değişiklik olabilir. Aciliyet, önceliği hesaplamada önemli bir bileşendir ve değişiklik yönetimi sürecinin zamanında olup olmadığını analiz etmek için kullanılır. Analistler, yüksek aciliyetli değişikliklerin gerçekten daha hızlı işlenip işlenmediğini araştırabilirler. Farklı aciliyet seviyelerindeki döngü sürelerini karşılaştırmak, sürecin iş ihtiyaçlarına duyarlı olup olmadığını veya tüm değişikliklerin zaman hassasiyetine bakılmaksızın aynı hızda işlenip işlenmediğini ortaya çıkarabilir. Neden Önemli?dir? Farklı aciliyet seviyelerindeki döngü sürelerini karşılaştırarak sürecin zamana duyarlı iş ihtiyaçlarına yanıt verme hızının analiz edilmesini sunar. Nereden Alınır?? Değişiklik talebinin ana kaydında veya başlık verilerinde bulunur. Örnekler::::::: 1-Kritik2-Yüksek3-Orta4-Düşük | |||
| Değişiklik Nedeni ChangeReason | Değişikliği önerme gerekçesi veya iş nedeni, neden gerekli olduğunu açıklar. | ||
| Açıklama Değişiklik Nedeni, değişiklik talebinin ardındaki iş gerekçesini özetleyen metinsel bir açıklamadır. 'Neden yapıyoruz?' sorusuna yanıt vererek, 'Kritik güvenlik açığı için güvenlik yaması' veya 'Müşteri deneyimini iyileştirmek için yeni özellik' gibi bağlamlar sunar. Genellikle serbest metin alanı olsa da, bu öznitelik, metin madenciliği teknikleriyle kategorize edildiğinde veya analiz edildiğinde değerli niteliksel stratejik bilgiler sağlayabilir. İşin farklı bölümlerinden gelen değişiklik taleplerini anlamaya yardımcı olur. Örneğin, analiz, değişikliklerin büyük bir yüzdesinin hata düzeltmelerinden kaynaklandığını ortaya koyabilir, bu da yazılım kalitesiyle ilgili potansiyel sorunlara işaret ederken, başka bir dönemde stratejik projelerle ilgili yüksek sayıda değişiklik görülebilir. Neden Önemli?dir? Değişikliklerin neden başlatıldığına dair iş bağlamı sunar, kuruluş içindeki ana değişiklik etkenlerini analiz etmeye yardımcı olur. Nereden Alınır?? Genellikle değişiklik talebinin ilk gönderim formunda veya başlık ayrıntılarında bulunur. Örnekler::::::: Acil güvenlik yamasıDonanım süreç döngüsü yenilemesi4. çeyrek için yeni özellik uygulamasıÜretim olayı INC01, 2, 3, 45'i çöz | |||
| Etki ChangeImpact | Değişikliğin başarılı olması veya başarısız olması durumunda iş hizmetleri ve BT altyapısı üzerindeki değerlendirilmiş etkisi. | ||
| Açıklama Değişiklik Etkisi, bir değişikliğin iş operasyonları, hizmetler veya altyapı üzerindeki potansiyel etkisini ölçer. Değişikliğin genel önceliğini belirlemek için aciliyetle birlikte önemli bir girdidir. Örneğin, kritik bir müşteri odaklı hizmeti etkileyen bir değişikliğin etkisi yüksektir. Etkiye göre analiz yapmak, kritik hizmetleri etkileyen değişikliklerin uygun özenle yönetilmesini güçlüaya yardımcı olur. Yüksek etkili değişikliklerin her zaman belirli onay veya test aşamalarından geçip geçmediğini doğrulamak için uyumluluk kontrolünde kullanılabilir. Ayrıca, daha detaylı inceleme ve test nedeniyle yüksek etkili değişikliklerin uygulanmasının daha uzun sürdüğünü kontrol etmek gibi performans karşılaştırmalarına da sunar. Neden Önemli?dir? Yüksek iş etkisine sahip değişikliklerin, daha titiz inceleme ve test yollarını takip ettiğini doğrulamaya yardımcı olur, böylece uygun yönetişimi sunar. Nereden Alınır?? Değişiklik talebinin ana kaydında veya başlık verilerinde bulunur. Örnekler::::::: 1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized | |||
| Planlanan Tamamlama Tarihi PlannedCompletionDate | Değişiklik uygulamasının tamamlanması gereken planlanan veya hedef tarih. | ||
| Açıklama Planlanan Tamamlama Tarihi, değişiklik için belirlenen ve genellikle iş gereksinimleri veya Hizmet Seviyesi Anlaşmaları (SLA'lar) tarafından belirlenen son tarihtir. Değişiklik yönetimi sürecinin zamanında olup olmadığını ve performansını ölçmek için bir ölçüt görevi görür. Bu öznitelik, SLA performans analizi için gereklidir. Gerçek tamamlama tarihini planlanan tarihle karşılaştırarak, kuruluşlar önemli bir performans göstergesi olan Zamanında Tamamlama Oranını hesaplayabilir. Planlanan tarihlerini kaçıran değişiklikleri analiz etmek, onay darboğazları, kaynak kısıtlamaları veya gerçekçi olmayan planlama ile ilgili olsun, gecikmelerin temel nedenlerini belirlemeye yardımcı olabilir. Neden Önemli?dir? Bu, SLA uyumluluğunu ve zamanında teslimatı ölçmek için temel bir özniteliktir ve süreçteki gecikmelerin temel nedenlerini belirlemeye yardımcı olur. Nereden Alınır?? Genellikle değişiklik talebinin başlık verilerinde bulunur. Örnekler::::::: 2023-11-15T17:00:00Z2023-11-20T23:59:59Z2023-12-01T12:00:00Z | |||
| Sonuç Nedeni ChangeOutcomeReason | Reddedilme veya iptal nedeni gibi kapatılan bir değişikliğin nihai sonucunu açıklayan bir kod veya açıklama. | ||
| Açıklama Değişiklik Sonucu Nedeni, bir değişiklik talebinin neden o şekilde sonuçlandığına dair bağlam sunar. Başarılı değişiklikler için 'Başarılı' olabilir. Başarısız değişiklikler için 'Başarısız - Geri Alma Başlatıldı' olabilir. Reddedilen veya iptal edilen değişiklikler için 'Yetersiz gerekçe' veya 'Talep Eden Tarafından İptal Edildi' gibi gerekçeyi sunar. Bu öznitelik, başarısız veya reddedilen değişikliklerin kök neden analizinde büyük önem taşır. Kuruluşlar bu nedenleri kategorize edip analiz ederek ortak hata kalıplarını belirleyebilir. Örneğin, birçok değişiklik 'Eksik bilgi' nedeniyle reddedilirse, bu, değişiklik gönderme sürecini iyileştirme ihtiyacına işaret eder. Bu veri, Değişiklik Başarısızlık Oranı ve İlk Geçiş Onay Oranı gibi KPI'ları hesaplamaya ve anlamaya yardımcı olur. Neden Önemli?dir? Başarısız, reddedilmiş veya iptal edilmiş değişikliklerin kök neden analizi için kritik veriler sunar, gelecekteki değişiklik taleplerinin kalitesini artırmaya yardımcı olur. Nereden Alınır?? Bir değişiklik talebi kaydının kapatma detaylarında bulunur. 'Kapatma Kodu', 'Çözüm' veya 'Reddetme Nedeni' olarak adlandırılabilir. Örnekler::::::: BaşarılıBaşarısızReddedildi - Yetersiz GerekçeKullanıcı tarafından iptal edildiSorunlarla Başarılı | |||
Değişiklik Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Değişiklik Kapatıldı | Bu, değişiklik yönetimi sürecinin resmi başarılı tamamlanmasını işaretler. Bu olay, değişiklik biletinin durumu, tüm işin tamamlandığını gösteren nihai 'Kapalı' durumuna getirildiğinde yakalanır. | ||
| Neden Önemli?dir? Birincil başarılı bitiş olayı olarak, bu aktivite uçtan uca döngü süresini hesaplamak için gereklidir. Değişikliğin tamamen işlendiğini ve kabul edildiğini gösterir. Nereden Alınır?? Değişiklik kaydının son durum değişikliğinden 'Kapalı' veya 'Tamamlandı' gibi çözümlenmiş bir duruma geçişle yakalanır. Yakala Son durum değişikliğinin 'Kapalı'ya ait zaman damgası (zaman damgası)'ini kullanın. Event tipi inferred | |||
| Değişiklik Onaylandı | Değişikliğin gerekli tüm taraflarca resmi olarak uygulamaya konulmasının onaylandığı kritik bir dönüm noktası. Bu olay, genellikle bir durum değişikliğini tetikleyen son gerekli onayın verildiği zaman kaydedilir. | ||
| Neden Önemli?dir? Bu, onay verimliliğini ve ilk geçiş onay oranını ölçmek için önemli bir kilometre taşıdır. Planlama ve değerlendirme aşamasını, zamanlama ve uygulama aşamasından ayırır. Nereden Alınır?? Genellikle 'Onaylandı' veya benzer bir duruma geçişten çıkarılır. Ayrıca nihai onay kaydının zaman damgası (zaman damgası)'inden de yakalanabilir. Yakala Değişikliğin genel onay durumu 'Onaylandı' olarak ayarlandığında zaman damgası (zaman damgası)nı yakalayın. Event tipi inferred | |||
| Değişiklik Planlandı | Bu etkinlik, onaylanan değişikliğin tanımlı bir uygulama penceresi ile resmi olarak planlandığı noktayı işaretler. Bu, genellikle planlanan başlangıç ve bitiş tarihi alanları doldurulduğunda yakalanır. | ||
| Neden Önemli?dir? Bu kilometre taşı, planlama aşamasını yürütme aşamasından ayırır. Onay ile zamanlama arasındaki süreyi analiz etmek, birikmiş işleri veya kaynak tahsisi sorunlarını ortaya çıkarabilir. Nereden Alınır?? Planlanan Başlangıç Tarihi ve Planlanan Bitiş Tarihi alanlarının doldurulması veya güncellenmesinden ya da durumun 'Planlandı' olarak değişmesinden çıkarılır. Yakala Değişiklik kaydının durumu 'Planlandı' olduğunda veya planlanan tarih alanları ayarlandığında zaman damgası (zaman damgası)'i kullanın. Event tipi inferred | |||
| Değişiklik Reddedildi | Bir onaylayıcı tarafından bir değişiklik talebinin resmi olarak reddedilmesini temsil eder ve bu süreci durdurur. Bu, talep için son bir durumdur veya bir yeniden işleme döngüsünü tetikleyebilir. | ||
| Neden Önemli?dir? Redleri takip etmek, değişiklik başarısızlık oranını belirlemeye yardımcı olur.saplamak ve ret için ortak nedenleri belirlemek için büyük önem taşır. Değişiklik kalitesi, planlama veya gerekçe ile ilgili sorunları vurgular. Nereden Alınır?? Değişiklik kaydının geçmişindeki durum değişikliğinden 'Reddedildi' veya 'Reddedildi' gibi bir duruma geçişle yakalanır. Yakala Değişiklik kaydının durumunun 'Reddedildi' olarak güncellendiği zaman damgası (zaman damgası)nı belirleyin. Event tipi inferred | |||
| Değişiklik Talebi Oluşturuldu | Bu etkinlik, sistemde bir değişiklik talebi kaydının ilk oluşturulmasını işaretler. Değişiklik yönetimi sürecinin resmi başlangıcını temsil eder ve tipik olarak değişiklik kaydının oluşturulma zaman damgası (zaman damgası)'inden yakalanır. | ||
| Neden Önemli?dir? Birincil başlangıç olayı olarak, bu aktivite bir değişikliğin uçtan uca döngü süresini hesaplamak için gereklidir. Taleplerin sistemde ne kadar zaman geçirdiğini ölçmek için temel sunar. Nereden Alınır?? Bu olay, neredeyse her zaman birincil değişiklik talebi kaydının veya biletinin oluşturulma zaman damgası (zaman damgası)'inden yakalanır. Yakala Değişiklik talebi kaydının oluşturulma zaman damgası (zaman damgası)'ini kullanın. Event tipi explicit | |||
| Değişiklik Uygulandı | Değişiklikle ilgili çalışmanın tamamlandığını gösteren önemli bir dönüm noktası. Bu genellikle 'Uygulandı' veya 'Doğrulama Bekleniyor' gibi bir duruma geçişle yakalanır. | ||
| Neden Önemli?dir? Bu kilometre taşı, uygulama aşamasının sonunu işaretler ve gerçek uygulama süresini ölçmek için büyük önem taşır. Test ve inceleme gibi uygulama sonrası etkinlikler için bir tetikleyici görevi görür. Nereden Alınır?? Değişiklik kaydının geçmişindeki durum değişikliğinden, uygulamanın tamamlandığını gösteren bir duruma geçişle yakalanır. Yakala Değişiklik kaydının durumu 'Uygulandı' veya 'Tamamlandı' olarak güncellendiğinde zaman damgası (zaman damgası)'i kullanın. Event tipi inferred | |||
| Onay Bekleyen Değişiklik | Değişiklik talebinin ilk incelemeleri geçtiğini ve artık resmi olarak bir onaylayıcı veya kuruldan karar beklediğini gösterir. Bu aktivite genellikle iş akışındaki bir durum değişikliğinden, örneğin 'Onay Bekliyor' durumuna geçişle yakalanır. | ||
| Neden Önemli?dir? Bu durum, onay döngüsü sürelerini ölçmek ve karar verme sürecindeki darboğazları belirlemek için büyük önem taşır. Buradaki yüksek süreler genellikle verimsiz onay Workflow'larına veya müsait olmayan onaylayıcılara işaret eder. Nereden Alınır?? Değişiklik kaydının geçmişindeki durum değişikliğinden 'Onay Bekleniyor', 'CAB Bekleniyor' veya 'Yetkilendir' gibi bir duruma geçişle çıkarılır. Yakala Resmi bir onay bekleme süresinin başlangıcını gösteren durum değişikliklerini belirleyin. Event tipi inferred | |||
| Değişiklik İnceleme İçin Gönderildi | Yeni oluşturulan bir değişiklik talebinin ilk değerlendirme veya inceleme için resmi olarak gönderilmesini temsil eder. Bu genellikle değişikliğin durumu 'Taslak' veya 'Yeni' durumundan incelemeye hazır olduğunu gösteren bir duruma geçtiğinde çıkarılır. | ||
| Neden Önemli?dir? Bu etkinlik, resmi değerlendirme başlamadan önceki ilk veri toplama aşamasında harcanan zamanı belirlemeye yardımcı olur. Bir değişikliğin ilk inceleme aşaması için hazırlanmasındaki gecikmeleri vurgulayabilir. Nereden Alınır?? Genellikle değişiklik talebinin geçmiş log'undaki bir durum değişikliğinden çıkarılır; örneğin 'Yeni'den 'Değerlendiriliyor'a veya 'İncelemede'ye geçiş gibi. Yakala Taslak veya yeni durumdan inceleme durumuna geçişleri belirleyin. Event tipi inferred | |||
| Değişiklik İptal Edildi | Bir değişiklik talebinin uygulanmadan veya tamamlanmadan önce sonlandırılmasını temsil eder. Bu, bilet durumu 'İptal Edildi' veya 'Geri Çekildi' olarak ayarlandığında yakalanan alternatif bir son durumdur. | ||
| Neden Önemli?dir? Bu, boşa harcanan çabayı temsil eden son bir olaydır. İptallerin sıklığını ve zamanlamasını analiz etmek, süreç verimsizliklerini veya değişen iş önceliklerini belirlemeye yardımcı olur. Nereden Alınır?? Değişiklik kaydının durum değişikliğinden 'İptal Edildi' veya 'Geri Çekildi' gibi son bir duruma geçişle yakalanır. Yakala Durum değişikliğinin 'İptal Edildi'ye ait zaman damgası (zaman damgası)'ini kullanın. Event tipi inferred | |||
| Risk Değerlendirmesi Tamamlandı | Bu etkinlik, önerilen değişiklik için risk ve etki analizinin tamamlandığını gösterir. Genellikle riskle ilgili alanlar doldurulduğunda veya belirli bir değerlendirme görevi tamamlandı olarak işaretlendiğinde çıkarılır. | ||
| Neden Önemli?dir? Risk değerlendirmesi için harcanan zamanın analizi, değişiklik sürecinin erken aşamalarındaki darboğazları belirlemeye yardımcı olur. Değişikliklerin resmi onay için ne kadar hızlı hazırlandığını anlamak için büyük önem taşır. Nereden Alınır?? Durum güncellemelerinden, ilgili değerlendirme görevlerinin tamamlanmasından veya değişiklik kaydındaki belirli risk ve etki alanlarındaki güncellemelerden çıkarılır. Yakala Bir risk değerlendirme görevinin tamamlanmasını veya değerlendirme aşamasının bittiğini gösteren bir durum değişikliğini arayın. Event tipi inferred | |||
| Uygulama Başlatıldı | Onaylanan değişikliğin teknik uygulamasının başlangıcını işaretler. Bu genellikle 'Planlandı' durumundan 'Devam Ediyor' veya 'Uygulanıyor' durumuna geçişle yakalanır. | ||
| Neden Önemli?dir? Bu etkinlik, gerçek değişiklik penceresinin başlangıcına görünürlük sunar. Planlanan ile gerçek başlangıç zamanlarını karşılaştırmak, takvim uyumluluğunu analiz etmek için temel rol oynar. Nereden Alınır?? Değişiklik kaydının geçmişindeki durum değişikliğinden 'Devam Ediyor' veya 'Uygulanıyor' gibi aktif bir duruma geçişle çıkarılır. Yakala Durumun 'Devam Ediyor' olarak değiştiği zaman damgası (zaman damgası)nı belirleyin. Event tipi inferred | |||
| Uygulama Planı Kesinleştirildi | Değişiklik için uygulama, test ve geri alma planları dahil olmak üzere gerekli tüm planlamanın tamamlandığını gösterir. Bu genellikle onay sonrası bir durum değişikliğinden veya bir planlama görevinin tamamlanmasından çıkarılır. | ||
| Neden Önemli?dir? Bu etkinlik, ayrıntılı planlama aşamasının süresini ölçer. Buradaki gecikmeler, değişiklikleri zamanında planlama ve yürütme yeteneğini etkileyebilir. Nereden Alınır?? Genellikle planlamaya özgü görevlerin tamamlanmasından veya planlamanın tamamlandığını gösteren bir durum güncellemesinden çıkarılır. Yakala Planlama görevlerinin kapanışını veya 'Onaylandı' durumundan 'Planlandı' durumuna geçişi arayın. Event tipi inferred | |||
| Uygulama Sonrası İnceleme Yapıldı | Değişikliğin başarısını değerlendiren ve öğrenilen dersleri yakalayan resmi incelemenin tamamlandığını gösterir. Bu genellikle bir durum değişikliği veya bir inceleme görevinin kapatılmasıyla yakalanır. | ||
| Neden Önemli?dir? Bu etkinlik, sürekli süreç iyileştirmesi için büyük önem taşır. PIR'leri tamamlamak için geçen süreyi analiz etmek, geçmiş değişikliklerden öğrenmeye olan bağlılığı vurgulayabilir. Nereden Alınır?? Bir 'İnceleme' durumuna geçişten, bir PIR görevinin tamamlanmasından veya uygulama sonrası inceleme notlarının eklenmesinden çıkarılır. Yakala Uygulama Sonrası İnceleme görevinin kapatıldığı veya durumun 'İnceleme' durumundan çıktığı zaman damgası (zaman damgası)nı belirleyin. Event tipi inferred | |||
| Uygulama Sonrası Test Yapıldı | Değişikliğin başarılı olduğundan emin olmak için gerekli tüm test ve doğrulama faaliyetlerinin tamamlanmasını temsil eder. Bu, ayrı bir durum olabilir veya test görevlerinin kapatılmasından çıkarılabilir. | ||
| Neden Önemli?dir? Testin tamamlanmasını takip etmek, doğrulama aşamasının süresini ve etkinliğini ölçmeye yardımcı olur. Değişikliğin resmi olarak kapatılmasından önce temel bir adımdır. Nereden Alınır?? Genellikle ilgili test görevlerinin tamamlanmasından veya 'Doğrulama Tamamlandı' veya 'Test Tamamlandı' gibi bir duruma geçişten çıkarılır. Yakala Doğrulama görevlerinin kapanışını veya uygulama sonrası belirli bir durum güncellemesini arayın. Event tipi inferred | |||
Veri Çıkarma Kılavuzları
Veri çıkarma yöntemleri sisteme göre değişir. Detaylı talimatlar için,