Sorun yönetimi veri şablonunuz
Sorun yönetimi veri şablonunuz
- Ayrıntılı analiz için önerilen öznitelikler
- Olay günlüğüne kaydedilecek süreç aşamaları
- Veri çıkarma için teknik yönergeler
Sorun yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik
ActivityName
|
Problem kaydında gerçekleşen belirli işlem veya durum değişikliği. | ||
|
Açıklama
Bu öznitelik, problem yönetimi yaşam döngüsünde gerçekleşen olayın veya durum geçişinin adını kaydeder. Örnekler arasında Problem kaydedildi, Durum incelemeye alındı ve Kök neden belirlendi yer alır. Süreç akışını haritalamak ve problemi çözmek için izlenen adımların sırasını belirlemek açısından önemlidir. Process Mining’de bu etkinlikler süreç haritasındaki düğümleri oluşturur.
Neden önemli?
Süreç haritasındaki adımları tanımlar ve süreç varyantlarının analiz edilmesini sağlar.
Nereden alınır?
Jira değişiklik günlüğü (History) veya kayıt durumu geçişleri
Örnekler
Problem kaydı oluşturulduİnceleme başladıKök neden belirlendiGeçici çözüm güncellendiProblem kaydı kapatıldı
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin geldiği sistemin adı. | ||
|
Açıklama
Süreç verilerinin alındığı yazılım sistemini belirtir. Bu bağlamda değer her zaman Jira Service Management’tır. Bu öznitelik, özellikle birden fazla sistemin kullanıldığı ortamlarda veri kaynaklarını ayırt etmeye yarar. Ancak bu görünümde temel olarak verinin kaynağını gösteren sabit bir tanımlayıcı işlevi görür.
Neden önemli?
Özellikle diğer BT hizmet yönetimi verileriyle birleştirildiğinde, verinin kaynağı hakkında bağlam sağlar.
Nereden alınır?
Sabit kodlanmış değer veya sistem yapılandırması
Örnekler
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
Problem kaydı
ProblemKey
|
Jira Service Management’ta problem kaydına atanan benzersiz tanımlayıcı. | ||
|
Açıklama
Bu öznitelik, Process Mining analizinde merkezi vaka tanımlayıcısı olarak kullanılır. Yeni bir problem kaydı oluşturulduğunda Jira Service Management’ın ürettiği benzersiz anahtarı (ör. PM-1001) ifade eder. İlişkili tüm etkinlikleri, durum değişikliklerini ve güncellemeleri tek bir uçtan uca süreç örneğinde gruplandırmak için kullanılır. Bu özniteliği analiz ederek problemin ilk tespitinden incelemeye ve son kapanışa kadar tüm yaşam döngüsünü görselleştirebilirsiniz.
Neden önemli?
Süreç akışını yeniden oluşturmak ve belirli problem kayıtlarını izlemek için gereken temel anahtardır.
Nereden alınır?
Kayıt tablosu, Key veya Issue Key alanı
Örnekler
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin çıkarıldığı veya son yenilendiği zaman damgası. | ||
|
Açıklama
Veri setinin canlı Jira Service Management ortamıyla en son ne zaman eşitlendiğini gösterir. Böylece analistler verilerin ne kadar güncel olduğunu anlayabilir. Analizin sürecin en güncel durumunu yansıttığını doğrulamak ve olası veri gecikmelerini belirlemek için kullanılır.
Neden önemli?
Verilerin güncel kalmasını sağlar ve analiz sonuçlarına güven duyulmasına yardımcı olur.
Nereden alınır?
ETL zaman damgası
Örnekler
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
Zaman damgası
EventTimestamp
|
Etkinliğin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Bu öznitelik, bir etkinliğin gerçekleştiği kesin zamanı kaydeder. Olayları kronolojik sıraya koymak ve adımlar arasındaki süreleri hesaplamak için kullanılır. Doğru zaman damgaları, Problem kaydedildi ile Kök neden belirlendi arasındaki süre gibi çevrim sürelerini hesaplamak ve işlem hacmini zaman içinde analiz etmek için önemlidir.
Neden önemli?
Zamana dayalı tüm KPI’ların hesaplanmasını ve olayların doğru sıraya konmasını sağlar.
Nereden alınır?
Jira değişiklik günlüğü oluşturulma tarihi veya kayıt oluşturulma tarihi
Örnekler
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
Atanan destek grubu
SupportGroup
|
Sorunu incelemekle şu anda görevlendirilmiş teknik ekip veya grup. | ||
|
Açıklama
Olay gerçekleştiğinde sorun kaydından sorumlu olan ekibi belirtir. Jira Service Management’ta bu bilgi genellikle 'Component' alanıyla veya 'Support Group' gibi özel bir alanla eşleştirilir. Bu öznitelik, analistlerin sorunların ekipler arasında nasıl aktarıldığını ve en uzun süre nerede beklediğini görmesini sağlayan 'Destek grubu devir teslim darboğazları' Dashboardı için önemlidir.
Neden önemli?
Kuruluş içindeki işleyişi analiz etmek ve ekipler arası aksaklıkları belirlemek için gereklidir.
Nereden alınır?
Kayıttaki 'Component' alanı veya özel 'Support Group' alanı
Örnekler
Veritabanı yönetimiAğ operasyonlarıUygulama desteği, 2. düzey
|
|||
|
Kök neden kategorisi
RootCauseCategory
|
Sorunun altında yatan nedenin sınıflandırması. | ||
|
Açıklama
Soruna yol açan teknik veya süreç kaynaklı hatayı 'Yazılım hatası', 'İnsan hatası' ya da 'Donanım arızası' gibi kategorilere ayırır. Bu bilgi çoğunlukla Jira Service Management’ta özel bir alanda tutulur. Bu öznitelik, tekrarları önlemek amacıyla altyapı veya eğitime nerede yatırım yapılacağına ilişkin kararları destekleyen 'Kök neden kategorisi dağılımı' Dashboardında kullanılır.
Neden önemli?
Sistemik sorunları belirlemek ve önleyici tedbirlere yön vermek için önemlidir.
Nereden alınır?
Özel 'Root Cause' veya 'Root Cause Category' alanı
Örnekler
Yazılım hatasıYapılandırma hatasıKapasite sorunuTedarikçi sorunu
|
|||
|
Kullanıcı
UserKey
|
Etkinliği gerçekleştiren kullanıcının benzersiz kimliği veya adı. | ||
|
Açıklama
Belirli bir etkinliği gerçekleştirmekten sorumlu kişinin veya sistem hesabının kimliğini kaydeder. Bu kişi, kaydı güncelleyen 'Atanan' ya da durum değişikliğini yapan 'Yazar' olabilir. Bu veri, kaynak kullanımını analiz etmek, kullanıcılar arasındaki devir teslim darboğazlarını belirlemek ve sorun yönetimi sürecinde hesap verebilirliği sağlamak için kullanılır.
Neden önemli?
Devir teslimleri, görevlerin ayrılığını ve kaynak iş yükünü analiz etmek için önemlidir.
Nereden alınır?
Jira değişiklik günlüğündeki 'author' alanı veya kayıttaki 'assignee' alanı
Örnekler
j.smithsystem_automationm.doe
|
|||
|
Öncelik
Priority
|
Sorun kaydına atanan önem düzeyi. | ||
|
Açıklama
Sorunun aciliyetini ve etkisini gösterir; değerler genellikle 'Düşük' ile 'Kritik' arasında değişir. Bu alan, analizi gruplandırmak ve yüksek öncelikli sorunların SLA hedefleri içinde çözüldüğünü doğrulamak için kullanılır. Bu özniteliğin analizi, kritik iş risklerine doğru önceliğin verilip verilmediğini 'SLA uyumluluğu ve hedef eğilimleri' Dashboardında doğrulamaya yardımcı olur.
Neden önemli?
Süreç performansını iş açısından önem düzeyine göre gruplandırmayı sağlar.
Nereden alınır?
Kayıttaki 'Priority' alanı
Örnekler
En yüksekYüksekOrtaDüşük
|
|||
|
Sorun özeti
ProblemSummary
|
Sorun kaydının kısa açıklaması veya başlığı. | ||
|
Açıklama
Sorun kaydının kısa özetini içerir. Metin ağırlıklı olsa da analistlere Process Mining aracında tek tek vakaları incelerken bağlam sağlar. Kaydedilen sorun türlerini anahtar kelimelerle aramaya ve niteliksel olarak analiz etmeye imkan verir.
Neden önemli?
Vaka kimliğine okunabilir bir bağlam sağlar.
Nereden alınır?
Kayıttaki 'Summary' alanı
Örnekler
AB bölgesinde veritabanı bağlantısı zaman aşımına uğradıE-posta hizmetinde gecikme artışıSipariş işleme kuyruğu takıldı
|
|||
|
Bağlantılı değişiklik talebi
LinkedChangeRequest
|
Bu sorunla bağlantılı değişiklik talebinin kimliği. | ||
|
Açıklama
Kalıcı çözümü uygulamak için oluşturulan Değişiklik Talebinin (RFC) kimliğini saklar. Bu bağlantı, 'Değişiklik talebi başlatma gecikmesi' Dashboardı için önemlidir. Sorun Yönetimi sürecini Değişiklik Yönetimi sürecine bağlayarak süreçler arası analize imkan verir.
Neden önemli?
İncelemeyi, Değişiklik Yönetimi sürecindeki düzeltme çalışmasına bağlar.
Nereden alınır?
Türü 'is fixed by' veya benzeri olan kayıt bağlantıları
Örnekler
CR-404CHG-1099CR-5512
|
|||
|
Bağlantılı olay sayısı
LinkedIncidentCount
|
Bu sorun kaydıyla bağlantılı olayların sayısı. | ||
|
Açıklama
Sorun kaydıyla ilişkili olay kayıtlarının sayısıdır. Bu öznitelik, sorunun kullanıcılar üzerindeki etkisini ölçer. En fazla destek kaydı oluşturan sorunlara öncelik vermek için 'Olay-sorun bağlantı derinliği' KPI’ında kullanılır.
Neden önemli?
Olay hacmine göre iş etkisini ölçer.
Nereden alınır?
'issuelinks' tablosunda türü 'Problem/Incident' olan bağlantıların sayısı
Örnekler
011550
|
|||
|
Bildirimi yapan
ReporterName
|
Sorun kaydını ilk oluşturan kullanıcı. | ||
|
Açıklama
Sorun kaydını oluşturan kişiyi belirtir. Bu kişi, kaydın atandığı kişiden farklıdır. Bildirim yapanları analiz etmek, sorunların nerede tespit edildiğini anlamaya yardımcı olur (ör. Hizmet Masası temsilcileri veya sistem yöneticileri). Bu bilgi, 'Proaktif ve reaktif' analizine bağlam kazandırır.
Neden önemli?
Sorun bildirimlerinin kaynağını belirler.
Nereden alınır?
Kayıttaki 'Reporter' alanı
Örnekler
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
Çözüm kodu
ResolutionCode
|
Sorunun nasıl çözüldüğünü belirten kod. | ||
|
Açıklama
Sorun kaydının nihai sonucunu 'Düzeltildi', 'Düzeltilmeyecek', 'Yinelenen' veya 'Yeniden oluşturulamıyor' gibi değerlerle belirtir. Başarıyla çözülen sorunları idari nedenlerle kapatılanlardan ayırmak için kullanılır. Böylece 'Kök nedene ulaşma süresi' gibi KPI hesaplamaları doğru yapılır.
Neden önemli?
Etkili çözümleri idari nedenlerle yapılan kapatmalardan ayırır.
Nereden alınır?
Kayıttaki 'Resolution' alanı
Örnekler
TamamlandıYapılmayacakYinelenenYeniden oluşturulamıyor
|
|||
|
Geçici çözüm mevcut
WorkaroundDetails
|
Sorun için bir geçici çözümün belgelenip belgelenmediğini gösterir. | ||
|
Açıklama
Geçici çözüm açıklamasının bulunup bulunmadığını veya yayımlanıp yayımlanmadığını kaydeder. Böylece 'Geçici çözüm yayımlama hızı' izlenebilir. Bu alanın analizi, kalıcı bir çözüm bulunmadan önce ekibin hizmeti ne kadar hızlı yeniden işler duruma getirebildiğini gösterir.
Neden önemli?
İş birimine sunulan geçici desteğin hızını ölçmek için önemlidir.
Nereden alınır?
Özel 'Workaround' alanı
Örnekler
Hizmeti yeniden başlatTarayıcı önbelleğini temizleBelirtilmedi
|
|||
|
Oluşturulma tarihi
CreatedDate
|
Sorun kaydının oluşturulduğu tarih. | ||
|
Açıklama
Sorunun sisteme ilk kaydedildiği zaman damgası. Etkinlik zamanlaması olay zaman damgasıyla izlenirken bu öznitelik genellikle üst düzey filtreleme için kullanılır (ör. '1. çeyrekte oluşturulan tüm sorunları göster'). Yaşlandırma analizinin başlangıç noktasını oluşturur.
Neden önemli?
Yaşlandırma ve gelen sorun hacmi analizleri için başlangıç tarihi.
Nereden alınır?
Kayıttaki 'Created' alanı
Örnekler
2023-01-012023-06-15
|
|||
|
SLA ihlal durumu
SlaBreachStatus
|
Sorun kaydında hizmet düzeyi anlaşmasının ihlal edilip edilmediğini gösterir. | ||
|
Açıklama
Çözüm süresinin üzerinde anlaşılan hedefi aşıp aşmadığını belirten bir doğru/yanlış veya durum alanıdır. 'SLA uyumluluğu ve hedef eğilimleri' Dashboardında kullanılır. Kuruluşu uyumluluk risklerine veya cezalara maruz bırakabilecek vakaları öne çıkarır.
Neden önemli?
Uyumluluğu ve performansı izlemek için önemlidir.
Nereden alınır?
Jira Service Management SLA alanı mantığı
Örnekler
Karşılandıİhlal edildiDuraklatıldı
|
|||
|
Tespit kaynağı
DetectionSource
|
Sorunun nasıl tespit edildiği (ör. proaktif, reaktif). | ||
|
Açıklama
Sorunun nasıl fark edildiğini gösterir. Yaygın değerler arasında 'Proaktif izleme', 'Hizmet Masası olayı' ve 'Tedarikçi bildirimi' bulunur. Bu öznitelik, sorun yönetimi sürecinin olgunluğunu ölçmek için 'Proaktif ve reaktif tespit' Dashboardında kullanılır.
Neden önemli?
Süreç olgunluğunu ve izleme sistemlerinin etkinliğini ölçer.
Nereden alınır?
Özel 'Source' veya 'Detection Source' alanı
Örnekler
Proaktif izlemeOlayın üst düzeye aktarılmasıTedarikçi bildirimi
|
|||
|
Uygulama sonrası inceleme yapıldı
ReviewStatus
|
Uygulama sonrası incelemenin (PIR) yapılıp yapılmadığını gösterir. | ||
|
Açıklama
Vakada 'Uygulama sonrası inceleme' etkinliğinin veya işaretinin bulunup bulunmadığını izler. 'Uygulama sonrası inceleme uyumluluğu' Dashboardı için gereklidir. Kuruluşun sürekli iyileştirme yönetişimi gerekliliklerine uyup uymadığını gösterir.
Neden önemli?
Kurumsal öğrenmeye yönelik uyumluluk metriği.
Nereden alınır?
Özel 'PIR Status' alanı veya 'PIR' etkinliğinin bulunması
Örnekler
TamamlandıBeklemedeGerekli değil
|
|||
|
Yeniden açıldı mı
IsReopened
|
Sorunun kapatıldıktan sonra yeniden açılıp açılmadığını belirten işaret. | ||
|
Açıklama
Sorun kaydı kapalı durumdan yeniden açık duruma geçtiğinde true değerini alan bir doğru/yanlış işaretidir. 'Sorunun yeniden açılma oranı analizi' için kullanılır. Yeniden açılma oranının yüksek olması, kalıcı çözümlerde kalite sorunlarına veya doğrulama adımlarının yetersizliğine işaret eder.
Neden önemli?
Çözümlerin etkinliğini gösteren bir kalite ölçütüdür.
Nereden alınır?
Durum geçişlerinden türetilir
Örnekler
truefalse
|
|||
Sorun yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm doğrulandı
|
Düzeltmenin problemi etkili biçimde çözdüğünün onaylanmasıdır. Durumun Resolved veya belirli bir Verified durumuna geçmesinden anlaşılır. | ||
|
Neden önemli?
Düzeltmenin işe yaradığını doğrulayan kalite kontrol aşamasıdır. Buradaki gecikmeler, test veya kullanıcı kabul süreçlerindeki darboğazlara işaret eder.
Nereden alınır?
Jira kayıt geçmişi: Durum Resolved veya Verified olarak değişti
Kaydedin
Durum alanındaki güncellemeleri karşılaştırın
Olay türü
inferred
|
|||
|
Destek ekibine atandı
|
Problem kaydının belirli bir teknik ekibe veya destek ekibine atanmasıdır. Bu işlem, Support Group özel alanındaki veya ekipler kullanılmıyorsa Assignee alanındaki değişiklikler üzerinden izlenir. | ||
|
Neden önemli?
Ekipler arasındaki devir teslimleri ve darboğazları analiz etmek için önemlidir. Devir teslim oranının yüksek olması, yönlendirmede verimsizlik olduğunu gösterebilir.
Nereden alınır?
Jira kayıt geçmişi: Support Group veya Assignee alanı değişti
Kaydedin
Atama alanı değiştiğinde günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Geçici çözüm güncellendi
|
Workaround metin alanının doldurulması veya güncellenmesidir. Bu olay, geçici bir düzeltmenin belgelendiğini gösterir. | ||
|
Neden önemli?
İş birimine ne kadar hızlı destek sağlandığını ölçer. Workaround Availability Lead Time KPI’ı için önemlidir.
Nereden alınır?
Jira kayıt geçmişi: Workaround alanı değişti (boş değil)
Kaydedin
Workaround alanı değiştirildiğinde günlüğe kaydedilir
Olay türü
explicit
|
|||
|
İnceleme başladı
|
Problem durumunun etkin inceleme durumuna (ör. Under Investigation veya In Progress) geçmesidir. Etkin çalışma aşamasının başlangıcını gösterir. | ||
|
Neden önemli?
İnceleme çevrim süresini başlatır. Bekleyen kayıtların bekleme süresiyle etkin analiz süresini birbirinden ayırmaya yardımcı olur.
Nereden alınır?
Jira kayıt geçmişi: Durum Under Investigation veya In Progress olarak değişti
Kaydedin
Durum alanındaki güncellemeleri karşılaştırın
Olay türü
inferred
|
|||
|
Kök neden belirlendi
|
Altta yatan nedenin resmi olarak kaydedildiği noktadır. Durumun Root Cause Identified olarak değişmesinden veya Root Cause alanının doldurulmasından anlaşılır. | ||
|
Neden önemli?
İnceleme aşamasını sona erdiren önemli bir dönüm noktasıdır. Mean Time to Root Cause Discovery metriğini hesaplamak için gereklidir.
Nereden alınır?
Jira kayıt geçmişi: Durum Root Cause Identified olarak değişti VEYA Root Cause alanı dolduruldu
Kaydedin
Durum alanındaki değişikliği karşılaştırın veya alanın doldurulup doldurulmadığını kontrol edin
Olay türü
inferred
|
|||
|
Olay problem kaydına bağlandı
|
İlişkili bir olay kaydının problem kaydına bağlanmasıdır. Bu işlem, kayıt bağlantıları tablosunda veya geçmişte yer alır. | ||
|
Neden önemli?
Problemin etkisini ve kapsamını belirler. Incident to Problem Linkage Depth KPI’ını hesaplamak ve iş etkisine göre önceliklendirme yapmak için gereklidir.
Nereden alınır?
Jira kayıt bağlantıları: causes veya relates to türünde bağlantı oluşturuldu
Kaydedin
Kayıt bağlantısı oluşturulduğunda günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Problem kaydı kapatıldı
|
Problem yaşam döngüsünün sona ermesidir. Durum Closed olarak değiştiğinde açıkça kaydedilir. | ||
|
Neden önemli?
Süreç örneğinin kesin bitiş noktasıdır. Toplam çevrim süresini ve kapanış oranlarını hesaplamak için gereklidir.
Nereden alınır?
Jira kayıt geçmişi: Durum Closed olarak değişti
Kaydedin
Durum Closed olduğunda günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Problem kaydı oluşturuldu
|
Problem kaydının sistemde oluşturulduğu ilk olaydır. Kayıt geçmişinde oluşturulma zaman damgası olarak açıkça yer alır. | ||
|
Neden önemli?
Problem yönetimi yaşam döngüsünün başlangıcını gösterir ve işlem hacmi analizine olanak tanır. İşlem hacmini ve kayıt giriş oranlarını hesaplamak için gereklidir.
Nereden alınır?
Jira kayıt tablosu: Created Date zaman damgası veya History sekmesi: Issue Created olayı
Kaydedin
Kayıt oluşturma işlemi tamamlandığında günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Değişiklik talebi bağlandı
|
Bir Değişiklik Talebinin (RFC) problem kaydına bağlanmasıdır. Kalıcı düzeltme sürecinin başladığını gösterir. | ||
|
Neden önemli?
Nedenin belirlenmesiyle düzeltme çalışmalarının başlaması arasındaki gecikmeyi ölçer. Change Management Transition Delay KPI’ını destekler.
Nereden alınır?
Jira kayıt bağlantıları: is fixed by türünde bağlantı oluşturuldu veya Change kayıt türüne bağlantı verildi
Kaydedin
Change kayıt türüne bağlantı oluşturulduğunda günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Kalıcı düzeltme uygulandı
|
Çözümün uygulandığını gösteren geçiştir. Genellikle durumun Implementing veya Fixed olarak değişmesinden anlaşılır. | ||
|
Neden önemli?
Teknik düzeltme çalışmalarının sona erdiğini gösterir. Uygulama çevrim süresini ölçmek için kullanılır.
Nereden alınır?
Jira kayıt geçmişi: Durum Implemented, Pending Verification veya Fixed olarak değişti
Kaydedin
Durum alanındaki güncellemeleri karşılaştırın
Olay türü
inferred
|
|||
|
Problem önceliği değişti
|
Problem kaydındaki Priority alanının güncellenmesidir. History sekmesinde Priority alanındaki değişiklikler izlenerek kaydedilir. | ||
|
Neden önemli?
Sorunun önceliğinin yükseltildiğini veya düşürüldüğünü gösterir. Bu değişikliği analiz etmek, ilk değerlendirmelerin doğruluğunu ve yüksek öncelikli kayıtların bekleme süresini belirlemeye yardımcı olur.
Nereden alınır?
Jira kayıt geçmişi: Priority alanı Old Value değerinden New Value değerine değişti
Kaydedin
Priority alanı güncellendiğinde günlüğe kaydedilir
Olay türü
explicit
|
|||
|
Problem yeniden açıldı
|
Problemin Resolved veya Closed durumundan yeniden etkin bir duruma geçmesidir. Düzeltmenin başarısız olduğunu veya çözümün kabul edilmediğini gösterir. | ||
|
Neden önemli?
Temel kalite metriklerinden biridir. Yeniden açılma oranının yüksek olması, kök neden analizinin veya testlerin etkisiz kaldığını gösterir.
Nereden alınır?
Jira kayıt geçmişi: Durum Closed/Resolved değerinden Open/In Progress değerine değişti
Kaydedin
Durum alanındaki değişiklik sırasını karşılaştırın
Olay türü
inferred
|
|||
|
SLA aşıldı
|
Problem çözüm süresinin belirlenen hizmet düzeyi anlaşmasını aştığını gösteren olaydır. SLA hedef tarihiyle çözüm tarihi karşılaştırılarak hesaplanır. | ||
|
Neden önemli?
Uyumluluk raporlaması için önemlidir. Hangi öncelik veya kategorilerin hedefleri en sık kaçırdığını belirlemeye yardımcı olur.
Nereden alınır?
Jira Service Management SLA günlükleri: Time to Resolution > Target veya hesaplanan değer
Kaydedin
SLA alanı verilerinden hesaplayın veya Due Date ile Resolution Date değerlerini karşılaştırın
Olay türü
calculated
|
|||
|
Uygulama sonrası inceleme
|
Düzeltme uygulandıktan sonra inceleme yapılmasıdır. Durumun In Review olarak değişmesi veya uygulama sonrası incelemeye özgü alanların güncellenmesiyle kaydedilir. | ||
|
Neden önemli?
Çıkarılan derslerin kayda geçirilmesini sağlayan uyumluluk etkinliğidir. Post Implementation Review Compliance analizini destekler.
Nereden alınır?
Jira kayıt geçmişi: Durum In Review olarak değişti VEYA PIR Notes alanı güncellendi
Kaydedin
Durum alanındaki değişiklikleri veya PIR alanı güncellemelerini karşılaştırın
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Sorun yönetimi verilerinizi bugün uygulanabilir içgörülere dönüştürün. Süreç analizinize başlamak için rehberi indirin veya destek ekibimizle iletişime geçin.
Sorun yönetimi akışınızı bugün iyileştirin
Çevrim sürelerini %30 kısaltın ve BT ortamınızın istikrarını artırın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.