Problem Yönetimi Veri Templateiniz
Problem Yönetimi Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- Event Logunuzda yakalamanız gereken süreç aşamaları
- Veri çıkarma için teknik yönergeler
Sorun Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik
ActivityName
|
Sorun kaydı için gerçekleşen belirli eylem veya durum değişikliği. | ||
|
Açıklama
Bu öznitelik, sorun 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 Logged', 'Status Changed to Investigating' ve 'Root Cause Identified' bulunur. Süreç akışını haritalamak ve bir sorunu çözmek için izlenen adımların sırasını belirlemek açısından gereklidir. Process Mining'de bu etkinlikler süreç haritasının düğümlerini 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 Changelog (History) veya Issue Status geçişleri
Örnekler
Sorun kaydı oluşturulduİnceleme başlatıldıKök neden belirlendiGeçici çözüm güncellendiSorun kaydı kapatıldı
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin geldiği sistemin adı. | ||
|
Açıklama
Süreç verilerinin çıkarıldığı yazılım sistemini tanımlar. Bu bağlamda değer sürekli olarak 'Jira Service Management'tır. Bu öznitelik, veri kaynaklarını ayırt etmek için özellikle çok sistemli ortamlarda kullanışlıdır. Ancak bu görünümde temel olarak veri soyunu gösteren statik bir tanımlayıcı görevi görür.
Neden önemli?
Özellikle diğer BT Hizmet Yönetimi verileriyle birleştirme yapılırken verilerin kaynağı hakkında bağlam sağlar.
Nereden alınır?
Sabit kodlanmış veya sistem yapılandırması
Örnekler
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verilerin çıkarıldığı veya son kez yenilendiği zaman damgası. | ||
|
Açıklama
Veri setinin canlı Jira Service Management ortamıyla en son ne zaman senkronize edildiğini gösterir. Böylece analistler verilerin güncelliğini 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 duyulan güveni artırır.
Nereden alınır?
ETL zaman damgası
Örnekler
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
Sorun kaydı
ProblemKey
|
Jira Service Management'ta sorun kaydına atanan benzersiz tanımlayıcı. | ||
|
Açıklama
Bu öznitelik, Process Mining analizi için merkezi Case ID olarak kullanılır. Yeni bir sorun kaydı oluşturulduğunda Jira Service Management tarafından oluşturulan benzersiz anahtarı, örneğin PM-1001, temsil eder. İlgili tüm etkinlikleri, durum değişikliklerini ve güncellemeleri tek bir uçtan uca süreç örneğinde gruplamak için kullanılır. Bu özniteliği analiz ederek bir sorunun ilk tespitinden incelemeye ve nihai 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 sorun kayıtlarını izlemek için gereken temel anahtardır.
Nereden alınır?
Issue table, field 'Key' or 'Issue Key'
Örnekler
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
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 anı kaydeder. Olayları kronolojik sıraya koymak ve adımlar arasındaki süreleri hesaplamak için kullanılır. Doğru zaman damgaları, 'Problem Logged' ile 'Root Cause Identified' arasındaki süre gibi çevrim sürelerini hesaplamak ve zaman içindeki işlem hacmini 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 Changelog created date veya Issue created date
Örnekler
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
Atanan destek grubu
SupportGroup
|
Sorunu incelemek üzere o anda atanan teknik ekip veya grup. | ||
|
Açıklama
Olay sırasında problem kaydından sorumlu olan belirli ekibi gösterir. Jira Service Management içinde bu bilgi çoğu zaman Bileşen veya Destek Grubu gibi özel bir alana eşlenir. Bu öznitelik, problemlerin ekipler arasında nasıl ilerlediğini ve en uzun süre nerede kaldığını görselleştirmenizi sağlayan Destek Grubu Devir Teslim Darboğazları Dashboardu için gereklidir.
Neden önemli?
Kuruluş içindeki ekipleri analiz etmek ve ekipler arası sürtünmeyi belirlemek için gereklidir.
Nereden alınır?
Issue üzerindeki 'Component' alanı veya özel 'Support Group' alanı
Örnekler
Veritabanı YönetimiAğ OperasyonlarıUygulama Desteği 2. Seviye
|
|||
|
Kök neden kategorisi
RootCauseCategory
|
Problemin altında yatan nedenin sınıflandırması. | ||
|
Açıklama
Probleme neden olan teknik veya süreç kaynaklı hatayı sınıflandırır. Örneğin Yazılım Hatası, İnsan Hatası veya Donanım Arızası gibi değerler kullanılabilir. Bu alan, Jira Service Management içinde çoğu zaman özel bir alandır. Bu öznitelik, tekrarları önlemek amacıyla altyapı veya eğitime nerede yatırım yapılacağı konusunda stratejik kararlar alınmasını sağlayan Kök Neden Kategorisi Dağılımı Dashboardunu destekler.
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 tanımlayıcısı veya adı. | ||
|
Açıklama
Belirli etkinliği yürütmekten sorumlu kişinin veya sistem hesabının kimliğini kaydeder. Bu kişi, kaydı güncelleyen Assignee veya durum değişikliğinin Author'ı olabilir. Bu veri, kaynak kullanımını analiz etmek, kullanıcılar arasındaki devir darboğazlarını belirlemek ve sorun yönetimi sürecinde hesap verebilirliği sağlamak için kullanılır.
Neden önemli?
Devirleri, görevlerin ayrılığını ve kaynak iş yükünü analiz etmek için büyük önem taşır.
Nereden alınır?
Değişiklik günlüğündeki Jira 'author' alanı veya issue üzerindeki 'assignee' alanı
Örnekler
j.smithsystem_automationm.doe
|
|||
|
Öncelik
Priority
|
Problem kaydına atanan önem düzeyi. | ||
|
Açıklama
Problemin aciliyetini ve etkisini gösterir. Değerler genellikle Düşük ile Kritik arasında değişir. Bu alan, analizi bölümlere ayırmak ve yüksek öncelikli problemlerin SLA hedefleri içinde çözülmesini sağlamak için kullanılır. Bu özniteliği analiz etmek, kritik iş risklerinin doğru biçimde önceliklendirildiğini doğrulamak üzere SLA Uyumluluğu ve Hedef Eğilimleri Dashboarduna yardımcı olur.
Neden önemli?
Süreç performansını iş açısından önem düzeyine göre segmentlere ayırmanızı sağlar.
Nereden alınır?
Issue üzerindeki 'Priority' alanı
Örnekler
En YüksekYüksekOrtaDüşük
|
|||
|
Problem özeti
ProblemSummary
|
Problem kaydının kısa metin açıklaması veya başlığı. | ||
|
Açıklama
Problem kaydının başlık niteliğindeki özetini içerir. Öncelikle metin tabanlı olsa da process mining aracında tek tek vakaları inceleyen analistlere bağlam sağlar. Anahtar kelime aramasına ve kaydedilen problem türlerinin nitel analizine imkan verir.
Neden önemli?
Vaka kimliği için insanların kolayca anlayabileceği bir bağlam sağlar.
Nereden alınır?
Issue üzerindeki '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 probleme bağlanan 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 Dashboardu için gereklidir. Problem Yönetimi sürecini Değişiklik Yönetimine bağlayarak süreçler arası analiz yapılmasını sağlar.
Neden önemli?
İncelemeyi Change Management sürecindeki düzeltme çalışmasına bağlar.
Nereden alınır?
Türü 'is fixed by' veya benzeri olan issue bağlantıları
Örnekler
CR-404CHG-1099CR-5512
|
|||
|
Bağlantılı olay sayısı
LinkedIncidentCount
|
Bu problem kaydına bağlanan olayların sayısı. | ||
|
Açıklama
Problem kaydıyla ilişkilendirilmiş olay ticket'larının sayısını gösterir. Bu öznitelik, problemin kullanıcı tabanı üzerindeki etkisini ölçer. En fazla destek ticket'ı oluşturan problemlere öncelik vermek için 'Olaydan Probleme Bağlantı Derinliği' KPI'ında kullanılır.
Neden önemli?
İş etkisini olay hacmine göre ölçer.
Nereden alınır?
'issuelinks' tablosunda türü 'Problem/Incident' olan bağlantıların sayısı
Örnekler
011550
|
|||
|
Bildiren
ReporterName
|
Problem kaydını ilk oluşturan kullanıcı. | ||
|
Açıklama
Problem kaydını oluşturan kişiyi gösterir. Bu kişi, atanan kişiden farklıdır. Bildirim yapanları analiz etmek, problemlerin nerede belirlendiğini anlamaya yardımcı olur. Örneğin bildirimler Hizmet Masası Temsilcilerinden veya Sistem Yöneticilerinden geliyor olabilir. Bu bilgi, Proaktif ve Tepkisel analizine bağlam kazandırır.
Neden önemli?
Problem girişinin kaynağını tanımlar.
Nereden alınır?
Issue üzerindeki 'Reporter' alanı
Örnekler
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
Çözüm kodu
ResolutionCode
|
Problemin nasıl çözüldüğünü gösteren kod. | ||
|
Açıklama
Problem kaydının nihai sonucunu 'Fixed', 'Won't Fix', 'Duplicate' veya 'Cannot Reproduce' gibi değerlerle belirtir. Başarıyla çözülen problemleri idari nedenlerle kapatılanlardan ayırmak için kullanılır. Böylece 'Mean Time to Root Cause' gibi KPI hesaplamalarının doğruluğu korunur.
Neden önemli?
Etkili düzeltmeler ile idari kapanışları birbirinden ayırır.
Nereden alınır?
Issue üzerindeki 'Resolution' alanı
Örnekler
TamamlandıYapılmayacakYinelenenYeniden Üretilemiyor
|
|||
|
Geçici çözüm mevcut
WorkaroundDetails
|
Problem için bir geçici çözümün belgelenip belgelenmediğini gösterir. | ||
|
Açıklama
Geçici bir çözüm metninin mevcut veya yayımlanmış olup olmadığını kaydeder. Bu sayede kuruluş 'Geçici Çözüm Yayımlama Hızı'nı izleyebilir. Bu alanın analizi, kalıcı bir düzeltme bulunmadan önce ekibin hizmet kararlılığını ne kadar hızlı yeniden sağlayabildiğini belirlemeye yardımcı olur.
Neden önemli?
İş birimine sağlanan geçici rahatlamanın hızını ölçmek için önemlidir.
Nereden alınır?
Özel 'Workaround' alanı
Örnekler
Hizmeti yeniden başlatınTarayıcı önbelleğini temizleyinBelirtilmedi
|
|||
|
Oluşturulma tarihi
CreatedDate
|
Problem kaydının oluşturulduğu tarih. | ||
|
Açıklama
Problemin sisteme ilk kaydedildiği zaman damgası. Olay zaman damgası etkinlik zamanlamasını gösterirken bu özel öznitelik genellikle üst düzey filtreleme için kullanılır, örneğin '1. çeyrekte oluşturulan tüm problemleri göster'. Yaşlandırma analizi için başlangıç noktasıdır.
Neden önemli?
Yaşlandırma ve giriş hacmi analizi için referans tarihidir.
Nereden alınır?
Issue üzerindeki 'Created' alanı
Örnekler
2023-01-012023-06-15
|
|||
|
PIR yürütüldü
ReviewStatus
|
Bir Post Implementation Review (PIR) gerçekleştirilip gerçekleştirilmediğini gösterir. | ||
|
Açıklama
Uygulama Sonrası İnceleme etkinliğinin veya işaretinin vaka üzerinde bulunup bulunmadığını izler. Bu bilgi, Uygulama Sonrası İnceleme Uyumluluğu Dashboardu için gereklidir. Kuruluşun sürekli iyileştirme yönetişimi gerekliliklerine uyduğundan emin olmanızı sağlar.
Neden önemli?
Organizasyonel öğrenme için uyumluluk metriğidir.
Nereden alınır?
Özel 'PIR Status' alanı veya 'PIR' etkinliğinin mevcut olması
Örnekler
TamamlandıBeklemedeGerekli Değil
|
|||
|
SLA ihlal durumu
SlaBreachStatus
|
Problem kaydının hizmet seviyesi anlaşmasını ihlal edip etmediğini gösterir. | ||
|
Açıklama
Çözüm süresinin üzerinde anlaşılan hedefi aşıp aşmadığını gösteren bir boolean veya durum alanıdır. Bu bilgi, SLA Uyumluluğu ve Hedef Eğilimleri Dashboardunda kullanılır. Kuruluşu uyumluluk risklerine veya cezalara açık bırakan vakaları öne çıkarır.
Neden önemli?
Uyumluluk ve performans izleme için büyük önem taşır.
Nereden alınır?
Jira Service Management SLA alanı mantığı
Örnekler
Karşılandıİhlal edildiDuraklatıldı
|
|||
|
Tespit kaynağı
DetectionSource
|
Problemin nasıl tespit edildiği, örneğin Proactive veya Reactive. | ||
|
Açıklama
Problemin nasıl belirlendiğini gösterir. Yaygın değerler arasında Proaktif İzleme, Hizmet Masası Olayı veya Tedarikçi Bildirimi bulunur. Bu öznitelik, Problem Yönetimi sürecinin olgunluğunu ölçmek için Proaktif ve Tepkisel Belirleme Dashboardunda 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 İzlemeOlay EskalasyonuTedarikçi Bildirimi
|
|||
|
Yeniden açıldı
IsReopened
|
Problemin kapatıldıktan sonra yeniden açılıp açılmadığını gösteren işaret. | ||
|
Açıklama
Problem kaydı kapalı durumdan tekrar açık duruma geçtiğinde true olarak ayarlanan boolean işarettir. 'Problem Yeniden Açılma Oranı Analizi'ni destekler. Yüksek yeniden açılma oranları, kalıcı düzeltmelerde kalite sorunlarına veya doğrulama prosedürlerinin yetersizliğine işaret eder.
Neden önemli?
Düzeltmelerin etkinliği için kalite göstergesidir.
Nereden alınır?
Durum geçişlerinden türetilir
Örnekler
truefalse
|
|||
Sorun Yönetimi Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm doğrulandı
|
Düzeltmenin sorunu etkili biçimde çözdüğünün onaylanmasıdır. 'Resolved' veya belirli bir 'Verified' durumuna geçişten çıkarılır. | ||
|
Neden önemli?
Düzeltmenin çalıştığını doğrulayan kalite kapısıdır. Buradaki gecikmeler, test veya kullanıcı kabulü süreçlerindeki darboğazlara işaret eder.
Nereden alınır?
Jira Issue History: Status changed to 'Resolved' or 'Verified'
Yakalayın
Status alanı güncellemelerini karşılaştırın
Olay türü
inferred
|
|||
|
Destek grubuna atandı
|
Sorun kaydının belirli bir teknik ekibe veya destek grubuna atanmasıdır. Bu işlem, Support Group özel alanındaki veya gruplar kullanılmıyorsa Assignee alanındaki değişikliklerle izlenir. | ||
|
Neden önemli?
Ekipler arasındaki devirleri ve darboğazları analiz etmek için önemlidir. Yüksek devir oranları, yönlendirme verimsizliklerine işaret edebilir.
Nereden alınır?
Jira Issue History: Field 'Support Group' or 'Assignee' changed
Yakalayın
Atama alanı değiştiğinde günlüğe alınır
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?
İşletmeye ne kadar hızlı rahatlama sağlandığını ölçer. Workaround Availability Lead Time KPI'ı için önemlidir.
Nereden alınır?
Jira Issue History: Field 'Workaround' changed (not null)
Yakalayın
Workaround alanı değiştirildiğinde günlüğe alınır
Olay türü
explicit
|
|||
|
İnceleme başlatıldı
|
Sorun durumunun aktif inceleme durumuna geçirilmesidir, örneğin 'Under Investigation' veya 'In Progress'. Bu, aktif çalışma aşamasının başlangıcını gösterir. | ||
|
Neden önemli?
İnceleme çevrim süresinin ölçümünü başlatır. Bekleyen işte geçen süre ile gerçek aktif analiz süresini ayırt etmeye yardımcı olur.
Nereden alınır?
Jira Issue History: Status changed to 'Under Investigation' or 'In Progress'
Yakalayın
Status alanı güncellemelerini karşılaştırın
Olay türü
inferred
|
|||
|
Kök neden belirlendi
|
Temel nedenin resmi olarak kaydedildiği noktadır. 'Root Cause Identified' durumuna geçişten veya Root Cause alanının doldurulmasından çıkarılır. | ||
|
Neden önemli?
İnceleme aşamasını sona erdiren önemli bir kilometre taşıdır. Mean Time to Root Cause Discovery hesaplaması için gereklidir.
Nereden alınır?
Jira Issue History: Status changed to 'Root Cause Identified' OR Field 'Root Cause' populated
Yakalayın
Status alanını karşılaştırın veya alanın doldurulup doldurulmadığını kontrol edin
Olay türü
inferred
|
|||
|
Olay sorunla ilişkilendirildi
|
İlgili bir Incident ticket'ının Problem kaydına bağlanmasıdır. Bu işlem, issue links tablosunda veya geçmişte kaydedilir. | ||
|
Neden önemli?
Sorunun etkisini ve kapsamını belirler. Incident to Problem Linkage Depth KPI'ı ve iş etkisine göre önceliklendirme için gereklidir.
Nereden alınır?
Jira Issue Links: Link created with type 'causes' or 'relates to'
Yakalayın
Bir issue link oluşturulduğunda günlüğe alınır
Olay türü
explicit
|
|||
|
Sorun kaydı kapatıldı
|
Sorun yaşam döngüsünün nihai olarak sona ermesidir. Durum 'Closed' olduğunda açıkça kaydedilir. | ||
|
Neden önemli?
Süreç örneğinin kesin sonudur. Toplam çevrim süresini ve kapanış oranlarını hesaplamak için gereklidir.
Nereden alınır?
Jira Issue History: Status changed to 'Closed'
Yakalayın
Durum Closed'a geçtiğinde günlüğe alınır
Olay türü
explicit
|
|||
|
Sorun kaydı oluşturuldu
|
Problem ticket'ının sistemde oluşturulduğu ilk olaydır. Bu olay, sorun geçmişinde oluşturma zaman damgası olarak açıkça kaydedilir. | ||
|
Neden önemli?
Sorun yönetimi yaşam döngüsünün başlangıcını gösterir ve hacim analizine olanak tanır. İşlem hacmini ve başvuru oranlarını hesaplamak için gereklidir.
Nereden alınır?
Jira Issue Table: Created Date zaman damgası veya History Tab: Issue Created olayı
Yakalayın
Sorun oluşturma işlemi kaydedildiğinde günlüğe alınır
Olay türü
explicit
|
|||
|
Değişiklik talebi ilişkilendirildi
|
Bir Request for Change (RFC) kaydının Problem kaydına bağlanmasıdır. Bu, kalıcı düzeltme sürecinin başlatıldığını gösterir. | ||
|
Neden önemli?
Nedenin belirlenmesi ile düzeltmenin başlatılması arasındaki gecikmeyi ölçer. Change Management Transition Delay KPI'ını destekler.
Nereden alınır?
Jira Issue Links: Link created with type 'is fixed by' or linking to 'Change' issue type
Yakalayın
Bir Change issue type kaydına bağlantı oluşturulduğunda günlüğe alınır
Olay türü
explicit
|
|||
|
Kalıcı düzeltme uygulandı
|
Çözümün uygulandığını gösteren geçiştir. Genellikle 'Implementing' veya 'Fixed' durumuna geçişten çıkarılır. | ||
|
Neden önemli?
Teknik düzeltme çalışmasının sona erdiğini gösterir. Uygulama çevrim süresini ölçmek için kullanılır.
Nereden alınır?
Jira Issue History: Status changed to 'Implemented', 'Pending Verification', or 'Fixed'
Yakalayın
Status alanı güncellemelerini karşılaştırın
Olay türü
inferred
|
|||
|
SLA ihlal edildi
|
Sorun çözüm süresinin tanımlanan Service Level Agreement süresini aştığını gösteren olaydır. SLA hedef tarihi ile çözüm tarihi karşılaştırılarak hesaplanır. | ||
|
Neden önemli?
Uyumluluk raporlaması için önemlidir. Hangi önceliklerin veya kategorilerin hedefleri en sık karşılayamadığını belirlemeye yardımcı olur.
Nereden alınır?
Jira Service Management SLA Logs: 'Time to Resolution' > Target veya hesaplanan değer
Yakalayın
SLA alan verilerinden türetin veya Due Date ile Resolution Date'i karşılaştırın
Olay türü
calculated
|
|||
|
Sorun önceliği değiştirildi
|
Sorun kaydının Priority alanında yapılan güncellemedir. History Tab'da Priority alanındaki değişiklikler izlenerek kaydedilir. | ||
|
Neden önemli?
Sorunun eskale edildiğini veya önceliğinin düşürüldüğünü gösterir. Bunu analiz etmek, ilk triyajın doğruluğunu ve yüksek öncelikli bekleyen işlerin yaşını belirlemeye yardımcı olur.
Nereden alınır?
Jira Issue History: Field 'Priority' changed from Old Value to New Value
Yakalayın
Priority alanı güncellendiğinde günlüğe alınır
Olay türü
explicit
|
|||
|
Sorun yeniden açıldı
|
Sorunun 'Resolved' veya 'Closed' durumundan yeniden aktif bir duruma geçirilmesidir. Başarısız bir düzeltmeye veya reddedilen bir çözüme işaret eder. | ||
|
Neden önemli?
Başlıca kalite metriklerinden biridir. Yüksek yeniden açılma oranları, etkisiz kök neden analizine veya teste işaret eder.
Nereden alınır?
Jira Issue History: Status changed from 'Closed'/'Resolved' to 'Open'/'In Progress'
Yakalayın
Status alanı dizisini karşılaştırın
Olay türü
inferred
|
|||
|
Uygulama sonrası inceleme
|
Düzeltme uygulandıktan sonra inceleme yürütülmesidir. 'In Review' durumuna geçiş veya PIR'a özel alanlardaki güncellemeler aracılığıyla kaydedilir. | ||
|
Neden önemli?
Öğrenilen derslerin kaydedilmesini sağlayan uyumluluk faaliyetidir. Post Implementation Review Compliance analizini destekler.
Nereden alınır?
Jira Issue History: Status changed to 'In Review' OR Field 'PIR Notes' updated
Yakalayın
Status alanını veya PIR alanı güncellemelerini karşılaştırın
Olay türü
inferred
|
|||
Çıkarma Rehberleri
Başlamaya hazır mısınız?
Problem Yönetimi verilerinizi bugün uygulanabilir içgörülere dönüştürün. Process Mining yolculuğunuza başlamak için rehberi indirin veya destek ekibimizle iletişime geçin.
Problem Yönetimi akışınızı bugün optimize edin
Çevrim sürelerini %30 azaltın ve BT ortamınızı istikrarlı hale getirin.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.