Problem Yönetimi Veri Şablonunuz
Problem Yönetimi Veri Şablonunuz
- Detaylı analiz için önerilen nitelikler
- Anahtar süreç etkinlikleri ve durum geçişleri
- Zendesk Destek verileri için veri çıkarma rehberliği
Problem Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Problem kaydı üzerinde gerçekleştirilen olayın veya eylemin adı. | ||
|
Açıklama
Bu nitelik, problem kaydının yaşam döngüsü sırasında atılan belirli adımı veya eylemi yakalar. Örnekler arasında 'Açık'tan 'Beklemede'ye durum değişiklikleri, atama değişiklikleri veya 'Geçici Çözüm Yayınlandı' gibi belirli iş akışı adımları yer alır. Analizde bu, süreç haritasının düğümlerini oluşturur. Bu aktivitelerin sırası, analistlerin iş akışını görselleştirmesine, darboğazları belirlemesine ve belirli süreç adımları arasında geçen süreyi ölçmesine olanak tanır.
Neden önemli
Sürecin 'ne'sini tanımlar, süreç akışının görselleştirilmesini ve varyant analizini mümkün kılar.
Nereden alınır
Zendesk Bilet Denetimlerinden veya Bilet Metriklerinden türetildi
Örnekler
Problem Kaydı OluşturulduAraştırma BaşlatıldıGeçici Çözüm Yayınlandı
|
|||
|
Başlangıç Zamanı
EventTimestamp
|
Bir `activity`'nin occurred olduğu specific `date` ve `time`. | ||
|
Açıklama
Bu nitelik, Zendesk sistemi içinde bir aktivitenin tam olarak gerçekleştiği anı kaydeder. Olayları doğru sıralamak ve adımlar arasındaki süreleri hesaplamak için gereken zamansal boyutu sağlar. Analizde bu, döngü sürelerini hesaplamak, gecikmeleri belirlemek, SLA uyumluluğunu kontrol etmek ve süreci zaman içinde görselleştirmek için kritik öneme sahiptir. Doğru zaman damgaları olmadan, problem çözüm sürecinin hızını anlamak imkansızdır.
Neden önemli
Etkinliklerin sıralanmasına ve tüm zaman tabanlı KPI'ların hesaplanmasına olanak tanır.
Nereden alınır
Zendesk Talep Denetimleri, 'created_at' alanı
Örnekler
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
|
|||
|
Kaynak Sistem
SourceSystem
|
Verinin kaynaklandığı sistemin adı. | ||
|
Açıklama
Bu nitelik, süreç verilerinin çıkarıldığı yazılım platformunu tanımlar. Bu bağlamda, sürekli olarak 'Zendesk Support' ile doldurulacaktır. Analizde, özellikle birden fazla sistemden (örn. Zendesk ve Jira) gelen verileri birleştirirken, bu alan analistlerin verileri kaynağına göre filtrelemesine veya gruplamasına olanak tanır. Çoklu sistem süreç görünümlerinde veri soykütüğü ve izlenebilirliği sağlar.
Neden önemli
Veri soyunu garanti eder ve çoklu sistem process mining konfigürasyonlarını destekler.
Nereden alınır
Çıkarma sırasında sabit kodlandı
Örnekler
Zendesk Support
|
|||
|
Problem Kaydı
ProblemRecordId
|
Zendesk'teki problem talebine atanan benzersiz sayısal tanımlayıcı. | ||
|
Açıklama
Bu nitelik, Zendesk Support sistemi içindeki problem kaydı için benzersiz anahtarı temsil eder. Process Mining için merkezi Vaka Kimliği görevi görür ve sonraki tüm olayların, güncellemelerin ve etkileşimlerin tek bir süreç örneğinde gruplandırılmasını sağlar. Analizde bu Kimlik, her bir problem inceleme yolculuğunu oluşturulmasından kapanışına kadar belirgin bir şekilde tanımlamak için kullanılır. İlgili olayların ilişkilendirilmesini ve problemin yaşam döngüsünün çeşitli destek katmanları boyunca izlenmesini sağlar.
Neden önemli
Herhangi bir process mining analizi için olayları vakalar halinde gruplamak için gerekli olan temel zorunlu anahtardır.
Nereden alınır
Zendesk Talep nesnesi, tipi 'problem' olan 'id' alanı
Örnekler
1045293849921
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Problem kaydının en son ne zaman değiştirildiğini gösteren zaman damgası. | ||
|
Açıklama
Bu nitelik, problem kaydı verilerinin kaynak sistemde en son güncellendiği zamanı yansıtır. Olay zaman damgasından farklıdır, çünkü aktivite düzeyinden ziyade kayıt düzeyini ifade eder. Analizde bu, verilerin güncelliğini belirlemeye yardımcı olur. Veri setinin güncel olup olmadığını veya kaynak sistem ile Process Mining ortamı arasında senkronizasyon gecikmeleri olup olmadığını tespit etmek için kullanılır.
Neden önemli
Veri tazeliğini izler ve artımlı veri yükleme stratejilerine yardımcı olur.
Nereden alınır
Zendesk Talep nesnesi, 'updated_at' alanı
Örnekler
2023-11-01T14:20:00Z
|
|||
|
Atanan Kişi Adı
AssigneeName
|
Problemi üzerinde çalışmak üzere atanan belirli temsilci. | ||
|
Açıklama
Bu nitelik, problem kaydından şu anda sorumlu olan bireysel kullanıcının adını içerir. Kimin belirli eylemleri gerçekleştirdiğine dair ayrıntılı görünürlük sağlar. Analizde bu, bireysel iş yükünü ve performansını anlamaya yardımcı olur. Grup düzeyinde analiz yaygın olsa da, atanan kişi düzeyindeki veriler eğitim ihtiyaçlarını veya karmaşık kök nedenleri çözmede özellikle etkili olan kişileri vurgulayabilir.
Neden önemli
Bireysel düzeyde kaynak analizini mümkün kılar.
Nereden alınır
Zendesk Talep nesnesi, 'assignee_id' alanı (isme çözümlendi)
Örnekler
John DoeJane SmithSistem
|
|||
|
Destek Grubu
SupportGroup
|
Problem kaydına şu anda atanmış ekip veya departman. | ||
|
Açıklama
Bu nitelik, belirli bir zamanda sorundan sorumlu belirli temsilci grubunu tanımlar. Talep bir ekipten diğerine devredildikçe değişir. Analizde bu, 'Destek Grubu Devir Teslim Analizi' kontrol paneli için kritik öneme sahiptir. Ekip başına performansın ölçülmesine, devir teslimler sırasındaki darboğazların belirlenmesine ve kaynak iş yükü dağılımının analiz edilmesine olanak tanır.
Neden önemli
Organizasyonel analizi ve departmanlar arası darboğazların belirlenmesini sağlar.
Nereden alınır
Zendesk Talep nesnesi, 'group_id' alanı (isme çözümlendi)
Örnekler
L2 DestekVeritabanı EkibiAğ Operasyonları
|
|||
|
İlgili Olay Sayısı
RelatedIncidentCount
|
Bu problem kaydına bağlı olay taleplerinin sayısı. | ||
|
Açıklama
Bu nitelik, bu problem kaydıyla ilişkilendirilen bireysel olay taleplerinin sayısını sayar. Zendesk'te bu, olay taleplerindeki 'problem_id' alanı aracılığıyla bu kayda geri bağlanarak yönetilir. Analizde bu, 'Olay İlişkilendirme ve Etki' için birincil metrikdir. En fazla sayıda kullanıcıyı etkileyen sorunları önceliklendirmeye yardımcı olur ve talep hacmi azaltma açısından en yüksek yatırım getirisini (ROI) sağlayacak düzeltmeler hakkında stratejik kararlar alınmasına rehberlik eder.
Neden önemli
Problemin büyüklüğünü ve kullanıcı üzerindeki etkisini gösterir.
Nereden alınır
Zendesk Talepler API'si, type='incident' ve problem_id=ThisID olan taleplerin sayısı
Örnekler
015342
|
|||
|
Kök Neden Kategorisi
RootCauseCategory
|
Sorunun tespit edilen temel nedeni (örn. Kod Hatası, Yapılandırma Hatası). | ||
|
Açıklama
Bu nitelik, probleme neyin neden olduğuna dair nihai teşhisi yakalar. Genellikle 'Kök Neden Tespit Edildi' aktivitesi sırasında doldurulur. Analizde, 'Problem Kategorizasyon Doğruluğu' raporunu oluşturmak ve sistem hatalarındaki eğilimleri analiz etmek için kullanılır. Yönetimin, kod kalitesine, altyapı istikrarına veya tedarikçi yönetimine odaklanıp odaklanmaması gerektiğini anlamasına yardımcı olur.
Neden önemli
Başarısızlık kalıplarının analizini sağlar ve uzun vadeli iyileştirme çabalarını yönlendirir.
Nereden alınır
Zendesk Talep Özel Alanları
Örnekler
`Yazılım Hatası`Yapılandırma HatasıKullanıcı Hatası
|
|||
|
Öncelik
Priority
|
Problem kaydına atanan aciliyet seviyesi. | ||
|
Açıklama
Bu nitelik, problemin göreceli önemini gösterir ve genellikle Düşük, Normal, Yüksek veya Acil olarak kategorize edilir. Beklenen hizmet seviyesi anlaşmalarını (SLA'lar) ve kaynak tahsisini yönlendirir. Analizde bu, süreci bölümlere ayırmak ve farklı aciliyet seviyeleri arasında performansı karşılaştırmak için kullanılır. Örneğin, 'Acil' sorunların gerçekten 'Düşük' öncelikli olanlardan daha hızlı çözülüp çözülmediğini doğrulamaya yardımcı olur; bu da 'Kök Neden İnceleme Hızı' kontrol paneli tarafından gereklidir.
Neden önemli
SLA uyumunu ve kaynak önceliklendirmesini analiz etmek için vakaları segmentlere ayırmak esastır.
Nereden alınır
Zendesk Talep nesnesi, 'priority' alanı
Örnekler
AcilYüksekNormalDüşük
|
|||
|
Problem Durumu
ProblemStatus
|
Problem kaydının yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Bu nitelik, sorunun Yeni, Açık, Beklemede, Çözüldü veya Kapalı gibi mevcut durumunu gösterir. İncelemenin ilerlemesini yansıtır. Analizde bu, açık ve kapalı vakaları filtrelemek için kullanılır. Hangi aktif vakaların beklenen durum yaşam döngüsünde ilerlemediğini belirlemek için 'Durgun Problem Kaydı İzleme' kontrol paneli için hayati öneme sahiptir.
Neden önemli
Vakaların tamamlama durumlarına göre filtrelenmesine olanak tanır.
Nereden alınır
Zendesk Talep nesnesi, 'status' alanı
Örnekler
yeniopenpendingsolvedkapalı
|
|||
|
SLA Son Tarihi
SlaDueDate
|
Problemin çözülmesi gereken hedef tarih ve saat. | ||
|
Açıklama
Bu nitelik, Hizmet Seviyesi Anlaşması yapılandırmasına dayalı çözüm için son tarihi temsil eder. Genellikle öncelik ve talebin oluşturulma zamanına göre hesaplanır. Analizde bu, 'Problem SLA Uyum Oranı'nı hesaplamak için gerçek çözüm süresiyle karşılaştırılır. Ayrılan süreyi yaklaşan veya aşan vakaları vurgulayarak 'SLA Performans ve Risk' kontrol panelini besler.
Neden önemli
Uyumluluğu ve sözleşmesel performansı ölçmek için kritiktir.
Nereden alınır
Zendesk Talep Metrikleri veya SLA Politikaları uç noktası
Örnekler
2023-12-01T17:00:00Z
|
|||
|
Sorun Kategorisi
ProblemCategory
|
Sorunun sınıflandırılması (örn. Yazılım, Donanım, Ağ). | ||
|
Açıklama
Bu nitelik, sorunu etkilenen hizmete veya teknoloji yığınına göre kategorize eder. Genellikle Zendesk formlarında özel bir açılır alandır. Analizde bu, 'Problem Kategorizasyon Doğruluğu' kontrol paneli için kullanılır. Bu başlangıç kategorisini nihai kök neden ile karşılaştırmak, ilk değerlendirmenin sorunları doğru ekiplere yönlendirip yönlendirmediğini belirlemeye yardımcı olur.
Neden önemli
Teknoloji veya iş hizmetine göre segmentasyona olanak tanır.
Nereden alınır
Zendesk Talep Özel Alanları
Örnekler
VeritabanıUI/UXAğ Altyapısı
|
|||
|
Araştırma Süresi
InvestigationDuration
|
İnceleme başlangıcından kök neden tespitine kadar geçen süre. | ||
|
Açıklama
Bu hesaplanmış nitelik, temel teşhis aşamasının süresini ölçer. 'İnceleme Başlatıldı' aktivitesi ile 'Kök Neden Tespit Edildi' aktivitesi arasındaki zaman farkını hesaplar. Analizde bu, 'Ortalama Kök Neden Analiz Süresi' için birincil metrikdir. Farklı destek grupları ve problem kategorileri arasında teşhis hızının kıyaslanmasına olanak tanır.
Neden önemli
Teşhis sürecinin verimliliğini ölçer.
Nereden alınır
Process Mining aracında hesaplandı: Zaman Damgası (Kök Neden) - Zaman Damgası (Araştırma Başlangıcı)
Örnekler
48 saat5 gün
|
|||
|
Bilgi Makalesi Kimliği
KnowledgeArticleId
|
Problemle oluşturulan veya ilişkilendirilen bilgi tabanı makalesinin kimliği. | ||
|
Açıklama
Bu nitelik, bir Zendesk Guide makalesine veya harici bir bilgi öğesine referansı saklar. Sorundan elde edilen bilginin yakalandığını gösterir. Analizde, bu alanın varlığı 'Bilgi Tabanı Entegrasyon Oranı'nı hesaplamak için kullanılır. Kuruluşun, gelecekte başvurmak üzere çözümleri belgeleyerek öğrenme döngüsünü kapattığını doğrular.
Neden önemli
Bilgi yönetimi süreçlerinin etkinliğini ölçer.
Nereden alınır
Zendesk Talep Özel Alanları veya Bağlantılı İçerik
Örnekler
360045889KB-2991
|
|||
|
Değişiklik Talebi Kimliği
ChangeRequestId
|
Düzeltmeyi uygulamak için ilişkilendirilen değişiklik talebinin tanımlayıcısı. | ||
|
Açıklama
Bu nitelik, problem kaydını bir Değişiklik Yönetimi kaydına (potansiyel olarak başka bir sistemde veya farklı bir talep türünde) bağlar. Resmi bir değişiklik sürecinin başlatıldığını gösterir. Analizde bu, 'Değişiklik Talebi Başlatma Oranı' kontrol panelini destekler. Teşhisten uygulamaya geçişi izlemeye yardımcı olur, böylece belirlenen kök nedenlerin resmi değişiklik eylemleriyle sonuçlanmasını sağlar.
Neden önemli
Problem sürecini değişiklik yönetimi sürecine bağlar.
Nereden alınır
Zendesk Talep Özel Alanları veya Bağlantılı Talepler
Örnekler
CR-1002CHG00394
|
|||
|
Eskimiş mi
IsStale
|
Problemin 14 günden fazla süredir etkinliği olup olmadığını işaretler. | ||
|
Açıklama
Bu hesaplanmış nitelik, son zamanlarda güncellenmemiş kayıtları tanımlar. Mevcut tarihi (veya analiz tarihini) son aktivite zaman damgasıyla karşılaştırır. Analizde bu, 'Durgun Problem Kaydı İzleme' kontrol panelini besler. Yöneticilerin, birikmiş işleri şişiren ve idari olarak kapatma veya yeniden atama gerektirebilecek ihmal edilmiş vakaları hızla izole etmesine yardımcı olur.
Neden önemli
Süreç israfını ve ihmal edilen iş öğelerini belirlemeye yardımcı olur.
Nereden alınır
Process Mining aracında hesaplandı: (Şimdi - SonVeriGüncellemesi) > 14 gün
Örnekler
truefalse
|
|||
|
Geçici Çözüm Aktif
WorkaroundActive
|
Bir geçici çözümün sağlanıp/yayınlanmadığını gösteren bir işaret. | ||
|
Açıklama
Bu boolean nitelik, sorun için geçici bir düzeltmenin belgelenip belgelenmediğini gösterir. Genellikle 'Geçici Çözüm Yayınlandı' aktivitesinin veya formdaki belirli bir onay kutusunun varlığından türetilir. Analizde bu, 'Geçici Çözüm Yayınlama Uyumluluğu' kontrol paneli için kullanılır. Destek ekibinin uzun vadeli inceleme devam ederken kullanıcılara ne sıklıkta acil yardım sağladığını ölçer.
Neden önemli
Araştırmalar sırasında kullanıcı etkisinin azaltılmasını ölçmek için anahtardır.
Nereden alınır
'Geçici Çözüm Yayınlandı' etkinliğinin veya Özel Alanın varlığından türetildi
Örnekler
truefalse
|
|||
|
PIR Var
HasPostImplementationReview
|
Uygulama Sonrası İnceleme yapılıp yapılmadığını işaretler. | ||
|
Açıklama
Bu nitelik, problem çözüm sürecinin bir inceleme aşaması içerip içermediğini gösterir. Bu, vaka geçmişinde 'Uygulama Sonrası İnceleme Gerçekleştirildi' aktivitesinin olup olmadığı kontrol edilerek elde edilir. Analizde bu, 'Uygulama Sonrası İnceleme Kapsamı' kontrol panelini destekler. Kuruluşun önemli sorunlarından ders çıkardığını sağlayan bir uyumluluk metrikidir.
Neden önemli
Sürekli iyileştirme süreçleriyle uyumluluğu doğrular.
Nereden alınır
'Uygulama Sonrası İnceleme Yapıldı' etkinliğinin varlığından türetildi
Örnekler
truefalse
|
|||
|
Problem Konusu
ProblemSubject
|
Problem kaydının kısa özeti veya başlığı. | ||
|
Açıklama
Bu nitelik, problem oluşturulduğunda girilen metin özetini içerir. Genellikle semptomu veya incelenen sorunu açıklar. Analizde bu, analiste belirli vakalara derinlemesine inerken bağlam sağlar. Benzer sorunları kümelemek veya yapılandırılmış kategori alanları tarafından yakalanamayan tekrar eden konuları belirlemek için burada metin madenciliği teknikleri de uygulanabilir.
Neden önemli
Bireysel vakalar için insan tarafından okunabilir bağlam sağlar.
Nereden alınır
Zendesk Talep nesnesi, 'subject' alanı
Örnekler
AB bölgesinde ödemeler işlenemiyorGiriş sunucusunda gecikme artışlarıYönetici kullanıcılar için veri dışa aktarımı başarısız oluyor
|
|||
Problem Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Araştırma Başlatıldı
|
Pasif 'Yeni' durumundan aktif bir çalışma durumuna geçişi işaret eder. Bu, bir temsilcinin sorunu onayladığını ve teşhise başladığını gösterir. | ||
|
Neden önemli
Durgun Problem Kaydı metriklerini hesaplamak ve Ortalama Kök Neden Analiz Süresi KPI'ı için başlangıç noktası olarak kullanılır.
Nereden alınır
Bilet durumu 'Yeni'den 'Açık' veya 'Beklemede'ye değiştiğinde çıkarıldı.
Yakala
Durum alanını öncesi/sonrası ile karşılaştır
Event tipi
inferred
|
|||
|
Çözüm Doğrulandı
|
Sorunun resmi olarak Çözüldü olarak işaretlenmesi. Zendesk'te bu, standart sistem durumu 'Çözüldü' olarak ayarlandığında meydana gelir ve düzeltmenin doğrulandığını ve vakanın tamamlandığını gösterir. | ||
|
Neden önemli
SLA Performans ve Risk hesaplamaları ile Problem SLA Uyum Oranı için birincil bitiş noktasıdır.
Nereden alınır
Bilet durumunun 'Çözüldü' olarak değişmesinden türetildi.
Yakala
Durum Çözüldü olarak değiştiğinde kaydedildi
Event tipi
explicit
|
|||
|
Destek Grubuna Atandı
|
Problem kaydının belirli bir teknik ekibe veya departmana yönlendirilmesi. Bu, talepteki Grup Kimliği alanı güncellendiğinde izlenir. | ||
|
Neden önemli
Departmanlar arası bekleme sürelerini ölçmek için Destek Grubu Devir Teslim Analizi dashboard'u için kritiktir.
Nereden alınır
Talep denetim günlüğündeki 'group_id' alanındaki değişiklikleri izleyin.
Yakala
İşlem Grup Ataması Değişikliği yürütüldüğünde kaydedildi
Event tipi
explicit
|
|||
|
Geçici Çözüm Yayınlandı
|
Sorun için geçici bir düzeltmenin belgelenmesi ve paylaşılması eylemi. Zendesk'te bu, genellikle belirli bir etiket veya geçici bir çözümün mevcut olduğunu gösteren özel bir onay kutusu alanı aracılığıyla yakalanır. | ||
|
Neden önemli
Geçici Çözüm Yayınlama Uyumluluğu kontrol panelini destekler, uzun incelemeler sırasında kullanıcılara geçici çözüm sağlanmasını sağlar.
Nereden alınır
'workaround_published' etiketinin eklenmesini veya 'Workaround' adlı özel bir boolean alanındaki değişikliği izleyin.
Yakala
Özel alan veya etiket değerlerini karşılaştırın
Event tipi
inferred
|
|||
|
Kalıcı Düzeltme Uygulandı
|
Teknik çözümün ortama dağıtıldığını belirtir. Bu genellikle, talep tamamen çözülmeden önce özel bir durum geçişi veya belirli bir etiket aracılığıyla izlenir. | ||
|
Neden önemli
Teşhisten dağıtıma kadar geçen süreyi ölçmek için Düzeltme Uygulama Verimliliği dashboard'u için esastır.
Nereden alınır
Belirli bir etiketten (örn. 'fix_deployed') veya varsa özel bir durum alanından çıkarıldı.
Yakala
Etiketleri veya özel durum açılır menülerini izleyin
Event tipi
inferred
|
|||
|
Kök Neden Belirlendi
|
Problemin temel nedeninin belirlendiği nokta. Bu genellikle, bir temsilci tarafından özel bir 'Kök Neden' metin alanı veya açılır kategori doldurulduğunda yakalanır. | ||
|
Neden önemli
Kök Neden Araştırma Hızı dashboard'u ve teşhis verimliliğini ölçmek için kritik bir kilometre taşı.
Nereden alınır
'Kök Neden', 'RCA' veya 'Sorun Kaynağı' olarak etiketlenmiş özel alanlardaki boş olmayan değer değişikliklerini izleyin.
Yakala
Doldurma için özel alan değerlerini karşılaştırın
Event tipi
inferred
|
|||
|
Problem Kaydı Kapatıldı
|
Talebin kilitlendiği ve başka değişiklik yapılamadığı son yaşam döngüsü olayıdır. Zendesk'te bu, genellikle Çözüldü durumundan 4 gün sonra otomatik olarak gerçekleşir. | ||
|
Neden önemli
Kaydın ömrünün kesin sonunu işaret eder ve veri saklama ile geçmiş raporlama için kullanılır.
Nereden alınır
Bilet durumunun 'Kapalı' olarak değişmesinden türetildi.
Yakala
Durum 'Kapatıldı' olarak değiştiğinde kaydedilir
Event tipi
explicit
|
|||
|
Problem Kaydı Oluşturuldu
|
Zendesk Support içinde problem talebinin ilk oluşturulması. Bu olay, sorunun sisteme ilk kaydedildiği zaman damgasını yakalar ve genellikle süreç örneğini tetikler. | ||
|
Neden önemli
Uçtan Uca Çözüm Döngüsü için başlangıç zamanını belirler ve sonraki tüm lead time metrikleri için temel teşkil eder.
Nereden alınır
Bilet nesnesindeki 'created_at' zaman damgasından veya bilet denetim günlüğündeki ilk girişten türetildi.
Yakala
İşlem Bilet Oluşturuldu yürütüldüğünde kaydedildi
Event tipi
explicit
|
|||
|
Değişiklik Talebi Başlatıldı
|
Bir problemin düzeltilmesi için resmi bir değişiklik yönetimi sürecinin tetiklendiğini gösterir. Bu genellikle 'Değişiklik Talebi Kimliği' özel alanı doldurulduğunda veya 'Değişiklik' türü bir bilet bağlandığında çıkarılır. | ||
|
Neden önemli
Değişiklik Talebi Başlatma Oranı'nı izler ve Problem Yönetimi'ni Değişiklik Yönetimi iş akışlarına bağlar.
Nereden alınır
'change_reference' gibi özel bir alandaki güncellemeleri veya 'problem_change' bağlantı türünün oluşturulmasını izleyin.
Yakala
Dış kimlik girişi için özel alanı izleyin
Event tipi
inferred
|
|||
|
Önerilen Çözüm Taslağı Hazırlandı
|
Problem incelemesine dayalı bir bilgi tabanı makalesinin oluşturulması. Bu, Zendesk Knowledge Capture uygulamasının kullanımından veya yeni bir makalenin ilişkilendirilmesinden çıkarılır. | ||
|
Neden önemli
Kurumsal öğrenmeyi sağlayan Bilgi Tabanı Entegrasyon Oranı KPI'ını destekler.
Nereden alınır
'Knowledge Capture' entegrasyonu veya 'kcs_draft' gibi etiketlerle ilgili olayları izleyin.
Yakala
Belirli sistem etiketlerinden veya olay bağlantılarından türetin
Event tipi
inferred
|
|||
|
Sorun İncelemesi Yeniden Açıldı
|
Daha önce Çözüldü olarak işaretlenmiş bir problem kaydının Açık veya aktif bir duruma geri döndürülmesiyle meydana gelir. Bu, başarısız bir düzeltmeyi veya reddedilmiş bir çözümü gösterir. | ||
|
Neden önemli
Problem Yeniden Açılma Oranı KPI'ını destekler ve çözüm sürecindeki kalite sorunlarını belirlemeye yardımcı olur.
Nereden alınır
Durum 'Çözüldü'den tekrar 'Açık', 'Yeni' veya 'Beklemede'ye geçtiğinde çıkarıldı.
Yakala
Durum alanını öncesi/sonrası ile karşılaştır
Event tipi
inferred
|
|||
|
Uygulama Sonrası İnceleme Yapıldı
|
Düzeltme sonrası retrospektif bir incelemenin tamamlandığını doğrular. Bu genellikle süreç koordinatörü tarafından güncellenen bir onay kutusu veya tarih alanıdır. | ||
|
Neden önemli
Kalite standartlarına uyumu sağlamak için Uygulama Sonrası İnceleme Sıklığı KPI'ı için gereklidir.
Nereden alınır
Özel bir 'PIR Tamamlandı' onay kutusu veya 'PIR Tarihi' tarih alanındaki güncellemeleri izleyin.
Yakala
Özel alanın tamamlanmasını izleyin
Event tipi
inferred
|
|||