Veri Şablonu: Olay Yönetimi
Olay Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Jira Service Management için veri çıkarma rehberliği
Incident Management Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Olay için gerçekleşen belirli olayın veya durum değişikliğinin adı. | ||
|
Açıklama
Etkinlik, 'Incident Created', 'Incident Assigned' veya 'Resolution Proposed' gibi olay yönetimi yaşam döngüsündeki belirli bir adımı veya olayı temsil eder. Bunlar genellikle Jira kaydının geçmişinde veya değişiklik günlüğünde kaydedilen durum geçişlerinden veya belirli güncelleme olaylarından türetilir. Bu etkinliklerin sırasını ve süresini analiz etmek, gerçek süreç akışını, darboğazları ve sapmaları ortaya çıkararak Process Mining'in birincil amacıdır.
Neden önemli
Etkinlikler, olay yaşam döngüsünün görselleştirilmesine ve analizine olanak tanıyarak süreç haritasının omurgasını oluşturur.
Nereden alınır
Jira sorun geçmişi ve değişiklik günlüğü verilerinden türetilmiştir; durum geçişlerini ve anahtar alan güncellemelerini yakalar.
Örnekler
Olay AtandıSoruşturma BaşladıOlay Çözüldü
|
|||
|
Başlangıç Zamanı
EventTimestamp
|
Aktivitenin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Bu öznitelik, olayın yaşam döngüsündeki her aktivite için timestamp'i kaydeder. Süreleri, cycle time'ları ve sürecin farklı adımları arasındaki bekleme sürelerini hesaplamak için kritiktir. Doğru timestamp'ler, ayrıntılı performans analizi, SLA izleme ve bottleneck tespiti sağlar. Çözüm süresi ve teşhis süresi gibi tüm performans metrikleri bu timestamp'lerden türetilir.
Neden önemli
Timestamp'ler, tüm zaman tabanlı metrikleri hesaplamak, süreç süresini anlamak ve performans bottleneck'lerini keşfetmek için kritiktir.
Nereden alınır
Bu, Jira sorununun değişiklik kaydındaki veya geçmişindeki her girişle ilişkili olan 'created' tarihidir.
Örnekler
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Olay Kimliği
IncidentId
|
Jira Service Management'taki her olay kaydı için benzersiz tanımlayıcı. | ||
|
Açıklama
Olay Kimliği, genellikle Jira'da Jira Kayıt Anahtarı olarak anılır ve bildirilen her olay için birincil benzersiz tanımlayıcı görevi görür. Oluşturulduğu andan nihai kapanışına kadar ilgili tüm etkinlikleri, yorumları ve durum değişikliklerini birbirine bağlar. Process Mining'de bu kimlik, her bir olayın uçtan uca yaşam döngüsünü yeniden yapılandırmak ve tüm sürecin kapsamlı bir analizini yapmak için esastır.
Neden önemli
Bu, tüm ilişkili event'leri tek bir vaka halinde ilişkilendirmek için kullanılan temel tanımlayıcı olup, her türlü Process Mining analizinin temelini oluşturur.
Nereden alınır
Bu, Jira Service Management'taki bir sorun için standart 'Key' alanıdır (örn. 'ITSM-123').
Örnekler
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin çekildiği sistem. | ||
|
Açıklama
Bu öznitelik, verinin kaynağını belirtir; bu durumda Jira Service Management'tır. Birden fazla sistemden gelen verilerin bütünsel bir süreç görünümü için birleştirildiği ortamlarda özellikle kullanışlıdır. Kaynak sistemi belirtmek, veri soy kütüğünün netliğini sağlar ve veri kalitesi veya çıkarma sorunlarının teşhis edilmesine yardımcı olur. Bu model için değer statik olacaktır.
Neden önemli
veri kaynağı hakkında temel bağlam sağlayarak, özellikle çoklu sistem analizlerinde netlik ve izlenebilirlik sağlar.
Nereden alınır
Bu, veri çıkarma süreci sırasında eklenmesi gereken statik bir değerdir.
Örnekler
Jira Service ManagementJira Cloud
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Verilerin kaynak sistemden son yenilendiği zamanı gösteren timestamp. | ||
|
Açıklama
Bu öznitelik, veri kümesinin en son ne zaman güncellendiğini kaydeder. Süreci analiz eden herkese kritik bir bağlam sunarak, verinin güncelliği konusunda bilgi sahibi olmalarını sağlar. Bu, güncel bilgilerin zamanında karar vermek için hayati önem taşıdığı sürekli izleme Dashboard'ları için özellikle önemlidir. Değer, tek bir veri çıkarma toplu işi içindeki tüm event'ler için genellikle aynıdır.
Neden önemli
Kullanıcıları, analizin alaka düzeyi ve doğruluğu açısından kritik öneme sahip olan verilerin güncelliği hakkında bilgilendirir.
Nereden alınır
Bu, veri dönüştürme süreci sırasında eklenen, veri çıkarma işleminin timestamp'idir.
Örnekler
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Atama Grubu
AssignmentGroup
|
Olayı ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Atama Grubu, olaya atanan ekibi temsil eder. Bu, 'L1 Helpdesk' gibi bir destek katmanı, 'Network Operations' gibi uzmanlaşmış bir ekip veya bir geliştirme ekibi olabilir. Atama grupları arasındaki geçişleri analiz etmek, süreç eskalasyonlarını ve devirleri anlamanın anahtarıdır. Ekip performansının ölçülmesini, ekip düzeyindeki darboğazların belirlenmesini ve ekipler arası bağımlılıkların analizini mümkün kılar.
Neden önemli
Ekip performansını, verimi ve farklı destek katmanları veya uzmanlaşmış gruplar arasındaki iş akışını analiz etmek için çok önemlidir.
Nereden alınır
Bu genellikle Jira'da 'Team' veya 'Assignment Group' gibi özel bir alan olarak uygulanır. Bazen Jira Components veya Project Roles'tan da türetilebilir.
Örnekler
1. Kademe DestekAltyapı EkibiVeritabanı Yöneticileri
|
|||
|
Atanan Kişi
Assignee
|
Olay üzerinde çalışmak üzere şu anda atanmış kullanıcı. | ||
|
Açıklama
Atanan Kişi, belirli bir zamanda olaydan sorumlu olan bireysel temsilci veya kullanıcıdır. Atanan kişideki değişiklikleri takip etmek, devirleri analiz etmek, iş yükü dağılımını anlamak ve belirli süreç adımlarına hangi kişilerin dahil olduğunu belirlemek için kritik öneme sahiptir. Bu öznitelik, destek ekipleri içindeki bireysel performans ve kaynak tahsisi hakkındaki soruları yanıtlamaya yardımcı olur.
Neden önemli
Bireysel iş yükünü izlemeye, belirli temsilcilerle ilgili darboğazları belirlemeye ve devirlerin çözüm süresi üzerindeki etkisini analiz etmeye yardımcı olur.
Nereden alınır
Bir Jira kaydındaki standart 'Assignee' alanı.
Örnekler
Can DemirEmily JonesServisMasasıTemsilcisi1
|
|||
|
Çözüm Çevrim Süresi
IncidentResolutionCycleTime
|
Olay oluşturulmasından çözüme kadar geçen toplam süre. | ||
|
Açıklama
Bu, 'CreatedDate' ile 'ResolutionDate' arasındaki süreyi temsil eden hesaplanmış bir metriktir. Olay yönetimindeki en önemli KPI'lardan biri olup, tüm sürecin verimliliğini doğrudan ölçer. Bu metriki öncelik, atama grubu veya bileşen gibi farklı boyutlarda analiz etmek, performans üzerinde en büyük etkiye sahip faktörleri belirlemeye yardımcı olur.
Neden önemli
Olay yönetimi sürecinin uçtan uca verimliliğini doğrudan ölçer ve performans takibi için birincil bir KPI'dır.
Nereden alınır
('ÇözümTarihi' - 'OluşturmaTarihi') olarak hesaplanır.
Örnekler
2h 30m1d 4h5d 1h 15m
|
|||
|
Çözüm Tarihi
ResolutionDate
|
Olayın çözüldü olarak işaretlendiği tarih ve saat. | ||
|
Açıklama
Bu öznitelik, olayın ilk kez çözüldü durumuna geçtiği timestamp'i yakalar. Aktif çalışma aşamasının sonunu işaret eder ve 'Time to Resolution' hesaplaması için bitiş noktasıdır. Çözüm tarihini oluşturulma tarihiyle karşılaştırmak, süreç verimliliğinin birincil ölçüsünü sağlar. Aynı zamanda SLA uyumluluğunu belirlemede önemli bir bileşendir.
Neden önemli
Çözüm sürecinin sonunu işaret eder; toplam döngü süresinin ve SLA performansının hesaplanmasını sağlar.
Nereden alınır
Bir Jira kaydındaki standart 'Resolved' alanı.
Örnekler
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Durum
Status
|
Olayın yaşam döngüsündeki mevcut aşaması. | ||
|
Açıklama
Durum alanı, 'Open', 'In Progress', 'Pending Customer' veya 'Resolved' gibi tanımlanmış iş akışı içindeki bir olayın mevcut durumunu belirtir. Durum değişiklikleri, Process Mining için etkinlik günlüğü oluşturmak için birincil kaynaktır. Her bir durumda harcanan süreyi analiz etmek, darboğazları belirlemek ve olayların en çok zaman geçirdiği yerleri anlamak için temeldir.
Neden önemli
Olayın ilerlemesini doğrudan yansıtır ve süreç adımlarını ve bekleme sürelerini belirlemek için birincil kaynaktır.
Nereden alınır
Bir Jira kaydındaki standart 'Status' alanı.
Örnekler
Devam EdiyorMüşteri BekleniyorÇözüldüKapalı
|
|||
|
Oluşturulma Tarihi
CreatedDate
|
Olayın sistemde ilk oluşturulduğu tarih ve saat. | ||
|
Açıklama
Bu öznitelik, olay yaşam döngüsünün resmi başlangıcını işaretler. Toplam çözüm süresi gibi genel metriklerin hesaplandığı temel timestamp'tir. Oluşturma tarihi her olay için statik bir değerdir ve Process Mining analizinde tüm vaka için başlangıç noktasıdır.
Neden önemli
Tüm uçtan uca cycle time hesaplamaları ve SLA ölçümleri için başlangıç noktası görevi görür.
Nereden alınır
Bir Jira kaydındaki standart 'Created' alanı.
Örnekler
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Öncelik
Priority
|
Olaya atanan, çözümün aciliyetini belirten öncelik düzeyi. | ||
|
Açıklama
Öncelik, bir olayın ele alınması için gereken hızı belirler. Genellikle etki ve aciliyetin birleşimi olup, SLA hedeflerini doğrudan etkiler. Olayları önceliğe göre analiz etmek, yüksek öncelikli olayların düşük öncelikli olanlardan daha hızlı ele alınıp alınmadığını ve önceliklendirme uygulamasının tutarlı olup olmadığını anlamaya yardımcı olur. Bu, süreç performansını filtrelemek ve karşılaştırmak için kritik bir boyuttur.
Neden önemli
SLA performans analizi ve kaynakların en kritik olaylara doğru şekilde tahsis edildiğini doğrulamak için hayati öneme sahiptir.
Nereden alınır
Bir Jira kaydındaki standart 'Priority' alanı.
Örnekler
En YüksekYüksekOrtaDüşük
|
|||
|
Bildiren
Reporter
|
Olayı ilk oluşturan veya bildiren kullanıcı. | ||
|
Açıklama
Bildiren Kişi, genellikle bir son kullanıcı veya başka bir sistem olan, olayı ilk kaydeden kişidir. Bildiren kişiye göre olayları analiz etmek, sık sık sorun yaşayan kullanıcıları veya departmanları belirlemeye yardımcı olabilir. Özellikle 'Waiting for Customer' ve 'Customer Responded' gibi etkinlikleri analiz ederken iletişim kalıplarını anlamak için de kullanılabilir.
Neden önemli
Olay kaynaklarını analiz etmeye, belirli kullanıcılar veya departmanlarla ilgili kalıpları belirlemeye ve müşteri etkileşim gecikmelerini anlamaya yardımcı olur.
Nereden alınır
Bir Jira kaydındaki standart 'Reporter' alanı.
Örnekler
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Bileşen
Component
|
Olaydan etkilenen sistem, uygulama veya altyapının bir parçası. | ||
|
Açıklama
Bileşenler, Jira projesinin 'Kullanıcı Arayüzü', 'Veritabanı' veya 'API' gibi daha küçük parçalara ayırmak için kullanılan alt bölümleridir. Olayları bileşene göre analiz etmek, bir sistemin hangi bölümlerinin sorunlara en yatkın olduğunu belirlemeye yardımcı olur. Bu bilgi, temel neden analizi için değerlidir ve hizmet iyileştirme veya teknik borç azaltma çabalarına rehberlik edebilir.
Neden önemli
Etkilenen belirli ürün veya sistem alanına göre filtreleme ve analiz imkanı sunarak, teknoloji odak noktalarını belirlemeye yardımcı olur.
Nereden alınır
Bir Jira kaydındaki standart 'Components' alanı.
Örnekler
Kimlik Doğrulama HizmetiRaporlama Dashboard'uMobil Uygulama
|
|||
|
Çözüm
Resolution
|
Olayın çözülmesinin nihai sonucu veya nedeni. | ||
|
Açıklama
Çözüm alanı, bir olayın neden çözüldü durumuna taşındığını açıklar. Yaygın çözümler arasında 'Fixed', 'Duplicate', 'Won't Do' veya 'Cannot Reproduce' bulunur. Çözüm türlerinin dağılımını analiz etmek, gelen raporların kalitesi ve çözüm sürecinin etkinliği hakkında bilgi sağlayabilir. Örneğin, yüksek sayıda 'Duplicate' çözümü, olay oluşturma veya önceliklendirme aşamasında bir soruna işaret edebilir.
Neden önemli
Bir olayın sonucuna bağlam sağlar, çözümleri kategorize etmeye ve olayların nasıl kapatıldığına dair eğilimleri belirlemeye yardımcı olur.
Nereden alınır
Bir Jira kaydındaki standart 'Resolution' alanı. Bu alan tipik olarak bir kayıt 'Done' durum kategorisine geçirildiğinde ayarlanır.
Örnekler
TamamlandıÇözüldüKopyaDüzeltilmeyecek
|
|||
|
Çözüm Süresi Hedefi
TimeToResolutionTarget
|
Olayı çözmek için SLA hedef süresi. | ||
|
Açıklama
Bu öznitelik, belirli bir öncelik veya türdeki bir olayın çözülmesi gereken beklenen maksimum süreyi tanımlar. Gerçek çözüm süresinin SLA uyumluluğunu belirlemede bir kıyaslama noktası olarak kullanılır. Bu değer genellikle öncelik, ciddiyet veya sorun türü gibi faktörler dikkate alınarak kurallara göre dinamik olarak belirlenir. Her SLA performans izleme Dashboard'unun temel bir bileşenidir.
Neden önemli
SLA uyumluluğunu ölçmek için bir referans noktası sağlar ve Olay SLA İhlal Oranı KPI'ının temelini oluşturur.
Nereden alınır
Bu, Jira Service Management içindeki SLA yapılandırmasından türetilmiştir. Belirli hedef (örn. 'Time to resolution') belirlenmelidir.
Örnekler
4h8h3d
|
|||
|
Devir Sayısı
HandoffCount
|
Olayın farklı bir gruba veya kullanıcıya yeniden atanma sayısı. | ||
|
Açıklama
Bu hesaplanmış metrik, olayın yaşam döngüsü boyunca 'Assignee' veya 'AssignmentGroup' alanının kaç kez değiştiğini sayar. Yüksek bir devir sayısı genellikle süreç verimsizliği, ilk aramada çözüm eksikliği veya bilgi boşluklarını gösterir ve daha uzun çözüm sürelerine yol açar. Bu KPI'ın analizi, atama sürecini düzenlemeye ve ekip iş birliğini geliştirmeye yardımcı olur.
Neden önemli
Yeniden atamaların neden olduğu süreç sürtünmesini ve verimsizliği nicelleştirerek süreç iyileştirme fırsatlarının belirlenmesine yardımcı olur.
Nereden alınır
Sorun değişiklik günlüğündeki 'Atanan Kişi' veya 'Atama Grubu' alanındaki değişiklik sayısı sayılarak hesaplanır.
Örnekler
015
|
|||
|
İlişkili Sorun ID
LinkedProblemId
|
Bu olaya bağlı olan bir problem kaydının tanımlayıcısı. | ||
|
Açıklama
Daha büyük, temel bir sorunun belirtileri olan vakalar genellikle bir Problem kaydına bağlıdır. Bu alan, ilgili Problemin kimliğini (ID) saklar. Bu bağlantıları analiz etmek, vakalar ve problemler arasındaki ilişkiyi anlamaya, problem yönetimi sürecinin etkinliğini ölçmeye ve kalıcı bir düzeltme gerektiren tekrarlayan vakaları belirlemeye yardımcı olur.
Neden önemli
Olayları temel sorunlara bağlar, kuruluşun gelecekteki olayları önlemek için temel nedenleri ne kadar etkili bir şekilde ele aldığını analiz etmeyi sağlar.
Nereden alınır
Bu bilgi, bir Jira sorununun 'Issue Links' bölümünde saklanır.
Örnekler
PROB-123PROB-456Yok
|
|||
|
Kök Neden Kategorisi
RootCauseCategory
|
Olayın temel kök nedeninin sınıflandırması. | ||
|
Açıklama
Bu öznitelik, olayın neden meydana geldiğinin temel nedenini, örneğin 'Yazılım Hatası', 'Donanım Arızası' veya 'Kullanıcı Hatası' gibi, yakalar. Genellikle araştırmadan sonra doldurulur ve etkili problem yönetimi ile gelecekteki olayların önlenmesi için esastır. Kök neden kategorilerini analiz etmek, sistematik zayıflıkları belirlemeye ve iyileştirme girişimlerini önceliklendirmeye yardımcı olur. Yüksek oranda 'Unknown' kök neden, daha iyi araştırma süreçlerine olan ihtiyaca işaret edebilir.
Neden önemli
Temel neden analizini mümkün kılarak, olayların kaynaklarını belirleyerek ve ele alarak reaktif bir yaklaşımdan proaktif bir yaklaşıma geçişe yardımcı olur.
Nereden alınır
Bu neredeyse her zaman Jira'da özel bir alandır. Adı ve seçenekleri, kuruluşun özel yapılandırmasına büyük ölçüde bağlıdır.
Örnekler
Yapılandırma HatasıAğ KesintisiYazılım Hatası
|
|||
|
Müşteri Talep Türü
CustomerRequestType
|
Müşteri tarafından hizmet portalı aracılığıyla gönderilen belirli istek türü. | ||
|
Açıklama
Bu alan, Jira Service Management portalında sunulduğu gibi müşteri bakış açısından istekleri kategorize eder (örn. 'Sistem sorunu bildir'). Dahili 'Sorun Tipi'nden farklılık gösterebilen, olayın kullanıcı dostu bir sınıflandırmasını sunar. Bu özniteliği analiz etmek, müşterilerin sorunları nasıl algıladığı ve bildirdiğine dair içgörüler sunarak portal tasarımını ve hizmet tekliflerini iyileştirmeye yardımcı olabilir.
Neden önemli
Müşteri odaklı bir olay kategorileri görünümü sunarak, talep analizi ve müşteri deneyimini iyileştirmek için fayda sağlar.
Nereden alınır
Jira Service Management projelerine özgü 'Müşteri Talep Türü' alanı.
Örnekler
BT yardımı alın > Bir sistem sorunu bildirinE-posta > Erişim talebi
|
|||
|
Şiddet
Severity
|
Olayın iş etkisinin ölçüsü. | ||
|
Açıklama
Önem derecesi, bir olayın iş üzerindeki etkisini, tek bir kullanıcının etkilenmesinden kritik bir sistem kesintisine kadar tanımlar. Öncelik işin sırasını belirlerken, Önem derecesi genel iş etkisini bildirir. Önem derecesine göre analiz yapmak, iş için en önemli olayların süreç performansını anlamaya yardımcı olur ve daha incelikli bir analiz için genellikle Öncelik ile birlikte kullanılır.
Neden önemli
İş etkisi görünümü sunarak, işletme operasyonlarına en çok zarar veren olaylara odaklanmış analiz yapılmasına olanak tanır.
Nereden alınır
Genellikle Jira'da standart bir sistem alanı olmadığı için özel bir alandır. Jira Service Management proje yapılandırmasını inceleyin.
Örnekler
KritikBüyükKüçükÖnemsiz
|
|||
|
SLA İhlali
SlaBreach
|
Olay çözüm süresinin SLA hedefini aşıp aşmadığını gösteren bir işaret. | ||
|
Açıklama
Bu hesaplanmış boolean öznitelik, bir olayın 'Çözüm Süresi' SLA'sını ihlal edip etmediğini gösterir. 'IncidentResolutionCycleTime' değeri 'TimeToResolutionTarget' değerinden büyükse doğrudur. Bu işaretçi, genel SLA İhlal Oranı KPI'ını hesaplamak için kolay filtreleme ve birleştirmeye olanak tanıyarak, analizi ve görselleştirmeyi basitleştirir. SLA Performans İzleme Dashboard'unun temel sonuç metriğidir.
Neden önemli
SLA performansı için net, ikili bir sonuç sunarak ihlal oranlarını hesaplamayı ve sorunlu alanları belirlemeyi kolaylaştırır.
Nereden alınır
('OlayÇözümDöngüSüresi' > 'ÇözümeUlaşmaHedefSüresi') olarak hesaplanır.
Örnekler
truefalse
|
|||
|
Vaka Tipi
IssueType
|
Olay, Hizmet Talebi veya Problem gibi kayıt türü. | ||
|
Açıklama
Jira, farklı görev türlerini ayırt etmek için Talep Türleri kullanır. Bir Olay Yönetimi bağlamında, birincil tür 'Olay' iken, 'Alt Görev' gibi diğer türler de alakalı olabilir. Bu nitelik, veri kümesini yalnızca olayları içerecek şekilde filtrelemek için çok önemlidir ve işlem madenciliği analizinin doğru sürece odaklanmasını sağlar.
Neden önemli
Analizin olaylara doğru şekilde odaklanmasını, onları hizmet talepleri veya değişiklikler gibi diğer iş türlerinden ayırmasını sağlar.
Nereden alınır
Bir Jira kaydındaki standart 'Issue Type' alanı.
Örnekler
OlayBT YardımıHata
|
|||
|
Yeniden İşleme mi?
IsRework
|
Olayın yeniden açılma gibi bir yeniden işleme tabi tutulup tutulmadığını gösteren bir işaret. | ||
|
Açıklama
Bu hesaplanmış boolean öznitelik, sürecin önceki bir aşamasına geri gönderilen, en yaygın olarak çözümlendikten sonra yeniden açılan olayları belirler. Yeniden işleme döngüleri, önemli bir verimsizlik ve müşteri memnuniyetsizliği kaynağıdır. Bu işaret, yeniden işleme oranının kolayca ölçülmesini sağlar ve olayların ilk seferde neden doğru çözülemediğine dair analizin odaklanmasına yardımcı olur.
Neden önemli
Tekrarlanan iş gerektiren olayları işaretleyerek süreç kalitesi sorunlarını ve verimsizlikleri vurgular, yeniden işleme analizini doğrudan destekler.
Nereden alınır
Olay günlüğündeki 'Çözüldü' -> 'Yeniden Açıldı' gibi belirli durum geçiş dizileri tespit edilerek hesaplanır.
Örnekler
truefalse
|
|||
Incident Management Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm Önerildi
|
Bu etkinlik, bir çözümün belirlendiğini ve uygulandığını, olayın ise onay veya nihai doğrulama beklediğini belirtir. Bu durum, 'Resolved' durumuna geçişten çıkarılır. | ||
|
Neden önemli
Bu, destek ekibi tarafından aktif çalışmanın sonunu işaret eden önemli bir kilometre taşıdır. Genellikle SLA saatini durduran event'tir.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olayın zaman damgası, durumun 'Çözüldü' veya eşdeğer bir duruma geçtiği zamandır.
Yakala
Durumun 'Çözüldü'ye geçişinin timestamp'ini belirleyin.
Event tipi
inferred
|
|||
|
Müşteri Bekleniyor
|
Destek ekibinin müşteriden bilgi veya eylem beklediği bir noktayı işaret eder. Bu, 'Müşteri Bekleniyor' gibi özel bir bekleme durumuna geçişten çıkarılır. | ||
|
Neden önemli
Bu 'beklemede' süresini izole etmek, genellikle çözüm süresi hesaplamalarından hariç tutulduğu için doğru SLA ölçümü açısından kritiktir. Müşteri yanıt gecikmelerini analiz etmeye yardımcı olur.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olay, durumun 'Müşteri Bekleniyor' veya benzeri bir duruma değiştiği zaman damgasına karşılık gelir.
Yakala
Durumun 'Müşteri Bekleniyor'a geçişinin timestamp'ini belirleyin.
Event tipi
inferred
|
|||
|
Olay Çözüldü
|
Bu etkinlik, olayın başarıyla çözüldüğünü ve hizmetin geri yüklendiğini onaylar. Genellikle 'Resolved' durumuna geçişle çakışır. | ||
|
Neden önemli
Bu, sürecin birincil başarı kilometre taşıdır. Bu noktaya kadar olan süre, 'Time to Resolution (TTR)'ı temsil eden en yaygın KPI'dır.
Nereden alınır
'Çözüldü' durum değişikliğinden çıkarım yapılır. Birçok iş akışında bu, ana çözüm noktasını temsil eden 'Çözüm Önerildi' olayıyla aynıdır.
Yakala
Durumun 'Çözüldü'ye geçişinin timestamp'ini belirleyin.
Event tipi
inferred
|
|||
|
Olay Kapatıldı
|
Olay talepinin çözülüp doğrulandıktan sonraki son, idari kapanışını temsil eder. Bu durum, statünün 'Kapalı'ya geçişinden çıkarılır. | ||
|
Neden önemli
Bu, sürecin son event'idir. 'Resolved' ve 'Closed' arasındaki süreyi analiz etmek, idari temizlik veya kullanıcı onay süreçlerindeki gecikmeleri ortaya çıkarabilir.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olay, durumun nihai 'Kapalı' durumuna geçtiği zaman damgasına karşılık gelir.
Yakala
Durumun 'Kapalı'ya geçişinin timestamp'ini belirleyin.
Event tipi
inferred
|
|||
|
Olay Oluşturuldu
|
Bir olay raporu gönderildiğinde ve Jira'da yeni bir talep oluşturulduğunda, olay yaşam döngüsünün resmi başlangıcını işaret eder. Bu olay, sistemde 'Olay' türünde yeni bir talep kaydedildiğinde açıkça yakalanır. | ||
|
Neden önemli
Bu, sürecin birincil başlangıç event'idir. Bu aktiviteden çözüme kadar geçen süreyi analiz etmek, genel cycle time ve SLA uyumunu ölçmek için temeldir.
Nereden alınır
Bu, Jira'daki olay sorununa ait 'created' timestamp'inden yakalanan açık bir event'tir. Sorun oluşturma event'i, sorunun geçmişine kaydedilir.
Yakala
Olay oluşturma timestamp'ini kullanın.
Event tipi
explicit
|
|||
|
Olay Yeniden Atandı
|
Bir olay, ilk atamadan sonra bir temsilciden veya gruptan diğerine aktarıldığında meydana gelir. Bu olay, 'Atanan Kişi' veya 'Atanan Grup' alanındaki herhangi bir değişiklikten çıkarılır. | ||
|
Neden önemli
Yeniden atamaları takip etmek, devir analizi için hayati öneme sahiptir. Yüksek sayıda yeniden atama, genellikle süreç verimsizliklerini, bilgi boşluklarını veya yanlış başlangıç yönlendirmesini göstererek çözüm gecikmelerine yol açar.
Nereden alınır
Vaka geçmişinden, 'Atanan' alanının ilk doldurulmasından sonraki herhangi bir güncellemeyi tespit ederek çıkarım yapılır. Her değişiklik bir yeniden atama olayı teşkil eder.
Yakala
İlk atamadan sonra 'Atanan' alanındaki sonraki değişiklikleri belirleyin.
Event tipi
inferred
|
|||
|
Soruşturma Başladı
|
Atanmış bir temsilcinin vakanın teşhisi üzerinde aktif olarak çalışmaya başladığını gösterir. Bu durum genellikle, vakanın durumu 'Açık' veya 'Yeni'den 'Devam Ediyor'a geçtiğinde çıkarım yoluyla anlaşılır. | ||
|
Neden önemli
Bu önemli kilometre taşı, aktif çözüm çabalarının başlangıcını işaret eder. Bu aktiviteye kadar geçen süreyi ölçmek, ilk kuyruk gecikmelerini ve kaynak kullanılabilirliği sorunlarını belirlemeye yardımcı olur.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olayın zaman damgası, durumun 'Devam Ediyor' gibi aktif çalışmayı temsil eden bir duruma geçtiği zamandır.
Yakala
Durumun 'Devam Ediyor'a geçişinin timestamp'ini belirleyin.
Event tipi
inferred
|
|||
|
Geçici Çözüm Sağlandı
|
Kalıcı bir çözüm geliştirilirken hizmeti geri yüklemek için geçici bir düzeltme uygulamasını temsil eder. Bu, bir statü değişikliğinden veya belirli bir yorumdan çıkarılabilir. | ||
|
Neden önemli
Geçici bir çözüm sağlama süresini ölçmek, hizmet restorasyon hızının önemli bir göstergesidir. Geçici hafifletme ile kalıcı çözüm arasındaki farkı ayırt etmeye yardımcı olur.
Nereden alınır
Bu genellikle çıkarılır. Bir 'Workaround Provided' durumuna geçiş veya 'workaround' gibi belirli anahtar kelimeler içeren genel bir yorumun eklenmesi olabilir.
Yakala
Bir yorumdaki belirli bir durum geçişini veya anahtar kelimeyi belirleyin.
Event tipi
inferred
|
|||
|
Müşteri Yanıtladı
|
Müşterinin talep edilen bilgiyi sağladığını ve vakanın devam edebileceğini gösterir. Bu durum, statünün 'Müşteri Bekleniyor'dan tekrar aktif bir statüye geçmesiyle anlaşılır. | ||
|
Neden önemli
Bu etkinlik, müşteriden kaynaklanan bir gecikmenin sona erdiğini işaret eder. 'Waiting For Customer' ile bu olay arasındaki süreyi analiz etmek, ortalama müşteri yanıt süresini ortaya çıkarır.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olay, durum 'Müşteri Bekleniyor'dan 'Devam Ediyor' gibi bir duruma geçtiğinde meydana gelir ve genellikle müşterinin bir yorum eklemesiyle tetiklenir.
Yakala
'Müşteri Bekleniyor' durumundan 'Devam Ediyor' durumuna geçişi tespit edin.
Event tipi
inferred
|
|||
|
Olay Atandı
|
Bu etkinlik, olayın ele alınmak üzere bir destek temsilcisine veya gruba ilk atanmasını gösterir. Bu durum, 'Assignee' veya 'Assigned Group' alanının ilk kez doldurulmasının takip edilmesiyle yakalanır. | ||
|
Neden önemli
SLA metriklerinin temel bir bileşeni olan ilk yanıt ve atama süresini ölçer. Aktif soruşturma başlamadan önceki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
Vaka geçmişinden, 'Atanan' alanındaki önceki değeri 'Atanmamış' olan ilk değişikliği belirleyerek çıkarım yapılır.
Yakala
Sorun geçmişindeki 'Atanan Kişi' alanındaki ilk güncellemeyi tespit edin.
Event tipi
inferred
|
|||
|
Olay Önceliklendirildi
|
Bir olayın önceliğinin ve/veya önem derecesinin belirlenmesini temsil eder; bu da olayın aciliyetini ve iş üzerindeki etkisini belirler. Bu genellikle, oluşturmadan sonra 'Öncelik' veya 'Önem Derecesi' alanlarının ilk kez doldurulması veya güncellenmesinden çıkarılır. | ||
|
Neden önemli
Önceliklendirmeyi takip etmek, olayların hızlı ve tutarlı bir şekilde değerlendirilip değerlendirilmediğini analiz etmeye yardımcı olur. Bu adımdaki gecikmeler, SLA hesaplamalarını ve kaynak tahsisini doğrudan etkileyebilir.
Nereden alınır
Tüm alanlardaki değişiklikleri izleyen vaka geçmişi logundan çıkarım yapılır. Sorun oluşturma olayından sonra 'Öncelik' veya özel bir 'Ciddiyet' alanındaki ilk güncellemeyi arayın.
Yakala
Sorun geçmişindeki 'Öncelik' alanındaki ilk değişikliği tespit edin.
Event tipi
inferred
|
|||
|
Olay Yeniden Açıldı
|
Daha önce çözülmüş bir olayın, sorunun tekrar etmesi veya çözümün etkisiz olması nedeniyle yeniden etkinleştirildiği bir durumu temsil eder. Bu durum, statüde 'Çözüldü' veya 'Kapalı'dan açık bir statüye geri dönülmesiyle çıkarılır. | ||
|
Neden önemli
Yeniden açılan olaylar, çözüm kalitesinin doğrudan bir ölçüsü ve yeniden işlemenin temel bir göstergesidir. Bu olayları analiz etmek, erken kapanışları ve etkisiz çözümleri belirlemeye yardımcı olur.
Nereden alınır
Vakanın durum değişikliği geçmişinden çıkarım yapılır. Olay, durum 'Çözüldü' veya 'Kapalı' gibi bir nihai durumdan 'Açık' veya 'Devam Ediyor' gibi bir duruma geri döndüğünde kaydedilir.
Yakala
'Çözüldü' veya 'Kapalı' durumundan açık bir duruma geçişi tespit edin.
Event tipi
inferred
|
|||
|
Sorun Talebine Bağlı
|
Bir olayın, kök neden analizi için bir 'Problem' talebiyle ilişkilendirildiğinde meydana gelir. Bu, bir Problem talep türüne 'ilişkili' veya 'neden olan' bağlantısı oluşturulduğunda açıkça yakalanan bir olaydır. | ||
|
Neden önemli
Bu bağlantıyı takip etmek, kuruluşun olay hafifletmeden kök neden analizi ve önlemeye ne kadar etkili geçiş yaptığını anlamak için esastır.
Nereden alınır
Bu, sorunun bağlantı geçmişine kaydedilen açık bir event'tir. Her bağlantı oluşturmanın bir timestamp'i vardır ve 'Sorun' olay tipine verilen bağlantılar için filtrelenebilir.
Yakala
Bir 'Problem' olay tipine bir olay linki oluşturma timestamp'ini kullanın.
Event tipi
explicit
|
|||
|
Uzman Ekibe Yönlendirildi
|
Olayın gelişmiş destek için özel bir ekibe (örneğin, 2. Seviye, Geliştirme) aktarıldığını gösterir. Bu durum, özel bir 'Destek Ekibi' alanındaki değişiklikten veya belirli bir yeniden atamadan çıkarılır. | ||
|
Neden önemli
Uzmanlık gerektiren olayları vurgular ve farklı destek seviyeleri arasındaki akışı izler. Bu, uzman ekiplerdeki darboğazları belirlemeye ve yönlendirme kalıplarını analiz etmeye yardımcı olur.
Nereden alınır
Vaka geçmişinden, atanmış ekibi temsil eden özel bir alandaki değişiklikleri izleyerek veya bilinen bir uzman grubunun üyesine yapılan bir 'Atanan' değişikliğini belirleyerek çıkarım yapılır.
Yakala
'Atanan Ekip' için özel bir alandaki değişikliği veya belirli atanan kişi değişikliklerini tespit edin.
Event tipi
inferred
|
|||
|
Yorum Eklendi
|
Bir kullanıcının olay talepine bir yorum eklediği herhangi bir iletişim veya not alma olayını temsil eder. Bu, her yorum gönderildiğinde yakalanan açık bir olaydır. | ||
|
Neden önemli
Yorum sıklığını analiz etmek, iletişim modelleri, işbirliği verimliliği ve bir olayın karmaşıklığı hakkında fikir verebilir. Aşırı iletişim gerektiren olayları vurgulayabilir.
Nereden alınır
Bu, açık bir event'tir. Jira, her yorumu bir timestamp ve yazar ile saklar, bunlar sorunun yorum geçmişi veya API aracılığıyla erişilebilir.
Yakala
Olay'a eklenen her yorumun timestamp'ini kullanın.
Event tipi
explicit
|
|||