Olay Yönetimi Veri Şablonunuz
Olay Yönetimi Veri Şablonunuz
Bu, Olay yönetimi için genel Process Mining veri Templateimizdir. Daha özel yönlendirme için sisteme özel Templatelerimizi kullanın.
Belirli bir sistem seçin- Her olay yönetimi sistemi için evrensel veri yapısı
- Ayrıntılı analiz için önerilen öznitelikler ve aktiviteler
- Sisteme özel örnekler de dahil olmak üzere veri çıkarma rehberi
Olay yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Olayın yaşam döngüsü sırasında gerçekleşen belirli bir iş etkinliğinin, olayın veya durum değişikliğinin adı. | ||
| Açıklama Etkinlik adı, olay yönetimi sürecinin bir parçası olarak gerçekleştirilen belirli bir adımı veya görevi tanımlar. Bu etkinlikler süreç haritasının yapı taşlarını oluşturur. 'SLA Breach Detected' gibi otomatik sistem olaylarını veya 'Agent Assigned' ve 'Workaround Provided' gibi manuel kullanıcı işlemlerini içerebilir. Process Mining analizinde bu öznitelik temel bir role sahiptir. Süreç grafiğindeki düğümleri tanımlayarak analistlerin iş akışını görselleştirmesine, yaygın yolları belirlemesine, darboğazları keşfetmesine ve standart prosedürden sapmaları analiz etmesine imkan verir. Etkinlik adlarının ayrıntı düzeyi ve açıklığı, elde edilebilecek içgörülerin kalitesini ve kapsamını 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 analiz edilmesini sağlar. Nereden alınır? Genellikle olay günlükleri, denetim izleri, durum değişikliği kayıtları veya olay yönetimi sistemindeki görev açıklaması alanlarının bir araya getirilmesiyle elde edilir. Ö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ıdır. Bu kimlik, olayın tüm yaşam döngüsü boyunca izlenmesi için birincil anahtar görevi görür. | ||
| Açıklama Olay kimliği, sistemdeki bir olayı diğer tüm olaylardan ayıran benzersiz alfasayısal koddur. Yeni bir olay oluşturulduğunda üretilir ve olay kalıcı olarak arşivlenene veya silinene kadar değişmez. Process Mining kapsamında Olay kimliği, Case ID olarak analizlerin temelini oluşturur. Yazılımın ilgili tüm olayları, durum değişikliklerini ve etkinlikleri tek bir tutarlı süreç örneğinde birleştirmesini sağlar. Tüm olaylar ortak bir Olay kimliği altında gruplandırıldığında analistler, her olayın ilk bildirimden nihai çözüm ve kapatmaya kadar uçtan uca yolculuğunu doğru biçimde haritalayabilir. Neden önemli? Process Mining için uçtan uca olay yaşam döngüsünü yeniden oluşturmak üzere ilgili tüm etkinlikleri ve olayları birbirine bağlamak açısından gereklidir. Nereden alınır? Olayın birincil anahtarıdır ve genellikle her olay tablosunun veya nesnesinin üst bilgi bölümünde ya da ana kaydında bulunur. Örnekler INC0010032TICKET-84321789456123 | |||
| Olay zaman damgası EventTimestamp | Bir olay için belirli bir etkinliğin veya olayın gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zaman damgası, bir etkinliğin gerçekleştiği kesin anı gösterir. Olayın yaşam döngüsündeki her etkinlik, olayların kronolojik sırasını oluşturmak için karşılık gelen bir zaman damgasına sahip olmalıdır. Bu öznitelik, zamana dayalı Process Mining analizleri için büyük önem taşır. Etkinlikler arasındaki çevrim sürelerinin, belirli adımların süresinin ve toplam olay çözüm süresinin hesaplanmasını sağlar. Kuruluşlar zaman damgalarını analiz ederek darboğazları belirleyebilir, SLA'lara uyumu ölçebilir ve süreç performansının zaman içinde nasıl değiştiğini anlayabilir. Ortalama Çözüm Süresi gibi temel performans göstergelerinin hesaplanmasının temelini oluşturur. Neden önemli? Süreleri hesaplamak, darboğazları belirlemek ve süreç performansını zaman içinde analiz etmek için gerekli olan olayların kronolojik sırasını sağlar. Nereden alınır? Olay günlüklerinde, denetim geçmişi tablolarında veya belirli ilgili kayıtlardaki 'son değiştirilme' ya da 'oluşturulma tarihi' alanlarında bulunur. Örnekler 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| Kaynak sistem SourceSystem | Olay verilerinin çıkarıldığı sistemin adı veya tanımlayıcısı. | ||
| Açıklama Kaynak sistem özniteliği, verinin kaynağını tanımlar. Birden fazla ITSM aracı veya entegre sistemin bulunduğu ortamlarda bu alan, farklı kaynaklardan gelen kayıtların ayırt edilmesine yardımcı olur. Süreç haritasının oluşturulmasında doğrudan kullanılmasa da bu öznitelik, veri doğrulama ve yönetişim açısından değerlidir. Analistlerin veriyi kaynağına kadar izlemesine, sistemler arasındaki olası tutarsızlıkları anlamasına ve analizi bölümlere ayırmasına yardımcı olur. Örneğin aynı kuruluşta ServiceNow ve Jira gibi iki farklı sistemde uygulanan olay yönetimi süreçleri karşılaştırılabilir. Neden önemli? Verinin kaynağı hakkında bağlam sağlar. Bu bilgi, çok sistemli ortamlarda veri doğrulama, sorun giderme ve karşılaştırmalı analiz için gereklidir. Nereden alınır? Genellikle veri çıkarma işlemi sırasında eklenen statik bir değerdir veya kaynak sistem tablolarında bulunan bir alandır. Örnekler ServiceNowJira Service ManagementBMC HelixZendesk | |||
| Son veri güncellemesi LastDataUpdate | Bu kayda ait verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Son veri güncellemesi zaman damgası, verilerin kaynak sistemden en son ne zaman çıkarıldığını veya senkronize edildiğini belirtir. Bu, analiz edilen verilerin güncelliğini gösteren bir üst veri alanıdır. Process Mining analizinde bu öznitelik, oluşturulan içgörülerin güncelliğini anlamak açısından önemlidir. Kullanıcıların gerçek zamanlı bilgilere mi yoksa geçmişteki bir ana ait anlık görüntüye mi baktığını anlamasına yardımcı olur. Bu bağlam, operasyonel izleme ve kararların güncel, ilgili verilere dayanmasını sağlamak için önemlidir. Neden önemli? Verilerin güncelliğini gösterir ve analistlerin süreç analizlerinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu değer genellikle veri çıkarma ve dönüştürme (ETL) süreci sırasında oluşturulur ve her kayda eklenir. Örnekler 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
| Atanan grup AssignedGroup | Olay üzerinde çalışmaktan o anda sorumlu olan destek ekibi, kuyruk veya grup. | ||
| Açıklama Atanan Grup, herhangi bir anda olaydan hangi ekibin sorumlu olduğunu gösterir. Olaylar genellikle Düzey 1 Hizmet Masası, Düzey 2 Ağ ekibi veya Düzey 3 Uygulama Desteği ekibi gibi farklı gruplar arasında yönlendirilir. Bu öznitelik, devir teslimi ve iş yükü analizi için gereklidir. Process Mining bu verileri kullanarak olayların ekipler arasındaki akışını görselleştirebilir, her ekibin kuyruğunda geçirilen süreyi ölçebilir ve sık yeniden atamalardan kaynaklanan darboğazları belirleyebilir. Ekip verimliliği ve iş birliğiyle ilgili soruları yanıtlamanıza yardımcı olur ve Devir Teslimi ve Yeniden Atama Analizi Dashboardunun temelini oluşturur. Neden önemli? Ekipler arasındaki devirleri analiz etmek, kuyruk sürelerini ölçmek ve ekiplere özgü performans ile iş yükü dağılımını anlamak için önemlidir. Nereden alınır? Bu bilgi genellikle olay kaydında saklanır ve olay her yeni ekibe atandığında güncellenir. Örnekler Hizmet MasasıAğ OperasyonlarıVeritabanı YönetimiUygulama Desteği 2. Seviye | |||
| Atanan temsilci AssignedAgent | Olayı ele almak üzere atanan bireysel destek temsilcisi veya kullanıcı. | ||
| Açıklama Atanan temsilci, bir olaydan sorumlu belirli kişiyi gösterir. Atanan grup ekibi belirtirken temsilci, çözüm üzerinde çalışan kişidir. Bu öznitelik, performans ve iş yükünün daha ayrıntılı analiz edilmesini sağlar. Atamaların temsilci düzeyinde izlenmesi, yöneticilerin bireysel üretkenliği değerlendirmesine, eğitim ihtiyaçlarını belirlemesine ve iş dağılımını dengelemesine yardımcı olur. Process Mining kapsamında grup düzeyinde görünmeyebilecek karmaşık yeniden atama kalıplarını ortaya çıkarabilir ve bireysel katkıların çözüm sürelerine etkisini anlamaya yardımcı olur. Neden önemli? Ekip içinde veya ekipler arasında bireysel iş yükünün, performansın ve yeniden atama kalıplarının ayrıntılı biçimde analiz edilmesini sağlar. Nereden alınır? Ana olay kaydında bulunur. Bir temsilci sorumluluğu üstlendiğinde veya olay kendisine atandığında güncellenir. Örnekler John SmithJane Doeagent.12345Emily Jones | |||
| Bildirim kanalı ReportingChannel | Olayın bildirildiği yöntem veya kanal. Örneğin e-posta, telefon veya self servis portalı. | ||
| Açıklama Bildirim kanalı, olay bildiriminin kaynağını gösterir. Kullanıcıların destek hizmetiyle nasıl etkileşim kurduğunu izler; telefon görüşmesi gibi doğrudan iletişim yöntemlerini veya sistem izleme uyarıları gibi otomatik yöntemleri kapsar. Sürecin bildirim kanalına göre analiz edilmesi, verimlilikteki önemli farkları ortaya çıkarabilir. Örneğin self servis portalı üzerinden bildirilen olaylar, başlangıçta daha yapılandırılmış bilgiler içerdiği için daha hızlı çözülebilir. Bu analiz, kuruluşların destek kanallarını optimize etmesine ve daha verimli yöntemlerin kullanımını teşvik etmesine yardımcı olur. Neden önemli? Olayların kaynağına göre verimliliğini ve çözüm yollarını analiz etmeye yardımcı olur. Bu bilgiler kanal stratejisine ve kaynak dağılımına yön verebilir. Nereden alınır? Bu bilgi genellikle otomatik olarak kaydedilir veya olay oluşturulurken temsilci tarafından seçilir. Örnekler E-postaTelefonSelf servis portalıSistem uyarısı | |||
| Çözüm yöntemi ResolutionMethod | Olayın nihai olarak nasıl çözüldüğünü gösteren kod, kategori veya açıklama. | ||
| Açıklama Çözüm yöntemi, olayın sonucunu ve nasıl çözüldüğünü açıklar. Standartlaştırılmış bir kod veya gerçekleştirilen işlemlerin serbest metin açıklaması olabilir. Örnekler arasında 'Kullanıcı eğitimi', 'Yazılım yaması uygulandı', 'Hata bulunamadı' veya 'Yinelenen olay' yer alır. Bu öznitelik, sürecin sonuna ilişkin önemli bir bağlam sağlar. Process Mining kapsamında olayların çözüm yöntemine göre analiz edilmesi, farklı çözümlerin etkililiğinin anlaşılmasına yardımcı olur. Gerçek bir düzeltme yapılmadan kapatılan vakaları ortaya çıkarabilir veya belirli olay kategorileri için yaygın çözüm kalıplarını belirleyebilir. Bu bilgiler 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ü sağlar. Bu bilgi, otomasyon, bilgi tabanı geliştirme ve eğitim fırsatlarını belirlemek için önemlidir. Nereden alınır? Genellikle destek temsilcisinin olayı 'Resolved' veya 'Closed' durumuna geçirirken doldurduğu alandır. Örnekler Hizmet Masası tarafından çözüldüArıza bulunamadıYinelenen kayıtYazı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 'New', 'In Progress' veya 'Closed'. | ||
| Açıklama Olay durumu, olayın belirli bir andaki aşamasını gösterir. Olayın çözüm sürecinde hangi noktada bulunduğuna dair genel bir görünüm sunar. Yaygın durumlar arasında yeni, atanmış, devam ediyor, beklemede, çözümlendi ve kapatıldı yer alır. Bu öznitelik süreç analizi için temeldir; çünkü durum değişiklikleri çoğu zaman süreç haritasındaki etkinlikleri tanımlar. Her durumda geçirilen sürenin analiz edilmesi, olayların 'Pending' durumunda uzun süre beklemesi gibi darboğazların belirlenmesine yardımcı olur. Ayrıca açık olay birikiminin hesaplanması ve çözüme doğru ilerlemenin izlenmesi için kullanılır. Neden önemli? Olayın ilerleyişini anlamak için temel bir özniteliktir ve genellikle süreç haritasındaki etkinlikleri oluşturmak için kullanılır. Her durumda geçirilen sürenin analiz edilmesi gecikmelerin bulunmasına yardımcı olur. Nereden alınır? Genellikle ana olay kaydında birincil alan olarak veya olayın geçmiş günlüğünde bulunur. Örnekler YeniDevam ediyorMüşteri bekleniyorÇözüldüKapatıldı | |||
| Olay kategorisi IncidentCategory | Olayın sınıflandırmasıdır ve genellikle hiyerarşik bir yapıda düzenlenir. Örneğin Donanım > Dizüstü bilgisayar > Pil. | ||
| Açıklama Olay kategorisi, olayları niteliklerine göre sınıflandırmak için yapılandırılmış bir yöntem sunar. Genellikle giderek daha ayrıntılı sınıflandırmaya imkan veren hiyerarşik bir alandır ve olayların raporlama ile analiz amacıyla mantıksal gruplar halinde düzenlenmesine yardımcı olur. Kategorilendirme, kök neden ve trend analizi için önemlidir. Kuruluşlar kategoriye göre filtrelenmiş süreç haritalarını analiz ederek belirli olay türleriyle ilişkili tekrarlayan sorunları ve kalıpları belirleyebilir. Örneğin 'Software' olayının çözüm süreci, 'Hardware' olayınınkinden oldukça farklı olabilir. Bu veri, İlk Kategorilendirme Doğruluğu ve Tekrarlayan Olay Oranı gibi KPI'ları besler. Neden önemli? Kök neden analizi, tekrarlayan olaylardaki eğilimlerin belirlenmesi ve farklı sorun türlerinin nasıl ele alındığının anlaşılması için gereklidir. Nereden alınır? Sınıflandırma için kullanılan, olay kaydındaki standart ve çoğu zaman zorunlu alanlar kümesidir. Örnekler Yazılım | Uygulama | Oturum açma sorunuDonanım | Yazıcı | Yanıt vermiyorAğ | Wi-Fi | Yavaş bağlantı | |||
| Öncelik Priority | Olayın aciliyetini ve çözüm sırasını belirleyen atanmış öncelik düzeyi. | ||
| Açıklama Öncelik, bir olayın göreli önemini ve gereken yanıt hızını belirlemek için kullanılan temel bir özniteliktir. Genellikle olayın etkisi ve aciliyetinin bir arada değerlendirilmesiyle belirlenir. Düzeyler çoğunlukla kritik ile düşük arasında değişir. Process Mining kapsamında olayların önceliğe göre analiz edilmesi, sürecin farklı aciliyet düzeylerini nasıl ele aldığını daha iyi anlamayı sağlar. Analistler, SLA'ların karşılanıp karşılanmadığını ve kaynakların etkili kullanılıp kullanılmadığını görmek için yüksek öncelikli ve düşük öncelikli olayların çözüm sürelerini karşılaştırabilir. 'En kritik olaylarımızı gerçekten en hızlı şekilde ele alıyor muyuz?' gibi soruların yanıtlanmasına yardımcı olur. Neden önemli? Farklı aciliyet düzeylerinde süreç performansının analiz edilmesini sağlar ve 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 hesaplanabilir. Örnekler 1 - Kritik2 - Yüksek3 - Orta4 - Düşük | |||
| Önem derecesi Severity | Olayın iş etkisini ölçen ve kullanıcıları veya hizmetleri ne ölçüde etkilediğini gösteren değer. | ||
| Açıklama Önem derecesi, bir olayın işletme üzerindeki etki düzeyini tanımlar. Aciliyetten bağımsız olarak sorunun ne kadar ciddi olduğunu gösterir. Örneğin sistem genelindeki kesinti yüksek önem dereceli, küçük bir görsel hata ise düşük önem dereceli bir olaydır. Olayların önem derecesine göre analiz edilmesi, kuruluşların en fazla kesintiye hangi sorun türlerinin yol açtığını anlamasına yardımcı olur. Process Mining, yüksek önem dereceli olayların farklı ve daha akıcı bir çözüm yolunu izleyip izlemediğini ortaya çıkarabilir. Bu öznitelik, kök neden analizi ve en ciddi olayların tekrarlanmasını önlemek üzere proaktif sorun yönetimi için kaynakların önceliklendirilmesi açısından önemlidir. Neden önemli? Olayların bölümlere ayrılmasını sağlar ve yüksek etkili sorunların düşük etkili sorunlardan farklı ya da daha verimli biçimde çözülüp çözülmediğini anlamaya yardımcı olur. Nereden alınır? Olay kaydındaki standart bir alandır ve genellikle aciliyetle birlikte önceliği belirlemek için 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ı iş uygulaması, sunucu veya ağ cihazı gibi BT altyapısındaki belirli bir bileşene bağlar. Bu bilgi genellikle Yapılandırma Yönetimi Veritabanı (CMDB) ile ilişkilidir. Bu öznitelik olaya önemli bir iş bağlamı kazandırır. Process Mining kapsamında belirli hizmetlerin veya varlıkların güvenilirliğine odaklanan analizler yapılmasını sağlar. Kuruluşlar en fazla olayı hangi hizmetlerin oluşturduğunu belirleyebilir, bu hizmetlerin çözüm süreçlerini analiz edebilir ve kritik iş hizmetlerinin kararlılığını artırmak için sorun yönetimi çalışmalarına öncelik verebilir. 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ğlar. Böylece hangi hizmetlerin sorunlara daha yatkın olduğu ve etkilerinin ne olduğu analiz edilebilir. Nereden alınır? Genellikle bir Yapılandırma Yönetimi Veritabanından (CMDB) bağlanır veya olay formundaki hizmet kataloğu listesinden seçilir. Örnekler E-posta hizmetleriSAP ERP FinansKurumsal VPNSRV-SQL-01 | |||
| SLA durumu SlaStatus | Olayın hizmet düzeyi anlaşması (SLA) hedefleri içinde olup olmadığını, risk altında bulunup bulunmadığını veya hedefleri aşıp aşmadığını gösterir. | ||
| Açıklama SLA Durumu, bir olayın yanıt verme veya çözme süresi gibi önceden belirlenmiş zaman hedeflerine göre performansını gösteren anlık bir görünüm sunar. Yaygın durumlar arasında Devam ediyor, Risk altında ve İhlal edildi bulunur. Bu öznitelik, hizmet kalitesinin doğrudan bir ölçüsüdür ve SLA performansına genel bakış Dashboardu için önemli bir girdidir. Process Mining ile SLA ihlal edilen ve edilmeyen olayların süreç akışlarını karşılaştırmanızı sağlar. Böylece SLA başarısızlıklarına en çok neden olan etkinlikleri, gecikmeleri veya yeniden çalışma döngülerini belirleyebilir ve süreç iyileştirme çalışmalarınızı hedefleyebilirsiniz. Neden önemli? Hedeflere göre performansın doğrudan ölçüsüdür. Hedefi aşan olayların analiz edilmesi, hizmet sunumundaki sorunlara yol açan süreç hatalarının belirlenmesine yardımcı olur. Nereden alınır? Genellikle ITSM aracı içindeki hesaplanan bir alandır ve olayın önceliğine, yaşına ve tanımlı SLA kurallarına göre dinamik olarak güncellenir. Ö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 bildirimini başlatan kişidir. Bu kişi kurum içindeki bir çalışan veya dış müşteri olabilir. Öznitelik, talep sahibinin departmanını veya kuruluşunu da içerebilir. Olayların talep sahibine veya talep sahibinin departmanına göre analiz edilmesi, belirli kullanıcı gruplarının diğerlerinden daha fazla sorun yaşayıp yaşamadığını ortaya çıkarabilir. Bu durum eğitim ihtiyaçlarına veya belirli bir ortamdaki sorunlara işaret edebilir. Process Mining kapsamında destek sürecinin kullanıcı odaklı görünümünü sağlar ve farklı kullanıcı gruplarının deneyimini anlamaya yardımcı olur. Neden önemli? Kullanıcı odaklı analiz yapılmasını sağlar ve belirli kullanıcıların, departmanların veya konumların orantısız sayıda olay oluşturup oluşturmadığını belirlemeye yardımcı olur. Nereden alınır? Olay kaydındaki standart bir alandır. Genellikle talep kaydını oluşturan veya kayıt adına oluşturulan kullanıcıyla doldurulur. Örnekler Alice JohnsonSatış Departmanıb.williamsMüşteri-XYZ Corp | |||
| Yeniden atama sayısı ReassignmentCount | Olayın farklı bir temsilciye veya gruba toplam kaç kez yeniden atandığı. | ||
| Açıklama Yeniden Atama Sayısı, bir olayın yaşam döngüsü boyunca geçirdiği devir teslimlerinin sayısını izleyen bir metriktir. Yüksek bir sayı genellikle verimsizliğe, ilk yönlendirmenin hatalı yapılmasına veya destek ekiplerinde bilgi eksikliğine işaret eder. Bu öznitelik, Process Mining analizi için oldukça faydalıdır. Process Mining yeniden atamaları görselleştirebilse de önceden hesaplanmış bir sayı, kolay filtreleme ve KPI ölçümü sağlar. Devir Teslimi ve Yeniden Atama Analizi Dashboardunda doğrudan kullanılır ve kayıtların ekipler arasında sürekli ileri geri aktarıldığı, çözüm sürelerinin uzamasına ve kullanıcıların memnuniyetsiz olmasına yol açan ping pong senaryolarını belirlemeye yardımcı olur. Neden önemli? Bu metrik süreç verimsizliğini doğrudan ölçer. Yüksek değerler genellikle daha uzun çözüm süreleriyle ilişkilidir ve yönlendirme ya da ekip yetkinlikleriyle ilgili sorunlara işaret eder. Nereden alınır? Genellikle olay kaydında standart bir sayaç alanı olarak bulunur. Yoksa olayın denetim günlüğündeki atama değişikliklerinin sayılmasıyla elde edilebilir. Örnekler 0135 | |||
Olay yönetimi faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Grup atandı | Olayın incelenmek üzere belirli bir destek grubuna veya ekibe ilk kez atanmasını ifade eder. Bu, ilk resmi devir teslimi ve çözüm iş akışının başlangıcını gösterir. | ||
| Neden önemli? Bu, önemli bir yönlendirme adımıdır. Atamadaki gecikmeler veya hatalı yönlendirme, çözüm sürelerini önemli ölçüde uzatabilir ve ekipler arasında gereksiz devirlere neden olabilir. Nereden alınır? Bu olay, 'Assignment Group' veya 'Support Team' alanının doldurulduğu ilk kaydı denetim günlüğünde bularak çıkarılır. Yakalayın Olay geçmişinde 'Assignment Group' alanının ilk kez doldurulduğu zaman damgasını belirleyin. Olay türü inferred | |||
| İnceleme başladı | Atanan temsilcinin olay üzerinde aktif olarak çalışmaya başladığını gösterir. Bu durum çoğu zaman 'Assigned' veya 'New' durumundan 'In Progress' durumuna geçişle ifade edilir. | ||
| Neden önemli? Bu kilometre taşı, ilk kuyruk süresinin sonunu ve aktif çalışmanın başlangıcını gösterir. Bu faaliyete kadar geçen süreyi ölçmek, temsilci kapasitesini ve yanıt gecikmelerini anlamanıza yardımcı olur. Nereden alınır? Bu bilgi genellikle olayın geçmiş günlüğündeki durum değişikliğinden çıkarılır. Yakalayın Olay durumunun ilk kez 'In Progress', 'Work in Progress' veya benzer bir etkin duruma geçtiği zaman damgasını belirleyin. Olay türü inferred | |||
| Olay çözüldü | Bu etkinlik, çözümün uygulandığını ve hizmetin kullanıcı için yeniden kullanılabilir durumda olduğunun düşünüldüğünü gösterir. Genellikle SLA çözüm süresi sayacını durduran önemli bir kilometre taşıdır. | ||
| Neden önemli? Çözüm süresini ölçmek için önemli bir bitiş noktasıdır. Bu nokta ile nihai kapatma arasındaki süre, kullanıcı onayındaki gecikmeleri veya otomatik kapatma politikalarını analiz etmek açısından önemlidir. Nereden alınır? Bir temsilci olayın durumunu 'Resolved' veya 'Solved' olarak değiştirdiğinde kaydedilen açık bir olaydır ve neredeyse her zaman gerçekleşir. Yakalayın Olay durumu 'Resolved' olarak güncellendiğinde denetim günlüğündeki zaman damgasını kullanın. Olay türü explicit | |||
| Olay kapatıldı | Yaşam döngüsündeki son etkinliktir. Olay kaydı burada resmen kapatılır ve salt okunur bir geçmiş kaydına dönüşür. Bu işlem, olayın 'Resolved' durumunda belirli bir süre kalmasının ardından çoğu zaman otomatik olarak gerçekleşir. | ||
| Neden önemli? Olay yaşam döngüsünün kesin sonunu gösterir. Oluşturmadan kapatmaya kadar geçen toplam sürenin analiz edilmesi, çözüm sonrası idari dönemler de dahil olmak üzere süreç süresini eksiksiz biçimde ortaya koyar. Nereden alınır? Olay geçmişi günlüğünde 'Closed' durumuna yapılan açık bir durum değişikliğinden alınır ve nihai zaman damgasını sağlar. Yakalayın Olay durumu 'Closed' olarak güncellendiğinde denetim günlüğündeki zaman damgasını kullanın. Olay türü explicit | |||
| Olay oluşturuldu | Bu faaliyet, sistemde bir olay kaydının resmi olarak oluşturulmasını ifade eder. Kullanıcıdan veya izleme aracından gelen ilk bildirimi kaydederek olay yaşam döngüsünün kesin başlangıcını oluşturur. | ||
| Neden önemli? Bu, sürecin birincil başlangıç olayıdır. Oluşturma ile diğer kilometre taşları arasındaki süreyi analiz etmek, genel çözüm süresini ölçmek ve başlangıç aşamasındaki gecikmeleri belirlemek için temel öneme sahiptir. Nereden alınır? Bu bilgi genellikle kaynak sistemdeki birincil olay veya kayıt tablosunun oluşturulma zaman damgasından alınır. Yakalayın Ana olay kaydındaki 'create_date' veya 'submitted_on' zaman damgasını kullanın. Olay türü explicit | |||
| Olay yeniden açıldı | Daha önce çözümlenmiş bir olay etkin duruma döndürüldüğünde gerçekleşir. Bu genellikle kullanıcının sorunun tekrarlandığını veya sunulan çözümün etkili olmadığını bildirmesiyle olur. | ||
| Neden önemli? Yüksek yeniden açılma oranı, çözüm kalitesiyle ilgili sorunlara, eksik kök neden analizine veya erken kapatmaya işaret eder. Yeniden işleme analizi için önemli bir metriktir. Nereden alınır? Olayın durumu 'Resolved' veya 'Closed' durumundan 'In Progress' gibi etkin bir duruma döndüğünde durum geçmişinden çıkarılır. Yakalayın Çözümlenmiş durumdan açık duruma geçişi tespit edin ve bu değişikliğin zaman damgasını kaydedin. Olay türü inferred | |||
| SLA ihlali tespit edildi | Bir olaya yanıt vermek veya olayı çözmek için geçen süre, Hizmet Seviyesi Anlaşmasında (SLA) tanımlanan hedefleri aştığında gerçekleşen hesaplanmış bir olaydır. Bu, kullanıcının manuel olarak gerçekleştirdiği bir işlem değil, geçen sürenin sonucudur. | ||
| Neden önemli? SLA ihlalleri temel bir Temel Performans Göstergesidir (KPI). Bunların ne zaman ve neden gerçekleştiğini analiz etmek, hizmet sunumunu iyileştirmek ve sözleşme yükümlülüklerini yerine getirmek için büyük önem taşır. Nereden alınır? Bu olay günlüklerde doğrudan yer almaz. Olay zaman damgaları, olay kaydında saklanan SLA hedef son tarihleriyle karşılaştırılarak hesaplanır. Yakalayın Çözüm zaman damgasını 'SLA Due Date' ile karşılaştırın. Çözüm daha sonraysa SLA son tarihi zaman damgasında bir ihlal olayı oluşturun. Olay türü calculated | |||
| Çalışma devam etti | Beklemeye alınmış bir olayın yeniden etkinleştirildiği anı gösterir. Bu genellikle gerekli bilgiler alındığında ve destek temsilcisi çalışmasına devam edebildiğinde gerçekleşir. | ||
| Neden önemli? Bu faaliyet, dış kaynaklı beklemelerin süresini doğru ölçmek için gereklidir. 'Pending' ile 'Resumed' arasındaki süre, dış faktörler nedeniyle sürecin ne kadar durduğunu gösterir. Nereden alınır? Olay 'Pending' durumundan yeniden 'In Progress' veya başka bir etkin duruma geçtiğinde, olayın durum geçmişinden çıkarılır. Yakalayın Bir olayın durumu 'pending' durumundan yeniden etkin bir duruma geçtiğinde oluşan zaman damgasını kaydedin. Olay türü inferred | |||
| Durum beklemede olarak değiştirildi | Olay üzerindeki ilerleme, genellikle kullanıcıdan, tedarikçiden veya başka bir dış bağımlılıktan bilgi beklenirken duraklatıldığında gerçekleşir. Bu durum genellikle SLA saatini duraklatır. | ||
| Neden önemli? Beklemede geçirilen süreyi analiz etmek, dış bağımlılıkları ve gecikmeleri ortaya çıkarır. Aşırı bekleme süresi, iç verimsizlikleri gizleyebilir ve çözüm süresi metriklerini çarpıtabilir. Nereden alınır? Olay durumu 'Pending', 'On Hold' veya 'Awaiting User' durumuna değiştiğinde, olayın durum geçmişinden çıkarılır. Yakalayın Olay durumu belirlenmiş herhangi bir 'pending' durumuna her geçtiğinde zaman damgasını kaydedin. Olay türü inferred | |||
| Geçici çözüm sağlandı | Hizmetin çalışmasını yeniden sağlamak için kullanıcıya geçici bir çözüm iletildiğini gösterir. Kalıcı çözüm geliştirilirken iş üzerindeki etkiyi azaltır. | ||
| Neden önemli? Geçici çözüm sağlamak, büyük olayları yönetmenin önemli bir adımıdır. Azaltma süresini kalıcı çözüme ulaşma süresinden ayrı olarak izlemenize imkan verir. Nereden alınır? Bu, açık bir durum veya işaret olabilir; ancak çoğu zaman temsilci notları ya da iletişim günlükleri anahtar kelime analiziyle incelenerek çıkarılır. Yakalayın 'Workaround Provided' gibi belirli bir durum üzerinden veya temsilci yorumlarında 'workaround' ya da 'temporary fix' gibi anahtar kelimeleri arayarak belirleyin. Olay türü inferred | |||
| Olay kategorilendirildi | Kategorisinin, türünün ve öğesinin belirlenmesi dahil olmak üzere olayın sınıflandırılmasını ifade eder. Bu, olayın yönlendirilmesine ve doğru çözüm prosedürlerinin uygulanmasına yardımcı olan önemli bir ön değerlendirme adımıdır. | ||
| Neden önemli? Hatalı kategorilendirme gecikmelere, yeniden atamalara ve raporların çarpıtılmasına yol açabilir. Bu faaliyeti analiz etmek, ilk ön değerlendirme sürecinin kalitesini ve çözüm verimliliğine etkisini değerlendirmenize yardımcı olur. Nereden alınır? Bu olay genellikle denetim günlüğü veya geçmiş tablosunda kategorilendirmeyle ilgili alanların ilk kez doldurulduğu an belirlenerek çıkarılır. Yakalayın Olay oluşturulduktan sonra 'Category', 'Subcategory' veya 'Configuration Item' gibi alanlarda yapılan ilk güncellemeyi belirleyin. Olay türü inferred | |||
| Olay önceliklendirildi | Olayın önceliği, genellikle etkisine ve aciliyetine göre belirlendiğinde gerçekleşir. Öncelik düzeyi, Hizmet Seviyesi Anlaşmalarına (SLA'lar) göre hedef yanıt ve çözüm sürelerini belirler. | ||
| Neden önemli? Önceliklendirme, kaynak dağılımını ve olayların ele alınma sırasını doğrudan etkiler. Bu adımı analiz etmek, kritik olayların önce ele alınmasını ve SLA'lara uyulmasını sağlamaya yardımcı olur. Nereden alınır? Bu bilgi, denetim izinde 'Priority' veya 'Severity' alanındaki değişiklikler izlenerek alınır. Yakalayın 'Priority' alanının güncellenmesiyle ilişkili denetim günlüğündeki zaman damgasını kullanın. Olay türü explicit | |||
| Olay yeniden atandı | Bir olayın bir destek grubundan veya temsilciden başka bir destek grubuna ya da temsilciye aktarılmasını ifade eder. Bu devir, ilk ekip sorunu çözemediğinde ve farklı bir uzmanlık gerektiğinde gerçekleşir. | ||
| Neden önemli? Sık yeniden atamalar, süreç verimsizliğinin, hatalı ilk yönlendirmenin veya ekip bilgisindeki eksikliklerin güçlü bir göstergesidir. Bu devirleri analiz etmek, çözüm akışını kolaylaştırmak için önemlidir. Nereden alınır? İlk atamadan sonra 'Assignment Group' veya 'Assignee' alanındaki herhangi bir değişiklik denetim günlüğünde belirlenerek çıkarılır. Yakalayın 'Assignment Group' alanı ilk kez doldurulduktan sonra gerçekleşen her değişiklik için yeni bir olay kaydedin. Olay türü inferred | |||
| Temsilci atandı | Belirli bir temsilcinin olayın sorumluluğunu aldığı veya kendisine verildiği anı gösterir. Ekip düzeyindeki sorumluluktan bireysel sorumluluğa geçişi ifade eder. | ||
| Neden önemli? Temsilci atamasını izlemek, bireysel iş yüklerini ve performansı analiz etmenize, ayrıca olayların uygun bir temsilci beklediği darboğazları belirlemenize yardımcı olur. Nereden alınır? Olayın denetim günlüğünde 'Assignee' veya 'Assigned To' alanındaki değişiklikler izlenerek alınır. Yakalayın 'Assignee' alanının ilk kez doldurulduğu veya yeni bir kullanıcıyla değiştirildiği denetim günlüğündeki zaman damgasını kullanın. Olay türü explicit | |||
Veri çıkarma rehberleri
Çıkarma yöntemleri sisteme göre değişir. Ayrıntılı talimatlar için
Başlamaya hazır mısınız?
Olay yönetimi sürecinizi bugün dönüştürmeye başlayın. Aşağıdan sisteme özel bir çıkarma rehberi seçin veya güçlü süreç analizi için Event Logunuzu oluşturmaya başlamak üzere bu genel şablondan yararlanın.
Olayları daha hızlı çözün, dönüşümünüze şimdi başlayın
Darboğazları belirleyin, kesinti süresini azaltın ve ekip verimliliğini artırın.
Kredi kartı gerekmez, kurulum 5 dakika sürer