Veri Template'i: Olay Yönetimi
Incident Management Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- BMC Helix için veri çıkarma rehberi
Olay Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Olayın yaşam döngüsünün belirli bir noktasında meydana gelen spesifik eylemin veya event'in adı. | ||
|
Açıklama
Activity Name, 'Olay Kategorize Edildi', 'Destek Grubuna Atandı' veya 'Olay Çözüldü' gibi olay yönetimi sürecindeki bir adımı tanımlar. Bu aktiviteler, keşfedilen süreç haritasındaki düğümleri oluşturur. Bu aktivitelerin sırasını ve sıklığını analiz etmek, Process Mining'in merkezindedir. Gerçek süreç akışını ortaya çıkarmaya, adımlar arasındaki bottleneck'leri belirlemeye, standart operasyon prosedüründen sapmaları tespit etmeye ve olay yaşam döngüsü içindeki belirli aşamaların süresini ölçmeye yardımcı olur.
Neden önemli
Bu öznitelik, süreçteki adımları tanımlayarak, süreç haritasının görselleştirilmesini ve akışların, bottleneck'lerin (darboğazların) ve sapmaların analizini mümkün kılar.
Nereden alınır
Genellikle durum değişikliklerinden, denetim kayıtlarından veya 'HPD:HelpDesk_AuditLogSystem' ya da benzer denetim tablolarındaki olayla ilişkili belirli olay kayıtlarından elde edilir.
Örnekler
Olay BildirildiDestek Grubuna AtandıSoruşturma BaşladıOlay ÇözüldüOlay Kapatıldı
|
|||
|
Başlangıç Zamanı
EventTimestamp
|
Bir olay için belirli bir aktivitenin veya event'in gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Event Timestamp, her aktivitenin gerçekleştiği anı kaydeder. Bu zamansal veri, olayları kronolojik olarak sıralamak ve süreç akışını doğru bir şekilde oluşturmak için kritiktir. Analizde, timestamp'ler aktiviteler arasındaki süreleri hesaplamak, olayların toplam cycle time'ını ölçmek ve süreçteki gecikmeleri veya bekleme sürelerini belirlemek için kullanılır. Timestamp'leri Service Level Agreement (SLA'lar) ile karşılaştırmak da performans izleme ve uyumluluk kontrolleri için esastır.
Neden önemli
Timestamps, olayların zamansal sıralamasını gösterir ve performans ölçümü, darboğaz tespiti ve SLA uyumluluğu dahil olmak üzere tüm zamana dayalı analizler için kritik öneme sahiptir.
Nereden alınır
Bu bilgi, kaydedilen her eyleme veya durum değişikliğine karşılık gelen 'HPD:HelpDesk_AuditLogSystem' gibi denetim kaydı tablolarında bulunur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
|
|||
|
Olay Kimliği
IncidentId
|
Bildirilen her olay için benzersiz bir tanımlayıcıdır ve olayın yaşam döngüsünü izlemek için birincil anahtar görevi görür. | ||
|
Açıklama
Incident ID, olay yönetimi analizinin temel taşıdır. Her case'i benzersiz bir şekilde tanımlayarak, ilgili tüm event'leri, durum değişikliklerini ve aktiviteleri tek, uyumlu bir süreç örneğinde birleştirmeye olanak tanır. Process Mining'de bu ID, 'Incident Reported'dan 'Incident Closed'a kadar her adımı birbirine bağlar ve olayın yolculuğunun uçtan uca eksiksiz bir görünümünü sağlar. Toplam çözüm süresi, yeniden atama sayısı ve süreç varyantlarını belirleme gibi case düzeyindeki metrikleri hesaplamak için hayati öneme sahiptir.
Neden önemli
Bu öznitelik, temel case tanımlayıcısıdır ve bir olayın tüm yaşam döngüsünü izlemeyi ve yönetim sürecindeki akışını analiz etmeyi mümkün kılar.
Nereden alınır
Bu, birincil Olay Yönetimi modülü veya formunda, genellikle 'Olay Numarası' veya 'Olay Kimliği' olarak etiketlenen çekirdek bir alandır.
Örnekler
INC000012345678INC000009876543INC000011223344
|
|||
|
Kaynak Sistem
SourceSystem
|
Olay verilerinin çıkarıldığı sistem. | ||
|
Açıklama
Bu öznitelik, verinin kaynağını tanımlar ve birden fazla sistem'den gelen verilerin analiz için birleştirildiği ortamlarda çok önemlidir. Veri soy ağacını sağlamaya yardımcı olur ve verinin yapısı ile içeriği için bağlam sağlar. Bmc Helix için bu, tipik olarak belirli bir instance veya ortamı (örneğin 'BmcHelix_Production') tanımlayan statik bir değer olacaktır. Birden fazla kaynak sistem entegre edildiğinde, verileri filtrelemek ve segmentlere ayırmak için kullanışlıdır.
Neden önemli
Verinin kaynağı için izlenebilirlik ve bağlam sağlar, bu da veri yönetişimi ve çok sistemli ortamlarda sorun giderme için önemlidir.
Nereden alınır
Bu, veri kaynağını tanımlamak için veri çekme, dönüştürme ve yükleme (ETL) işlemi sırasında eklenen tipik olarak statik bir değerdir.
Örnekler
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu kayda ait verilerinin kaynak sistem'den son güncellenme zaman damgası. | ||
|
Açıklama
Bu öznitelik, en son veri çıkarma işleminin timestamp'ini (zaman damgasını) sağlar. Analiz edilen verinin güncelliğini anlamak için temel bir metadata alanıdır. Verinin en son ne zaman güncellendiğini bilmek, analistlerin ve iş kullanıcılarının Process Mining aracından türetilen içgörülere güvenmelerine yardımcı olur. Bu, analizin operasyonların en güncel durumunu yansıtıp yansıtmadığını veya eski verilere dayanıp dayanmadığını doğrular.
Neden önemli
Verinin güncelliğine dair şeffaflık sağlar; bu da süreç analizine dayanarak zamanında ve doğru iş kararları almak için kritiktir.
Nereden alınır
Bu timestamp, veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında oluşturulur ve eklenir.
Örnekler
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Atanan Destek Grubu
AssignedSupportGroup
|
Olay üzerinde çalışmaktan sorumlu destek ekibi veya grubu. | ||
|
Açıklama
Bu öznitelik, bir olaya atanan ekibi tanımlar. Bir olay ilerledikçe, Service Desk, Network Team veya Application Support gibi farklı destek gruplarına yeniden atanabilir. Bu öznitelikteki değişiklikleri izlemek, 'Incident Reassignment Analysis' dashboard'u için temeldir. Ekipler arası devirleri görselleştirmeye, olay başına aktarım sayısını ölçmeye ve aşırı yeniden atamalara yol açan bottleneck'leri (darboğazları) veya bilgi boşluklarını belirlemeye olanak tanır. Aynı zamanda ekipler arası iş yükü dağılımı analizini de destekler.
Neden önemli
Bu öznitelik, ekip performansını, iş yükü dağılımını ve olay yönlendirmesi ve devirlerinin verimliliğini analiz etmek için anahtardır.
Nereden alınır
'HPD:Help Desk' formunda standart bir alan, genellikle 'Assigned Group' olarak adlandırılır.
Örnekler
Service DeskAğ OperasyonlarıVeritabanı YönetimiApplication Support Tier 2
|
|||
|
Atanan Temsilci
AssignedAgent
|
Olaya atanmış bireysel destek temsilcisi. | ||
|
Açıklama
Assigned Agent, belirli bir anda olaydan sorumlu olan kişidir. Bu, destek grubundan daha ayrıntılı bir seviye sunarak bireysel performans ve iş yükü analizine olanak tanır. Bu nitelik, 'Ekip İş Yükü Dağılımı' dashboard'ı ve 'Temsilci Başına Aktivite Hacmi Standart Sapması' KPI'ı için kritik öneme sahiptir. Her temsilcinin ele aldığı olayların hacmini ve türlerini analiz ederek yöneticiler, aşırı yüklenmiş bireyleri belirleyebilir, adil iş yükü dağılımını sağlayabilir ve gelişim fırsatlarını tespit edebilir.
Neden önemli
Bireysel iş yükü ve performansı ayrıntılı analiz etmeyi sağlar; kaynak tahsisini optimize etmeye, en iyi performans gösterenleri veya desteğe ihtiyaç duyanları belirlemeye yardımcı olur.
Nereden alınır
'HPD:Help Desk' formunda standart bir alan, genellikle 'Assignee' olarak adlandırılır.
Örnekler
Alice SmithBob JohnsonCharlie Brown
|
|||
|
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
Incident Status, bir olayın herhangi bir andaki aşamasını gösterir. Genellikle 'Activity' log'unu oluşturmanın kaynağıdır; burada bir durum değişikliği bir süreç adımına karşılık gelir. Durumu analiz etmek, olayları mevcut durumlarına göre filtrelemeye, farklı durumlarda ne kadar zaman harcandığını anlamaya ve takılı kalan olayları belirlemeye olanak tanır. Örneğin, bir dashboard, 'Pending' durumunda alışılmadık derecede uzun süre kalmış olayları vurgulayabilir.
Neden önemli
Bir olayın ilerlemesinin anlık görüntüsünü sunar ve takılıp kalmış olayları belirlemek ile çeşitli aşamalarda harcanan zamanı analiz etmek için kritik öneme sahiptir.
Nereden alınır
Ana olay formundaki ('HPD:Help Desk') temel bir alan, genellikle 'Status' olarak adlandırılır.
Örnekler
YeniAtandıDevam EdiyorAskıdaÇözüldüKapalı
|
|||
|
Olay Kategorisi
IncidentCategory
|
Olayın sınıflandırması, genellikle hiyerarşik bir yapıda düzenlenir. | ||
|
Açıklama
Olay Kategorisi, etkilenen hizmete, bileşene veya sorun türüne göre olayları sınıflandırmak için yapılandırılmış bir yol sunar; örneğin 'Donanım', 'Yazılım' veya 'Ağ'. Bu kategorizasyon, olayları doğru ekibe yönlendirmek ve olay eğilimlerinin daha sonraki analizi için çok önemlidir. 'Olay Kategorizasyon Doğruluğu' dashboard'u, ilk triyajın kalitesini ölçmek için bu özniteliğe dayanır ve genellikle başlangıç değerini çözüm anındaki değeriyle karşılaştırır. Doğru kategorizasyon, tekrarlayan sorunları belirlemeye yardımcı olur ve daha etkili problem yönetimini sağlar.
Neden önemli
Doğru kategorizasyon, verimli yönlendirme, trend analizi ve ilk teşhisin doğruluğunu değerlendirmek için hayati öneme sahiptir.
Nereden alınır
Bunlar, 'HPD:Help Desk' formundaki standart alanlardır ve genellikle 'Kategorizasyon Katmanı 1', 'Kategorizasyon Katmanı 2' gibi basamaklı alan kümeleridir.
Örnekler
Yazılım > Kurumsal Uygulamalar > ERPDonanım > Laptop > KlavyeAğ > Bağlantı > Wi-Fi
|
|||
|
Öncelik
Priority
|
Olayın öncelik seviyesi, çözüm için gereken hızı belirler. | ||
|
Açıklama
Öncelik, bir olayın aciliyetini belirleyen temel bir özniteliktir. Genellikle olayın etkisinden ve aciliyetinden türetilir ve kaynakları tahsis etmek, hizmet seviyesi anlaşması (SLA) hedeflerini tanımlamak için kullanılır. Process Mining analizinde, öncelik, yüksek öncelikli olayların süreç akışlarını düşük öncelikli olaylarla karşılaştırmak için kullanılır. Bu, kritik olayların gerçekten daha hızlı ele alınıp alınmadığını doğrulamaya ve süreç yollarındaki sapmaları belirlemeye yardımcı olur; bu da 'Yüksek Öncelikli Olay Performansı' dashboard'u ve ilgili KPI'lar için temeldir.
Neden önemli
Bu öznitelik, analizi segmentlere ayırmak için kritik öneme sahiptir; bu sayede yüksek öncelikli olay'ların tanımlanmış prosedürlere ve SLA'lara göre ele alınması sağlanır.
Nereden alınır
'HPD:Help Desk' formunda standart bir alan, genellikle 'Priority' olarak adlandırılır.
Örnekler
KritikYüksekOrtaDüşük
|
|||
|
Şiddet
Severity
|
Olayın iş üzerindeki etkisinin ölçüsü. | ||
|
Açıklama
Önem Derecesi, bir olayın iş operasyonlarını ne denli ciddi etkilediğini tanımlar. Olayın önceliğini ve ilgili SLA'ları belirlemede aciliyetle birlikte kritik bir girdidir. Olayları önem derecesine göre analiz etmek, en etkili sorunlar için süreç performansını anlamaya yardımcı olur. Bu, 'Kritik SLA İhlali Genel Bakışı' gibi dashboard'larda, işletme için en büyük riski oluşturan olayları kategorize etmek ve bunlara odaklanmak için kullanılır.
Neden önemli
Önem derecesi, olayların iş üzerindeki etkisini nicelleştirmeye yardımcı olarak, en önemli operasyonel riskleri azaltmaya odaklanan analizler yapılmasını sağlar.
Nereden alınır
BMC Helix dokümantasyonuna bakın. Bu alan, olay formunda sıklıkla 'Impact' veya 'Severity' adıyla yer alan standart bir alandır.
Örnekler
1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
|
|||
|
SLA Statüsü
SLAStatus
|
Olayın SLA hedefleri dahilinde olup olmadığını veya ihlal edilip edilmediğini gösterir. | ||
|
Açıklama
SLA Durumu, her bir olay için hizmet performansının net bir göstergesini sunar. Genellikle 'Hedef İçinde', 'Uyarı' veya 'İhlal Edildi' gibi durumları gösterir. Bu, genellikle Bmc Helix içinde dinamik olarak hesaplanan bir alandır. Bu öznitelik, 'Critical SLA Breach Overview' dashboard'u ve 'Critical Incident SLA Breach Rate' KPI'ı için temeldir. SLA taahhütlerini karşılayamayan olay'ların anında tespit edilmesini ve önceliklendirilmesini sağlar, böylece gecikmelerin nedenlerine odaklanmış bir analiz yapılabilir.
Neden önemli
Taahhütlere karşı performansı doğrudan ölçer; uyumluluk takibi ve SLA ihlallerine yol açan süreçlerin belirlenmesi için temeldir.
Nereden alınır
Bu, genellikle Bmc Helix içinde, olayın önceliği ve yaşına göre oluşturulan hesaplanmış bir alandır. Durum, ilgili bir SLA yönetim modülünde saklanabilir.
Örnekler
Hedef İçindeUyarıİhlal Edildi
|
|||
|
Çözüm Kodu
ResolutionCode
|
Olayın nihayetinde nasıl çözüldüğünü gösteren bir kod veya kategori. | ||
|
Açıklama
Resolution Code, bir olaya uygulanan çözümün nihai sonucunu veya niteliğini yakalar. Bu yapılandırılmış veri, kök neden analizi ve en sık ihtiyaç duyulan çözüm türlerini anlamak için değerlidir. Analizde, bu öznitelik başlangıçtaki 'IncidentCategory' ile karşılaştırılarak kategorizasyon doğruluğu değerlendirilebilir. Aynı zamanda, yaygın düzeltmeler hakkında içgörüler sunar, bir bilgi tabanı oluşturmaya veya otomasyonun uygulanabileceği alanları belirlemeye yardımcı olur.
Neden önemli
Olay sonuçları hakkında yapılandırılmış veri sağlayarak kök neden analizini ve bilgi yönetimi ile otomasyonun geliştirilmesini destekler.
Nereden alınır
BMC Helix dokümantasyonuna bakın. Bu alan genellikle olay formunun çözüm sekmesinde veya bölümünde bulunur.
Örnekler
Kullanıcı Hatası - Eğitim SağlandıYazılım Yaması UygulandıDonanım DeğiştirildiHata Bulunamadı
|
|||
|
Çözüm Süresi
ResolutionDuration
|
Bir olayın ilk bildirildiği andan çözüldüğü ana kadar geçen toplam süre. | ||
|
Açıklama
Bu ölçüt, 'Olay Bildirildi' aktivitesinden 'Olay Çözüldü' aktivitesine kadar olan süreyi ölçer. Bu, tüm olay yönetimi sürecinin verimliliği için temel bir performans göstergesidir (KPI). Hesaplanan bu öznitelik, 'Ortalama Olay Çözüm Süresi' KPI'ı ve 'Olay Çözüm Süresi' dashboard'ının temelini oluşturur. Bu süreyi farklı olay kategorileri, öncelikleri veya ekipler genelinde analiz etmek, gecikmelerin sistematik kaynaklarını belirlemeye ve süreç iyileştirme girişimlerinin etkisini ölçmeye yardımcı olur.
Neden önemli
Bu, süreç verimliliğinin ve müşteri deneyiminin birincil bir ölçütüdür ve kullanıcılar için hizmetin ne kadar sürede geri yüklendiğini doğrudan yansıtır.
Nereden alınır
Veri dönüşümü sırasında, her vaka için 'Incident Resolved' aktivitesinin zaman damgası ile 'Incident Reported' aktivitesinin zaman damgası arasındaki süre farkı bulunarak hesaplanır.
Örnekler
25920000086400000604800000
|
|||
|
İş Hizmeti
BusinessService
|
Olaydan etkilenen iş hizmeti veya uygulama. | ||
|
Açıklama
Bu öznitelik, bir olayı Konfigürasyon Yönetim Veritabanı (CMDB) içinde tanımlanan belirli bir iş hizmetine (örneğin 'Email Service' veya 'ERP System') bağlar. Olayları etkilenen iş hizmetine göre analiz etmek, kuruluş üzerindeki etkiyi anlamak için kritik öneme sahiptir. En çok olay üreten veya en çok kesinti yaşayan hizmetler üzerindeki problem yönetimi çabalarını önceliklendirmeye yardımcı olur. Bu bakış açısı, BT performansını iş odaklı bir açıdan raporlamak için temeldir.
Neden önemli
Teknik olayları iş etkisiyle ilişkilendirir; kurum için en kritik olanı öne alan önceliklendirme yapmayı sağlayan analizleri mümkün kılar.
Nereden alınır
Bu, olay formunda CMDB'ye bağlantı sağlayan bir Yapılandırma Öğesi (CI) alanıdır. Bu alan 'Hizmet' veya 'CI' olarak etiketlenebilir.
Örnekler
Kurumsal E-posta HizmetiSAP ERP FinansMüşteri İlişkileri Yönetimi
|
|||
|
Kanal
Channel
|
Olayın bildirildiği yöntem veya kanal. | ||
|
Açıklama
Channel niteliği, bir olayın nasıl başlatıldığını, örneğin telefon araması, e-posta, self-service portalı veya otomatik izleme yoluyla olduğunu belirtir. Süreci kanala göre analiz etmek, çözüm sürelerinde veya süreç yollarında önemli farklılıkları ortaya çıkarabilir. Örneğin, self-service portalı üzerinden bildirilen olaylar, daha iyi başlangıç veri kalitesi nedeniyle daha hızlı çözülebilir. Bu analiz, hangi kanalların destekleneceği veya iyileştirileceği konusunda kararlara rehberlik edebilir.
Neden önemli
Bildirim yönteminin olay yaşam döngüsünü nasıl etkilediğini anlamaya yardımcı olur; belirli kanalları verimlilik için optimize etme fırsatlarını ortaya çıkarır.
Nereden alınır
'HPD:Help Desk' formunda standart bir alan, genellikle 'Reported Source' olarak adlandırılır.
Örnekler
E-postaTelefonSelf-service PortalıSistem İzleme
|
|||
|
SLA İhlal Edildi mi?
IsSlaBreached
|
Olay çözüm süresinin SLA hedefini aşıp aşmadığını gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu, 'SLA Durumu' özniteliğinden türetilen basitleştirilmiş bir göstergedir; burada 'true' değeri SLA'nın ihlal edildiğini gösterir. Bu, kolay filtreleme ve toplama için net, ikili bir sonuç sunar. Bu öznitelik, 'Kritik Olay SLA İhlal Oranı' KPI'ını hesaplamak için kullanılır. Hizmet hedeflerini karşılayamayan olaylar arasında en yaygın olan süreç özelliklerini analiz etmek için tüm olayları ihlale uğrayan ve uğramayan olmak üzere iki gruba kolayca ayırmayı sağlar.
Neden önemli
SLA uyumluluğu için basit, ikili bir sonuç sunar, böylece ihlâl oranlarını hesaplamayı ve uyumsuz durumların yaygın yollarını analiz etmeyi kolaylaştırır.
Nereden alınır
Veri dönüşümü sırasında 'SLAStatus' özniteliğinden türetilir. 'SLAStatus' 'Breached' ise bu bayrak true olarak işaretlenir.
Örnekler
truefalse
|
|||
|
Yeniden Açıldı mı?
IsReopened
|
Bir olayın çözüldükten sonra yeniden açılıp açılmadığını gösteren bir bayrak. | ||
|
Açıklama
Bu hesaplanan öznitelik, bir olayın geçmişinde 'Incident Reopened' aktivite'si varsa doğru olan bir boolean bayraktır. Yeniden açılan olayların yüksek oranı, çözümlerin kalitesi veya ticket'ların erken kapanmasıyla ilgili sorunları işaret edebilir. Bu bayrak, 'Incident Re-opening Rate' KPI'ını ve 'Incident Re-opening Rate Trend' dashboard'unu hesaplamada doğrudan kullanılır. Analistlerin yeniden açılan olayları kolayca filtrelemesine ve eksik düzeltmeler veya kullanıcıyla yanlış iletişim gibi temel nedenleri anlamak için incelemesine olanak tanır.
Neden önemli
Bu bayrak, çözüm kalitesini ve müşteri memnuniyetini doğrudan ölçer ve ilk düzeltmenin etkili olmadığı case'leri (durumları) vurgular.
Nereden alınır
Bu, bir olayın Event Log'unda 'Reopened' aktivitesi veya durum geçişi olup olmadığını kontrol ederek veri dönüşümü sırasında oluşturulan hesaplanmış bir alandır.
Örnekler
truefalse
|
|||
|
Yeniden Atama Sayısı
ReassignmentCount
|
Bir olayın farklı destek grupları arasında aktarılma sayısı. | ||
|
Açıklama
Bu hesaplanan öznitelik, bir olayın yaşam döngüsü boyunca 'AssignedSupportGroup' alanının kaç kez değiştiğini sayar. Sıklıkla 'ticket ping-pong' olarak adlandırılan yüksek sayıda yeniden atama, yanlış başlangıç yönlendirmesi veya destek ekipleri içindeki bilgi boşlukları gibi süreç verimsizliklerini gösterir. Bu metrik, 'Average Reassignments per Incident' KPI'ı ve 'Incident Reassignment Analysis' dashboard'unun çekirdeğidir. Bu sayıyı izlemek, ilk çağrıda çözüm oranlarını iyileştirme ve yönlendirme sürecini kolaylaştırma fırsatlarını belirlemeye yardımcı olarak, nihayetinde çözüm süresini azaltır.
Neden önemli
Süreç verimsizliğini ve sürtüşmeyi ölçer, ekipler arasında aktarılmaktan dolayı çözümü geciken olayları vurgular.
Nereden alınır
Veri dönüşümü sırasında, her olayın yaşam döngüsü boyunca 'AssignedSupportGroup' alanındaki benzersiz değerlerin veya değişikliklerin sayılmasıyla hesaplanır.
Örnekler
0135
|
|||
Olay Yönetimi Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm Tespit Edildi
|
Bir destek temsilcisinin bir çözüm bulduğu ve bunu olay kaydına belgelediği anı temsil eder. Olay artık 'Çözüldü' durumuna geçirilmeye hazırdır. | ||
|
Neden önemli
Bu dönüm noktası, teknik inceleme aşamasının sonunu işaret eder. Bu noktadan kapanışa kadar olan süre, iletişim, doğrulama ve idari süreçlerdeki darboğazları ortaya çıkarabilir.
Nereden alınır
Bu, çözüm detayları girilip kaydedildiğinde, yani durum 'Çözüldü' olarak değiştirilmeden hemen önce, genellikle zaman damgasından çıkarılır.
Yakala
Durum 'Çözüldü' olarak değişmeden önceki son değişikliğin timestamp'ini kullanın.
Event tipi
inferred
|
|||
|
Destek Grubuna Atandı
|
Bu aktivite, olayın inceleme ve çözümü için belirli bir destek grubuna ilk atanmasını ifade eder. Servis masası'ndan teknik bir ekibe yapılan ilk devri temsil eder. | ||
|
Neden önemli
Bu, ilk temas çözümü oranlarını ve ilk yanıt sürelerini izlemek için kritik bir dönüm noktasıdır. Olayın doğru ekibe ulaşmasındaki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
Olayın denetim geçmişinde (HPD:HelpDesk_AuditLogSystem) 'Assigned Group' alanının ilk kez doldurulduğu an izlenerek tespit edilir.
Yakala
Denetim log'larındaki 'Atanan Grup' alanına yapılan ilk kaydedilen değişiklikten çıkarılmıştır.
Event tipi
inferred
|
|||
|
Geçici Çözüm Uygulandı
|
Kullanıcıya geçici bir çözüm sağlandığını, kalıcı bir düzeltme geliştirilirken hizmet işlevselliğinin geri yüklendiğini gösterir. Bu durum genellikle belirli bir flag veya durum ayarlanarak kaydedilir. | ||
|
Neden önemli
Bunu izlemek, hizmetin eski haline getirilme hızını ölçmeye yardımcı olur ve bu da kullanıcı memnuniyeti için kritiktir. Süreç analizinde geçici düzeltmeleri kalıcı çözümlerden ayırır.
Nereden alınır
Bu, olay çözüm detaylarındaki 'Geçici Çözüm' alanı doldurulduğunda veya belirli bir 'Geçici Çözüm Sağlandı' durumu kullanıldığında timestamp'ten (zaman damgasından) çıkarılabilir.
Yakala
Bir 'Geçici Çözüm' durumuna geçişinin timestamp'ini veya bir geçici çözümü gösteren çözüm notlarının ilk kaydedildiği timestamp'i kullanın.
Event tipi
inferred
|
|||
|
Olay Bildirildi
|
Sistemde yeni bir olay kaydının oluşturulmasını işaretler. Bu, olay yaşam döngüsünün başlangıç noktasıdır ve genellikle bir kullanıcının portal, e-posta aracılığıyla gönderimi veya bir hizmet masası uzmanının bileti manuel olarak oluşturmasıyla tetiklenir. | ||
|
Neden önemli
Bu aktivite, süreç için birincil başlangıç event'idir. Bu event'ten çözüme kadar geçen süreyi analiz etmek, genel olay yaşam döngüsü süresini ölçmek ve yukarı akış gecikmelerini belirlemek için temeldir.
Nereden alınır
Bu, HPD:Help Desk formunda 'Gönderim Tarihi' veya 'Bildirim Tarihi' zaman damgasından yakalanan açık bir oluşturma olayıdır. Sistemdeki en güvenilir ve temel olaylardan biridir.
Yakala
HPD:Help Desk tablosundaki olay kaydının oluşturma zaman damgasından alınır.
Event tipi
explicit
|
|||
|
Olay Çözüldü
|
Bir çözümün uygulandığını ve hizmetin kullanıcı için geri yüklendiğini gösterir. Bu, genellikle durumun 'Çözüldü' olarak değişmesiyle kaydedilen önemli bir aşamadır. | ||
|
Neden önemli
Bu, temel çözüm süresini ölçmek için birincil bir dönüm noktasıdır. Aktif çalışma aşamasının sonunu işaret eder ve genellikle kullanıcı onayı veya otomatik kapatma prosedürleri için süreci başlatır.
Nereden alınır
Bu, 'Durum' alanı 'Çözüldü' olarak güncellendiğinde zaman damgasından çıkarılan ayrı bir olaydır. Bu değişiklik denetim geçmişinde kaydedilir.
Yakala
Audit log'larda 'Resolved' durumuna geçişi filtreleyin.
Event tipi
inferred
|
|||
|
Olay Kapatıldı
|
Yaşam döngüsündeki son aktivite olup, olay kaydının resmi olarak kapatıldığı ve salt okunur bir geçmiş kaydı haline geldiği adımdır. Bu genellikle 'Resolved' durumunda belirli bir sürenin ardından otomatik olarak gerçekleşir. | ||
|
Neden önemli
Bu aktivite, sürecin kesin sonunu işaret eder. 'Çözüldü' ve 'Kapandı' arasındaki süre, idari süreçlerde veya kullanıcı onay pencerelerindeki gecikmeleri vurgulayabilir.
Nereden alınır
Bu, 'Durum' alanı 'Kapalı' olarak güncellendiğinde zaman damgasından çıkarılan ayrı bir olaydır. Bu, denetim geçmişinde izlenir.
Yakala
Audit log'larda 'Closed' durumuna geçişi filtreleyin.
Event tipi
inferred
|
|||
|
Askıdaki Durumdan Devam Edildi
|
Beklemede olan bir olayın yeniden etkinleştirildiği noktayı işaretler. Bu, gerekli bilgiler alındığında gerçekleşir ve genellikle durumun 'Askıda' (Pending) konumundan 'Devam Ediyor' (In Progress) konumuna geçişiyle gösterilir. | ||
|
Neden önemli
Bu event, 'Incident Put On Hold' ile eşleştirildiğinde, bekleme sürelerinin hassas bir şekilde ölçülmesini sağlar. Uzun bekleme sürelerini analiz etmek, kullanıcılar veya üçüncü taraflarla yaşanan iletişim sorunlarını vurgulayabilir.
Nereden alınır
'Beklemede' durumundan 'Devam Ediyor' gibi aktif bir duruma geçişten çıkarılmıştır. Timestamp denetim log'unda mevcuttur.
Yakala
Audit log'larda durumun 'Pending'den 'In Progress'e veya 'Assigned'a değiştiği kayıtları filtreleyin.
Event tipi
inferred
|
|||
|
Başka Bir Gruba Aktarıldı
|
Bir olayın bir destek grubundan diğerine yeniden atanmasını temsil eder. Bu durum genellikle başlangıçtaki grubun sorunu çözememesi ve farklı bir ekipten uzmanlık gerektirmesi halinde meydana gelir. | ||
|
Neden önemli
Sık yapılan transferler, yani 'ping-pong', gecikme ve verimsizliğin başlıca nedenlerindendir. Bu aktiviteleri analiz etmek yönlendirme sorunlarını, yetkinlik açıklarını ve süreç darboğazlarını ortaya çıkarmaya yardımcı olur.
Nereden alınır
Olayın denetim geçmişindeki 'Atanan Grup' alanının değerindeki bir değişiklikten, ilk atamadan sonra çıkarılmıştır.
Yakala
İlk atamadan sonra audit log'da 'Assigned Group' alanına yapılan her değişiklik bir transferi ifade eder.
Event tipi
inferred
|
|||
|
Kullanıcı Onayı Alındı
|
Kullanıcının sunulan çözümün sorunlarını giderdiğini onayladığını temsil eder. Bu genellikle isteğe bağlı bir adımdır ve bir portal eylemi veya bir çalışan tarafından kaydedilebilir. | ||
|
Neden önemli
Kullanıcı onaylarının oranını ve hızını analiz etmek, iletişim etkinliğini ve çözüm kalitesini değerlendirmeye yardımcı olur. Düşük bir onay oranı, daha yüksek bir yeniden açılma oranına yol açabilir.
Nereden alınır
Bu, doğrudan yakalanması zordur ve çıkarım yapılması gerekebilir. 'Çözüldü - Onaylandı' gibi belirli bir durum veya olay iş günlüğüne eklenen bir not olabilir.
Yakala
Sistem analizi gerektirir. Kullanıcı geri bildirimini gösteren iş günlüğü girişleri veya durum değişikliklerini arayın.
Event tipi
inferred
|
|||
|
Olay Beklemeye Alındı
|
Bu aktivite, bir olayın ilerlemesi duraklatıldığında, tipik olarak kullanıcıdan veya harici bir satıcıdan bilgi beklenirken gerçekleşir. Bu durum genellikle 'Beklemede' statüsüne bir değişiklik olarak yansır. | ||
|
Neden önemli
Bu aktivite, çözüm sürelerini doğru bir şekilde hesaplamak için çok önemlidir. 'Beklemede' durumunda geçirilen süre, destek ekibi performansını adil bir şekilde ölçmek için genellikle SLA hesaplamalarından hariç tutulmalıdır.
Nereden alınır
'Durum' alanında 'Beklemede' durumuna geçişten çıkarılmıştır. Denetim log'u bu değişikliğin timestamp'ini izler.
Yakala
Audit log'larda 'Pending' veya benzeri beklemede durumuna yapılan değişiklikleri filtreleyin.
Event tipi
inferred
|
|||
|
Olay Kategorize Edildi
|
Olayın kategori, tür ve öğesinin belirlenmesi de dahil olmak üzere başlangıçtaki sınıflandırmasını temsil eder. Bu aktivite genellikle olay raporlandıktan kısa bir süre sonra bir Seviye 1 hizmet masası uzmanı tarafından gerçekleştirilir. | ||
|
Neden önemli
Bu etkinliği izlemek, ilk sınıflandırmaların doğruluğunu ve bunun yönlendirme ve çözüme etkisini analiz etmeye yardımcı olur. Sürecin ilerleyen aşamalarında kategorizasyondaki değişiklikler, yeniden çalışma ve potansiyel bilgi eksikliklerine işaret eder.
Nereden alınır
İşletimsel ve ürün kategorizasyon alanlarının ('OpCat', 'ProdCat') olayın denetim log'unda (HPD:HelpDesk_AuditLogSystem) ilk kez doldurulmasından çıkarılmıştır.
Yakala
Denetim günlüğünde kategorizasyon alanlarının ilk kez ne zaman belirlendiğini tespit edin.
Event tipi
inferred
|
|||
|
Olay Yeniden Açıldı
|
Daha önce çözülen veya kapatılan bir olayın tekrar aktif duruma getirilmesidir. Bu durum genellikle kullanıcının sorunun tekrar ettiğini bildirmesiyle ortaya çıkar. | ||
|
Neden önemli
Yüksek bir yeniden açılma oranı, çözüm kalitesindeki sorunları gösterir. Bu yeniden işleme döngüsünü takip etmek, etkisiz düzeltmelerin temel nedenlerini belirlemek ve ilk çağrıda çözümü iyileştirmek için hayati önem taşır.
Nereden alınır
'Çözüldü' veya 'Kapatıldı' durumundan 'Devam Ediyor' veya 'Atandı' gibi aktif bir duruma geçişten çıkarılmıştır. Bu geçiş denetim geçmişine kaydedilmiştir.
Yakala
Audit log'larda çözülmüş/kapanmış durumdan açık duruma dönüşü gösteren değişiklikleri filtreleyin.
Event tipi
inferred
|
|||
|
SLA İhlali Tespit Edildi
|
Bir olaya yanıt verme veya çözme süresinin, Hizmet Seviyesi Anlaşması (SLA) hedeflerini aştığında ortaya çıkan hesaplanmış bir eventtir. Bu doğrudan bir sistem event'i değildir. | ||
|
Neden önemli
SLA ihlallerini tespit etmek, uyumluluk takibi ve kritik olayların önceliklendirilmesi için hayati öneme sahiptir. Bu, sürecin hangi aşamalarının ihlallere en çok katkıda bulunduğunu belirlemeye yardımcı olur.
Nereden alınır
Bu event, 'Incident Resolved' aktivite'sinin (veya diğer SLA kilometre taşlarının) timestamp'i, 'Bildirim Tarihi' ve olayın önceliği için tanımlanmış SLA hedefi karşılaştırılarak hesaplanır.
Yakala
Çözüm zaman damgasını, başlangıç zaman damgasına SLA süresi eklenmiş hâliyle karşılaştırarak türetilir.
Event tipi
calculated
|
|||
|
Soruşturma Başladı
|
Atanan bir temsilcinin olayın üzerinde aktif olarak çalışmaya başladığını gösterir. Bu durum, genellikle 'Atandı'dan 'Devam Ediyor'a veya benzer bir duruma geçişle temsil edilir. | ||
|
Neden önemli
Atama ile inceleme başlangıcı arasındaki süreyi ölçmek, kuyruk gecikmelerini ortaya çıkarır ve çalışan yanıt verme hızını ve iş yükü kapasitesini değerlendirmeye yardımcı olur.
Nereden alınır
Bu, 'Durum' alanındaki 'Atandı'dan 'Devam Ediyor'a yapılan bir değişiklikten çıkarılır. Bu durum değişikliğinin zaman damgası denetim günlüğüne kaydedilir.
Yakala
Atama sonrası ilk kez 'In Progress' durumuna geçişi içeren audit log'ları filtreleyin.
Event tipi
inferred
|
|||