Data Template: Olay Yönetimi
Olay Yönetimi Veri Template'iniz
Bu, Olay Yönetimi süreci için genel Process Mining veri şablonumuzdur. Daha özel rehberlik için sisteme özel şablonlarımızı kullanın.
Belirli bir sistem seçin- Herhangi bir olay yönetimi sistemi için evrensel data structure
- Kapsamlı analiz için önerilen öznitelikler ve aktiviteler.
- Sisteme özel örnekler dahil olmak üzere veri çıkarma hakkında rehberlik
Olay Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
Faaliyet Adı ActivityName | Olayın yaşam döngüsü sırasında gerçekleşen belirli bir iş aktivitesi, event veya durum değişikliğinin adı. | ||
Açıklama Aktivite Adı, olay yönetimi sürecinin bir parçası olarak gerçekleştirilen belirli bir adımı veya görevi tanımlar. Bu aktiviteler, süreç haritasının yapı taşlarını temsil eder ve 'SLA İhlali Tespit Edildi' gibi otomatik sistem event'lerini veya 'Temsilci Atandı' veya 'Geçici Çözüm Sunuldu' gibi manuel kullanıcı eylemlerini içerebilir. Process Mining analizi için bu öznitelik temel niteliktedir. Süreç grafiğindeki düğümleri tanımlayarak, analistlerin iş akışını görselleştirmelerine, yaygın yolları belirlemelerine, darboğazları keşfetmelerine ve standart prosedürden sapmaları analiz etmelerine olanak tanır. Aktivite adlarının ayrıntı düzeyi ve netliği, elde edilebilecek içgörülerin kalitesini ve derinliğini doğrudan etkiler. Neden önemli Bu öznitelik, süreçteki adımları tanımlayarak olay yaşam döngüsü akışının görselleştirilmesini ve analizini sağlar. Nereden alınır Genellikle olay yönetimi sistemi içindeki event logları, denetim izleri, durum değişikliği kayıtları veya görev açıklama alanlarının birleşiminden türetilir. Örnekler Olay OluşturulduGrup AtandıOlay ÇözüldüDurum "Beklemede" Olarak Değiştirildi | |||
Olay Kimliği IncidentId | Her olaya atanan benzersiz tanımlayıcı. Bu ID, bir olayı tüm yaşam döngüsü boyunca izlemek için birincil anahtar görevi görür. | ||
Açıklama Incident ID, sistemdeki bir olayı diğer tüm olaylardan ayıran benzersiz bir alfasayısal koddur. Yeni bir olay oluşturulduğunda üretilir ve olay kalıcı olarak arşivlenene veya silinene kadar sabit kalır. Process Mining'de, Incident ID, Case ID olarak hizmet ederek analizin temel taşını oluşturur. Yazılımın ilgili tüm eventleri, durum değişikliklerini ve aktiviteleri tek, tutarlı bir süreç örneğinde bir araya getirmesini sağlar. Tüm eventleri ortak bir Incident ID altında gruplayarak, analistler her olayın ilk raporundan nihai çözümüne ve kapanışına kadar olan uçtan uca yolculuğunu doğru bir şekilde haritalandırabilir. Neden önemli Process Mining için uçtan uca olay yaşam döngüsünü yeniden yapılandırmak üzere tüm ilgili faaliyetleri ve event'leri birbirine bağlamak esastır. Nereden alınır Bu, bir olay için birincil anahtardır ve genellikle her olay tablosu veya nesnesinin başlığında veya ana kaydında bulunur. Örnekler INC0010032TICKET-84321789456123 | |||
Olay Zaman Damgası EventTimestamp | Bir olay için belirli bir aktivite veya eventin gerçekleştiği kesin tarih ve saat. | ||
Açıklama Olay Zaman Damgası, bir aktivitenin gerçekleştiği anı işaretler. Bir olayın yaşam döngüsündeki her aktivite, kronolojik bir event dizisi oluşturmak için ilgili bir zaman damgasına sahip olmalıdır. Bu öznitelik, zaman tabanlı herhangi bir Process Mining analizi için kritiktir. Aktiviteler arasındaki döngü sürelerinin, belirli adımların süresinin ve genel olay çözüm süresinin hesaplanmasını sağlar. Zaman damgalarını analiz ederek, kurumlar darboğazları tespit edebilir, SLA'lara uyumu ölçebilir ve süreç performansının zamanla nasıl değiştiğini anlayabilir. Ortalama Çözüm Süresi gibi temel performans göstergelerini hesaplamanın temelini oluşturur. Neden önemli Event'lerin kronolojik sırasını sağlar; bu da süreleri hesaplamak, bottleneck'leri belirlemek ve süreç performansını zaman içinde analiz etmek için esastır. Nereden alınır Event log'larda, audit history table'larında veya belirli ilgili kayıtlarda 'son değiştirilme' veya 'oluşturulma tarihi' olarak bulunur. Örnekler 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
Kaynak Sistem SourceSystem | Olay verisinin ayıklandığı sistemin adı veya tanımlayıcısı. | ||
Açıklama Kaynak Sistem özniteliği, verinin kaynağını belirler. Birden fazla ITSM aracı veya entegre sistemlerin bulunduğu ortamlarda, bu alan farklı kaynaklardan gelen kayıtları ayırt etmeye yardımcı olur. Süreç haritası çiziminde doğrudan kullanılmasa da, bu öznitelik, veri doğrulama ve yönetişim için değerlidir. Analistlerin veriyi kaynağına kadar izlemelerine, sistemler arasındaki potansiyel tutarsızlıkları anlamalarına ve analizi segmentlere ayırmalarına yardımcı olur. Örneğin, aynı organizasyon içinde ServiceNow ve Jira gibi iki farklı sistemde uygulanan olay yönetimi süreçleri karşılaştırılabilir. Neden önemli Verinin kaynağına dair bağlam sağlar, bu da çok sistemli ortamlarda veri doğrulama, sorun giderme ve karşılaştırmalı analiz için çok önemlidir. Nereden alınır Bu genellikle veri çıkarma süreci sırasında eklenen statik bir değer veya kaynak sistemin tablolarında bulunan bir alandır. Örnekler ServiceNowJira Hizmet YönetimiBMC HelixZendesk | |||
Son Veri Güncellemesi LastDataUpdate | Bu kaydın verisinin kaynak sistemden en son yenilendiği timestamp. | ||
Açıklama Son Veri Güncelleme zaman damgası, verinin kaynak sistemden en son ne zaman ayıklandığını veya senkronize edildiğini belirtir. Bu, analiz edilen verinin güncelliğini yansıtan bir metadata alanıdır. Process Mining analizinde, bu öznitelik üretilen içgörülerin güncelliğini anlamak için önemlidir. Kullanıcıların gerçek zamanlı bilgi mi yoksa geçmiş bir zamana ait anlık bir görüntüye mi baktıklarını bilmelerine yardımcı olur. Bu bağlam, operasyonel izleme ve kararların güncel, ilgili verilere dayanmasını sağlamak için hayati öneme sahiptir. Neden önemli Verilerin güncelliğini gösterir ve analistlerin süreç analizlerinin ne kadar yeni olduğunu anlamalarını sağlar. Nereden alınır Bu değer, genellikle veri çıkarma ve dönüştürme (ETL) süreci sırasında her kayda oluşturulur ve damgalanır. Örnekler 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
Atanan Grup AssignedGroup | Halihazırda olay üzerinde çalışmaktan sorumlu destek ekibi, sırası veya grubu. | ||
Açıklama Atanan Grup, herhangi bir zamanda olaydan hangi ekibin sorumlu olduğunu gösterir. Olaylar genellikle Seviye 1 Servis Masası, Seviye 2 Ağ ekibi veya Seviye 3 Uygulama Destek ekibi gibi farklı gruplar arasında yönlendirilir. Bu öznitelik, devir ve iş yükü analizi için çok önemlidir. Process Mining, bu verileri kullanarak olayların ekipler arasındaki akışını görselleştirebilir, her ekibin kuyruğunda harcanan süreyi ölçebilir ve sık yeniden atamalardan kaynaklanan darboğazları tespit edebilir. Ekip verimliliği ve işbirliği hakkındaki soruları yanıtlamaya yardımcı olur ve Devir ve Yeniden Atama Analizi Dashboard'ının temelini oluşturur. Neden önemli Ekipler arası aktarımları analiz etmek, kuyruk sürelerini ölçmek ve ekibe özel performans ve iş yükü dağılımını anlamak için kritik öneme sahiptir. Nereden alınır Bu bilgi genellikle olay kaydında saklanır ve olay her yeni bir ekibe atandığında güncellenir. Örnekler Service DeskAğ OperasyonlarıVeritabanı YönetimiUygulama Destek Seviyesi 2 | |||
Atanan Temsilci AssignedAgent | Olayı ele almak üzere atanan bireysel destek temsilcisi veya kullanıcı. | ||
Açıklama Atanan Temsilci, bir olaydan sorumlu belirli kişiyi tanımlar. Atanan Grup ekibi işaret ederken, temsilci çözüm üzerinde çalışan bireysel kişidir. Bu öznitelik, daha ayrıntılı düzeyde performans ve iş yükü analizi yapılmasına olanak tanır. Temsilci düzeyinde atamaları izleyerek, yöneticiler bireysel üretkenliği değerlendirebilir, eğitim ihtiyaçlarını belirleyebilir ve dengeli bir iş dağılımı sağlayabilir. Process Mining'de, grup düzeyinde gizli kalabilecek karmaşık yeniden atama kalıplarını ortaya çıkarabilir ve çözüm sürelerine bireysel katkıları anlamaya yardımcı olur. Neden önemli Ekipler içinde veya ekipler arasında bireysel iş yükü, performans ve yeniden atama kalıplarının ayrıntılı analizini sağlar. Nereden alınır Ana olay kaydında bulunur, bu alan bir agent sahiplendiğinde veya olaya atandığında güncellenir. Örnekler Can DemirAyşe Yılmazagent.12345Emily Jones | |||
Çözüm Yöntemi ResolutionMethod | Olayın sonunda nasıl çözüldüğünü belirten bir kod, kategori veya açıklama. | ||
Açıklama Çözüm Yöntemi, olayın sonucunu ve nasıl çözüldüğünü açıklar. Bu, standartlaştırılmış bir kod veya yapılan eylemlerin serbest metin açıklaması olabilir. Örnekler arasında 'Kullanıcı eğitimi', 'Yazılım yaması uygulandı', 'Hata bulunamadı' veya 'Yinelenen olay' bulunur. Bu öznitelik, sürecin sonuna hayati bağlam sağlar. Process Mining'de, olayları çözüm yöntemlerine göre analiz etmek, farklı çözümlerin etkinliğini anlamaya yardımcı olur. Gerçek bir düzeltme yapılmadan kapatılan durumları vurgulayabilir veya belirli olay kategorileri için yaygın çözüm kalıplarını belirleyebilir; bu da bir bilgi tabanı oluşturmak ve İlk Temasta Çözüm oranlarını iyileştirmek için kullanılabilir. Neden önemli Sorunların nasıl çözüldüğüne dair içgörü sunar; bu da otomasyon, bilgi tabanı iyileştirme ve eğitim fırsatlarını belirlemek için anahtardır. Nereden alınır Genellikle bir olayın 'Resolved' veya 'Closed' durumuna taşınması üzerine destek temsilcisi tarafından doldurulan bir alan. Örnekler Service Desk Tarafından ÇözüldüHata BulunamadıYinelenenYazılım Güncellemesi Dağıtıldı | |||
Olay Durumu IncidentStatus | Olayın yaşam döngüsü içindeki mevcut veya geçmiş durumu, örneğin 'Yeni', 'Devam Ediyor' veya 'Kapalı'. | ||
Açıklama Olay Durumu, bir olayın belirli bir zaman noktasındaki aşamasını gösterir. Olayın çözüm sürecinde nerede olduğuna dair üst düzey bir görünüm sağlar. Yaygın durumlar arasında 'yeni', 'atanmış', 'devam ediyor', 'beklemede', 'çözüldü' ve 'kapalı' bulunur. Bu öznitelik, süreç analizi için temeldir, çünkü durumdaki değişiklikler genellikle süreç haritasındaki aktiviteleri tanımlar. Her durumda harcanan sürenin analiz edilmesi, örneğin 'Beklemede' durumunda uzun süreler bekleyen olaylar gibi darboğazları tespit etmeye yardımcı olur. Ayrıca açık olayların birikimini hesaplamak ve çözüme yönelik ilerlemeyi takip etmek için de kullanılır. Neden önemli Olayın ilerlemesini anlamak için kilit öneme sahiptir ve genellikle süreç haritası için faaliyetler oluşturmak amacıyla kullanılır. Her bir durumda harcanan zamanı analiz etmek gecikmeleri bulmaya yardımcı olur. Nereden alınır Genellikle ana olay kaydında birincil alan olarak veya olayın geçmiş logunda (kayıtlarında) bulunur. Örnekler YeniDevam EdiyorMüşteri BekleniyorÇözüldüKapalı | |||
Olay Kategorisi IncidentCategory | Genellikle hiyerarşik bir yapıda (örn. Donanım > Dizüstü Bilgisayar > Pil) düzenlenen olayın sınıflandırması. | ||
Açıklama Olay Kategorisi, olayları niteliklerine göre sınıflandırmak için yapılandırılmış bir yol sunar. Bu, genellikle giderek daha ayrıntılı sınıflandırmaya olanak tanıyan hiyerarşik bir alandır ve olayları raporlama ve analiz için mantıksal gruplara ayırmaya yardımcı olur. Kategorizasyon, kök neden ve eğilim analizi için hayati öneme sahiptir. Kategoriye göre filtrelenmiş süreç haritaları analiz edilerek, kurumlar belirli olay türleriyle ilişkili tekrarlayan sorunları ve kalıpları tespit edebilir. Örneğin, bir 'Yazılım' olayının çözüm süreci, bir 'Donanım' olayından çok farklı görünebilir. Bu veriler, Başlangıç Kategorizasyon Doğruluğu ve Tekrarlayan Olay Oranı gibi KPI'ları besler. Neden önemli Kök neden analizi yapmak, yinelenen olaylardaki eğilimleri belirlemek ve farklı sorun türlerinin nasıl ele alındığını anlamak için hayati öneme sahiptir. Nereden alınır Bu, sınıflandırma için kullanılan olay kaydı üzerindeki standart, genellikle zorunlu bir alanlar kümesidir. Örnekler Yazılım | Uygulama | Giriş SorunuHardware | Printer | Not RespondingAğ | Wi-Fi | Yavaş Bağlantı | |||
Öncelik Priority | Olayın atanmış öncelik seviyesi, çözümün aciliyetini ve sırasını belirler. | ||
Açıklama Öncelik, bir olayın göreceli önemini ve gerekli yanıt hızını belirlemek için kullanılan temel bir özniteliktir. Genellikle olayın etkisi ve aciliyetinin birleşiminden türetilir. Seviyeler genellikle kritiktan düşüğe doğru değişir. Process mining'de, olayları önceliğe göre analiz etmek, sürecin farklı aciliyet seviyelerini nasıl ele aldığını daha derinlemesine anlamayı sağlar. Analistler, SLA'ların karşılanıp karşılanmadığını ve kaynakların etkin bir şekilde tahsis edilip edilmediğini görmek için yüksek öncelikli olaylar ile düşük öncelikli olayların çözüm sürelerini karşılaştırabilirler. Bu, 'En kritik olaylarımızı gerçekten en hızlı şekilde mi ele alıyoruz?' gibi soruları yanıtlamaya yardımcı olur. Neden önemli Farklı aciliyet seviyeleri için süreç performansının analizini sağlar, kritik olayların kritik olmayanlara göre daha hızlı ele alınıp alınmadığını doğrulamaya yardımcı olur. Nereden alınır Ana olay kaydında standart bir alan olarak bulunur. Etki ve aciliyete göre manuel olarak belirlenebilir veya otomatik olarak hesaplanabilir. Örnekler 1 - Kritik2 - Yüksek3 - Orta4 - Düşük | |||
Raporlama Kanalı ReportingChannel | Olayın bildirildiği yöntem veya kanal, örneğin Email, Phone veya Self-Service Portal gibi. | ||
Açıklama Raporlama Kanalı, olay bildiriminin kaynağını gösterir. Bu öznitelik, kullanıcıların destek fonksiyonuyla telefon görüşmeleri gibi doğrudan iletişim yöntemleri veya sistem izleme uyarıları gibi otomatik yöntemler aracılığıyla nasıl etkileşimde bulunduğunu izler. Raporlama kanalına göre süreci analiz etmek, verimlilikte önemli farklılıkları ortaya çıkarabilir. Örneğin, bir self-service portalı aracılığıyla bildirilen olaylar, genellikle başlangıçta daha yapılandırılmış bilgi içerdiğinden daha hızlı çözülebilir. Bu analiz, kurumların destek kanallarını optimize etmelerine ve daha verimli yöntemlerin kullanımını teşvik etmelerine yardımcı olur. Neden önemli Olayların kaynaklarına göre verimliliklerini ve çözüm yollarını analiz etmeye yardımcı olur, bu da kanal stratejisi ve kaynak tahsisi hakkında bilgi sağlayabilir. Nereden alınır Bu bilgi genellikle olay oluşturulduğunda otomatik olarak yakalanır veya temsilci tarafından seçilir. Örnekler E-postaTelefonSelf-Service PortalSistem Uyarısı | |||
Şiddet Severity | Olayın kullanıcıları veya hizmetleri ne kadar önemli ölçüde etkilediğini gösteren, iş üzerindeki etkisinin ölçüsü. | ||
Açıklama Ciddiyet, bir olayın iş üzerindeki etki düzeyini tanımlar. Sorunun aciliyetinden bağımsız olarak ne kadar ciddi olduğunu yanıtlar. Örneğin, sistem genelinde bir kesinti yüksek ciddiyetli bir olayken, küçük bir görsel hata düşük ciddiyetli olacaktır. Olayları severity'ye göre analiz etmek, kuruluşların en çok kesintiye neden olan sorun türlerini anlamalarına yardımcı olur. Process Mining, yüksek ciddiyetli olayların farklı, daha akıcı bir çözüm yolu izleyip izlemediğini ortaya çıkarabilir. Bu öznitelik, kök neden analizi ve en ciddi olayların tekrarlanmasını önlemek için proaktif sorun yönetimi için kaynakları önceliklendirme açısından kritik öneme sahiptir. Neden önemli Olayları segmentlere ayırarak, yüksek etkili sorunların düşük etkili sorunlardan farklı veya daha verimli bir şekilde çözülüp çözülmediğini anlamaya yardımcı olur. Nereden alınır Olay kaydındaki standart bir alan olup, önceliği belirlemek amacıyla genellikle aciliyetle birlikte kullanılır. Örnekler 1 - Yüksek2 - Orta3 - DüşükKritik | |||
Etkilenen Hizmet AffectedService | Olaydan etkilenen iş hizmeti, uygulama veya yapılandırma öğesi (CI). | ||
Açıklama Etkilenen Hizmet, bir olayı bir iş uygulaması, sunucu veya ağ cihazı gibi BT altyapısındaki belirli bir bileşene bağlar. Bu genellikle bir Yapılandırma Yönetimi Veritabanı (CMDB) ile ilişkilidir. Bu öznitelik, olaya kritik iş bağlamı sağlar. Process Mining'de, belirli hizmetlerin veya varlıkların güvenilirliğine odaklanmış analize olanak tanır. Kuruluşlar, en çok olay üreten hizmetleri belirleyebilir, çözüm süreçlerini analiz edebilir ve kritik iş hizmetlerinin istikrarını iyileştirmek için sorun yönetimi çabalarını önceliklendirebilir. BT olaylarının daha geniş iş etkisini anlamak için temel bir unsurdur. Neden önemli Olayları belirli iş hizmetlerine veya BT bileşenlerine bağlayarak, hangi hizmetlerin sorunlara en yatkın olduğunu ve bunların etkilerinin ne olduğunu analiz etmeyi sağlar. Nereden alınır Genellikle bir Yapılandırma Yönetimi Veritabanı (CMDB) ile ilişkilendirilir veya olay formundaki bir hizmet kataloğu listesinden seçilir. Örnekler E-posta HizmetleriSAP ERP FinansCorporate VPNSRV-SQL-01 | |||
SLA Statüsü SlaStatus | Olayın Hizmet Seviyesi Anlaşması (SLA) hedefleri dahilinde olup olmadığını, risk altında olup olmadığını veya ihlal edip etmediğini gösterir. | ||
Açıklama SLA Durumu, bir olayın yanıt süresi veya çözüm süresi gibi önceden tanımlanmış zaman hedeflerine göre performansının anlık bir görüntüsünü sunar. 'Devam Ediyor', 'Risk Altında' veya 'İhlal Edildi' gibi yaygın durumları içerir. Bu öznitelik, hizmet kalitesinin doğrudan bir ölçütüdür ve SLA Performansına Genel Bakış dashboard'u için kritik bir girdidir. Process Mining'de, ihlal edilen ve ihlal edilmeyen olayların süreç akışlarını karşılaştırmaya olanak tanır. Bu, SLA ihlallerinin başlıca nedenleri olan belirli aktiviteleri, gecikmeleri veya yeniden işleme döngülerini belirleyerek hedeflenen süreç iyileştirme çalışmalarını destekler. Neden önemli Hedeflere karşı performansın doğrudan bir ölçüsüdür. İhlal edilen olayları analiz etmek, kötü hizmet sunumuna yol açan süreç hatalarını belirlemeye yardımcı olur. Nereden alınır Bu, tipik olarak ITSM aracı içinde olayın önceliği, yaşı ve tanımlanmış SLA kurallarına göre dinamik olarak güncellenen hesaplanmış bir alandır. Örnekler Devam EdiyorDuraklatıldıİhlal EdildiRisk Altında | |||
Talep Sahibi Requester | Olayı ilk bildiren kullanıcı, çalışan veya sistem. | ||
Açıklama Talep Sahibi, sorunu yaşayan ve olay raporunu başlatan kişidir. Bu, dahili bir çalışan veya harici bir müşteri olabilir. Bu öznitelik, talep sahibinin departmanını veya kurumunu da yakalayabilir. Olayları talep sahibine veya talep sahibi departmanına göre analiz etmek, belirli kullanıcı gruplarının diğerlerinden daha fazla sorun yaşayıp yaşamadığını tespit etmeye yardımcı olur. Bu durum, eğitim ihtiyaçlarına veya yerelleşmiş çevresel sorunlara işaret edebilir. Process Mining'de, destek sürecine kullanıcı merkezli bir bakış açısı sağlayarak, farklı kullanıcı gruplarının deneyimini anlamaya yardımcı olur. Neden önemli Kullanıcı merkezli bir analize olanak tanır ve belirli kullanıcıların, departmanların veya lokasyonların orantısız sayıda olay üretip üretmediğini belirlemeye yardımcı olur. Nereden alınır Olay kaydındaki standart bir alandır; genellikle talebi oluşturan kullanıcı bilgisiyle veya adına oluşturulan kullanıcının bilgileriyle doldurulur. Örnekler Alice JohnsonSatış Departmanıb.williamsCustomer-XYZ Corp | |||
Yeniden Atama Sayısı ReassignmentCount | Olayın farklı bir temsilciye veya gruba yeniden atanma sayısı. | ||
Açıklama Yeniden Atama Sayısı, bir olayın yaşam döngüsü boyunca kaç kez el değiştirdiğini izleyen bir metriktir. Yüksek bir sayı genellikle verimsizliği, yanlış başlangıç yönlendirmesini veya destek ekipleri içinde bilgi eksikliğini gösterir. Bu, Process Mining analizi için güçlü bir özniteliktir. Process Mining yeniden atamaları görselleştirebilse de, önceden hesaplanmış bir sayı, kolay filtreleme ve KPI ölçümü sağlar. Doğrudan Devir ve Yeniden Atama Analizi Dashboard'ında kullanılır ve kayıtların ekipler arasında gidip gelerek daha uzun çözüm sürelerine ve kullanıcı hayal kırıklığına yol açtığı 'ping-pong' senaryolarını tespit etmeye yardımcı olur. Neden önemli Bu metrik, süreç verimsizliğini doğrudan nicelleştirir. Yüksek sayımlar genellikle daha uzun çözüm süreleriyle ilişkilidir ve yönlendirme veya ekip yetenekleriyle ilgili sorunları gösterir. Nereden alınır Genellikle olay kaydında standart bir sayıcı alanı olarak bulunur. Yoksa, olayın denetim kaydındaki atama değişikliklerinin sayısı sayılarak türetilebilir. Örnekler 0135 | |||
Olay Yönetimi Activity'leri
| Aktivite | Açıklama | ||
|---|---|---|---|
Grup Atandı | Olayın, inceleme için belirli bir destek grubuna veya ekibine ilk atamasını belirtir. Bu, ilk resmi devri ve çözüm workflow'unun başlangıcını temsil eder. | ||
Neden önemli Bu, önemli bir yönlendirme adımıdır. Atamalardaki gecikmeler veya yanlış yönlendirme, çözüm sürelerini önemli ölçüde artırabilir ve ekipler arasında gereksiz aktarımlara neden olabilir. Nereden alınır Bu event, bir 'Atama Grubu' veya 'Destek Ekibi' alanının ilk kez doldurulduğu örneği bulunarak audit logdan çıkarılır. Yakala Olayın geçmişindeki 'Atama Grubu' alanının ilk doldurulma timestamp'ini belirleyin. Event tipi inferred | |||
Olay Çözüldü | Bu aktivite, bir çözümün uygulandığını ve hizmetin kullanıcı için restore edildiğine inanıldığını gösterir. Genellikle SLA çözüm saatini durduran kritik bir dönüm noktasıdır. | ||
Neden önemli Bu, çözüm süresini ölçmek için önemli bir bitiş noktasıdır. Bu nokta ile nihai kapanış arasındaki süre, kullanıcı onay gecikmeleri veya otomatik kapanış politikalarını analiz etmek için önemlidir. Nereden alınır Bu, bir temsilcinin olayın durumunu 'Çözüldü' veya 'Halloldu' olarak değiştirdiğinde yakalanan neredeyse her zaman açık bir eventtir. Yakala Olay durumu 'Resolved' olarak güncellendiğinde audit log'daki timestamp'i kullanın. Event tipi explicit | |||
Olay Kapandı | Yaşam döngüsündeki son aktivitedir; olay kaydının resmi olarak kapatıldığı ve salt okunur bir geçmiş kaydı haline geldiği aşamadır. Bu durum genellikle 'Çözüldü' durumunda belirli bir süre geçtikten sonra otomatik olarak gerçekleşir. | ||
Neden önemli Bu, olay yaşam döngüsünün mutlak sonunu işaretler. Oluşturmadan kapanışa kadar geçen tam sürenin analizi, çözüm sonrası idari dönemler de dahil olmak üzere süreç süresinin eksiksiz bir görünümünü sunar. Nereden alınır Olayın history log'unda 'Kapalı' durumuna yapılan net bir status değişiminden alınır ve son timestamp'i verir. Yakala Olay durumu 'Closed' olarak güncellendiğinde audit log'daki timestamp'i kullanın. Event tipi explicit | |||
Olay Oluşturuldu | Bu aktivite, sistemde bir olay kaydının resmi olarak oluşturulduğunu işaretler. Bir kullanıcıdan veya izleme aracından gelen ilk raporu yakalayarak olay yaşam döngüsünün kesin başlangıcıdır. | ||
Neden önemli Bu, süreç için birincil başlangıç eventidir. Oluşturmadan diğer dönüm noktalarına kadar geçen sürenin analizi, genel çözüm süresini ölçmek ve ön uç gecikmelerini belirlemek için temeldir. Nereden alınır Bu, genellikle kaynak sistemdeki birincil olay veya ticket tablosunun oluşturma timestampinden yakalanır. Yakala Ana olay kaydındaki 'create_date' veya 'submitted_on' timestamp'ini kullanın. Event tipi explicit | |||
Olay Yeniden Açıldı | Daha önce çözülmüş bir olayın aktif duruma geri döndürülmesiyle gerçekleşir. Bu genellikle kullanıcının sorunun tekrar ettiğini veya sunulan çözümün etkili olmadığını bildirmesiyle olur. | ||
Neden önemli Yüksek yeniden açılma oranı, çözüm kalitesi, eksik kök neden analizi veya erken kapatma gibi sorunlara işaret eder. Bu durum, yeniden çalışma analizi için kritik bir metriktir. Nereden alınır Durum geçmişinden, bir olayın durumu 'Çözüldü' veya 'Kapalı' konumundan 'Devam Ediyor' gibi aktif bir duruma geri döndüğünde çıkarılır. Yakala Çözümlenmiş bir durumdan açık bir duruma status değişikliğini tespit edin ve bu değişikliğin timestamp'ini kaydedin. Event tipi inferred | |||
SLA İhlali Tespit Edildi | Bir olaya yanıt verme veya olayı çözme süresinin Hizmet Seviyesi Anlaşması (SLA) hedeflerini aşması durumunda ortaya çıkan, hesaplanmış bir olaydır. Bu, manuel bir kullanıcı eylemi değil, geçen sürenin bir sonucudur. | ||
Neden önemli SLA ihlalleri birincil Anahtar Performans Göstergesi (KPI)'dır. Ne zaman ve neden meydana geldiklerini analiz etmek, hizmet sunumunu iyileştirmek ve sözleşmeden doğan yükümlülükleri karşılamak için kritiktir. Nereden alınır Bu event doğrudan loglarda bulunmaz ancak olay kaydında saklanan SLA hedef son tarihleriyle event timestampleri karşılaştırılarak hesaplanır. Yakala Çözüm timestamp'ini 'SLA Due Date' ile karşılaştırın. Çözüm tarihi daha sonra ise, SLA due date timestamp'inde bir ihlal eventi oluşturun. Event tipi calculated | |||
Soruşturma Başladı | Atanmış bir çalışanın olay üzerinde aktif olarak çalışmaya başladığını gösterir. Bu durum genellikle 'Atandı' veya 'Yeni' durumundan 'Devam Ediyor' durumuna bir durum değişikliği ile temsil edilir. | ||
Neden önemli Bu dönüm noktası, ilk sıra süresinin sonunu ve aktif çalışmanın başlangıcını işaretler. Bu aktiviteye kadar geçen süreyi ölçmek, temsilci kapasitesini ve yanıt gecikmelerini anlamaya yardımcı olur. Nereden alınır Bu, tipik olarak olayın geçmiş logundaki bir durum değişikliğinden çıkarılır. Yakala Olay statusunun ilk kez 'Devam Ediyor', 'İşlemde' veya benzer aktif bir duruma değiştiği timestamp'i belirleyin. Event tipi inferred | |||
Çalışma Devam Edildi | Beklemede olan bir olayın yeniden etkinleştirildiği noktayı belirtir. Bu genellikle gerekli bilgiler alındığında ve destek temsilcisinin çalışmasına devam etmesine izin verildiğinde gerçekleşir. | ||
Neden önemli Bu aktivite, harici beklemelerin süresini doğru bir şekilde ölçmek için çok önemlidir. 'Beklemede' ve 'Devam Edildi' arasındaki süre, sürecin dış faktörler nedeniyle ne kadar süreyle durduğunu gösterir. Nereden alınır Olayın durum geçmişinden, 'Beklemede' durumundan tekrar 'Devam Ediyor' veya başka bir aktif duruma geçtiğinde çıkarılır. Yakala Bir olayın statusu 'beklemede' durumundan tekrar aktif bir duruma değiştiğinde timestamp'i kaydedin. Event tipi inferred | |||
Durum "Beklemede" Olarak Değiştirildi | Bir olayın ilerlemesi duraklatıldığında ortaya çıkar; genellikle kullanıcıdan, bir tedarikçiden veya başka bir dış bağımlılıktan bilgi beklenirken olur. Bu durum tipik olarak SLA saatini duraklatır. | ||
Neden önemli Beklemedeki süreyi analiz etmek, harici bağımlılıkları ve gecikmeleri ortaya çıkarır. Aşırı bekleme süresi, dahili verimsizlikleri maskeleyebilir ve çözüm süresi metriklerini yanıltıcı hale getirebilir. Nereden alınır Olayın durum geçmişinden, 'Beklemede', 'Askıda' veya 'Kullanıcı Bekleniyor' durumuna değiştirildiğinde çıkarılır. Yakala Olay statusu belirlenmiş herhangi bir 'beklemede' durumuna her değiştiğinde timestamp'i kaydedin. Event tipi inferred | |||
Geçici Çözüm Sağlandı | Hizmet işlevselliğini geri yüklemek için kullanıcıya geçici bir çözüm iletildiğini belirtir. Bu, kalıcı bir çözüm geliştirilirken iş üzerindeki etkiyi hafifletir. | ||
Neden önemli Geçici bir çözüm sunmak, büyük olayların yönetiminde önemli bir adımdır. Bu, olayın etkisini hafifletme süresini kalıcı çözüme ulaşma süresinden ayrı olarak izlemeyi sağlar. Nereden alınır Bu, açık bir durum veya flag olabilir, ancak genellikle temsilci notlarından veya iletişim loglarından anahtar kelime analizi kullanılarak çıkarılır. Yakala 'Geçici Çözüm Sağlandı' gibi belirli bir status aracılığıyla veya agent yorumlarında 'geçici çözüm' veya 'geçici düzeltme' gibi keyword'leri arayarak belirleyin. Event tipi inferred | |||
Olay Kategorize Edildi | Olayın kategori, tür ve öğesinin belirlenmesi dahil olmak üzere sınıflandırmasını temsil eder. Bu, olayın doğru yere yönlendirilmesine ve doğru çözüm prosedürlerinin uygulanmasına yardımcı olan kritik bir önceliklendirme adımıdır. | ||
Neden önemli Yanlış kategorilendirme gecikmelere, yeniden atamalara ve hatalı raporlamaya yol açabilir. Bu aktiviteyi analiz etmek, ilk triyaj sürecinin kalitesini ve çözüm verimliliği üzerindeki etkisini değerlendirmeye yardımcı olur. Nereden alınır Bu event genellikle audit logdan veya geçmiş tablosundan, kategorizasyonla ilgili alanların ilk kez doldurulduğu zaman belirlenerek çıkarılır. Yakala Olay oluşturulduktan sonra 'Kategori', 'Alt Kategori' veya 'Configuration Item' gibi alanlara yapılan ilk güncellemeyi tespit edin. Event tipi inferred | |||
Olay Önceliklendirildi | Bu aktivite, olayın önceliğinin tipik olarak etkisi ve aciliyeti temel alınarak belirlendiği zaman gerçekleşir. Öncelik düzeyi, Hizmet Seviyesi Anlaşmaları (SLA)na göre hedef yanıt ve çözüm sürelerini belirler. | ||
Neden önemli Önceliklendirme, kaynak tahsisini ve olayların ele alınma sırasını doğrudan etkiler. Bu adımı analiz etmek, kritik olayların öncelikli olarak ele alınmasını ve SLA'ların karşılanmasını sağlamaya yardımcı olur. Nereden alınır Bu, 'Öncelik' veya 'Önem Derecesi' alanındaki değişiklikler için audit trail izlenerek yakalanır. Yakala 'Priority' alanının güncellenmesiyle ilişkili audit log'dan timestamp'i kullanın. Event tipi explicit | |||
Olay Yeniden Atandı | Bir olayın bir destek grubundan veya temsilcisinden diğerine aktarılmasını temsil eder. Bu devir, ilk ekibin sorunu çözemediği ve farklı bir uzmanlık gerektiği durumlarda sıklıkla meydana gelir. | ||
Neden önemli Sık yeniden atamalar, süreç verimsizliğinin, yanlış ilk yönlendirmenin veya ekip bilgisindeki boşlukların güçlü bir göstergesidir. Bu handoff'ları analiz etmek, çözüm akışını kolaylaştırmak için anahtardır. Nereden alınır Denetim log'undan, ilk atama sonrası 'Atama Grubu' veya 'Atanan Kişi' alanında herhangi bir değişiklik tespit edilerek çıkarılır. Yakala 'Atama Grubu' alanı ilk kez doldurulduktan sonra bu alandaki her değişiklik için yeni bir event kaydedin. Event tipi inferred | |||
Temsilci Atandı | Bu aktivite, belirli bir temsilcinin olayın sahipliğini aldığı veya verildiği noktayı işaretler. Ekip düzeyindeki sorumluluktan bireysel sorumluluğa geçişi temsil eder. | ||
Neden önemli Temsilci atamasını takip etmek, bireysel iş yüklerini, performansı analiz etmeye ve olayların müsait bir temsilci beklemesi nedeniyle darboğazların belirlenmesine yardımcı olur. Nereden alınır Olayın audit log'undaki 'Görevli' veya 'Atanan Kişi' alanındaki değişiklikler izlenerek kaydedilir. Yakala 'Assignee' alanı ilk doldurulduğunda veya yeni bir kullanıcıya değiştirildiğinde audit log'daki timestamp'i kullanın. Event tipi explicit | |||
Veri Çekim Kılavuzları
Veri çıkarma yöntemleri sisteme göre değişir. Detaylı talimatlar için,
