Hizmet talebi yönetimi Veri Templateiniz
Hizmet talebi yönetimi Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- Süreç keşfi için izlenecek önemli etkinlikler
- Kaynak sisteminizden veri çıkarma yönergeleri
Hizmet talebi yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Etkinlik adı
ActivityName
|
Hizmet talebinin yaşam döngüsünde belirli bir anda gerçekleşen olayın veya görevin adı. | ||
|
Açıklama
Bu öznitelik, 'Talep onaya gönderildi' veya 'Hizmet talebi çözüldü' gibi hizmet talebi sürecindeki belirli bir adımı ya da durum değişikliğini açıklar. Etkinliklerin sırasını ve sıklığını analiz etmek; süreç akışını anlamak, darboğazları belirlemek ve standart prosedürden sapmaları keşfetmek için temel önemdedir.
Neden önemli?
Süreç haritasındaki adımları tanımlar; yeniden çalışmaları, darboğazları ve sapmaları belirlemek dahil olmak üzere süreç akışını görselleştirip analiz etmenizi sağlar.
Nereden alınır?
Genellikle Ivanti Service Manager içindeki durum değişikliklerinden, günlük kayıtlarından veya denetim günlüğü olay açıklamalarından elde edilir.
Örnekler
Hizmet talebi oluşturulduTalep onaylandıHizmet talebi çözüldüHizmet talebi kapatıldı
|
|||
|
Hizmet Talebi kimliği
ServiceRequestID
|
Her hizmet talebini benzersiz biçimde tanımlayan kimlik. | ||
|
Açıklama
Hizmet Talebi kimliği, kullanıcı veya sistem tarafından gönderilen her bir hizmet talebini benzersiz biçimde tanımlar. İlk kayıttan son kapatmaya kadar sonraki tüm olayları birbirine bağlayan temel referanstır ve her hizmet talebinin yolculuğunu baştan sona analiz etmenizi sağlar.
Neden önemli?
Bu temel vaka tanımlayıcısı, ilgili tüm etkinlikleri tek bir süreç örneğinde birleştirerek süreci baştan sona analiz etmenizi sağlar.
Nereden alınır?
Bu, Hizmet Talebi iş nesnesinin birincil anahtarıdır ve genellikle ServiceReq tablosunda ServiceReqNumber adıyla bulunur.
Örnekler
SR-0012345SR-0012346SR-0012347
|
|||
|
Olay zamanı
EventTime
|
Belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
|
Açıklama
Başlangıç zamanı olarak da bilinen olay zamanı, bir etkinliğin sisteme kaydedildiği kesin tarih ve saattir. Bu zaman damgası, olayları doğru sıraya koymak için gereklidir ve çevrim süreleri, bekleme süreleri ve etkinlik süreleri gibi zamana dayalı tüm Process Mining analizlerinin temelini oluşturur.
Neden önemli?
Bu zaman damgası, olayları kronolojik sıraya koymak ve performans analizinde önemli olan süreye dayalı tüm metrikleri hesaplamak için gereklidir.
Nereden alınır?
Denetim günlüklerinde, günlük kayıtlarında (ör. Journal.CreatedDateTime) veya Hizmet Talebiyle ilişkili durum değişikliği kayıtlarında bulunur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Kaynak sistem
SourceSystem
|
Verilerin çıkarıldığı sistem. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu görünümde değer sabittir ve tüm verilerin Ivanti Service Manager’dan geldiğini gösterir. Verilerin birden fazla sistemden birleştirilebildiği ortamlarda, veri kaynağının ve bağlamının açıkça anlaşılmasını sağlar.
Neden önemli?
Verilerin nereden geldiğine ilişkin önemli bağlamı sunar. Özellikle birden fazla sistemin kullanıldığı ortamlarda analizlerin doğru kaynak sisteme atfedilmesini sağlar.
Nereden alınır?
Genellikle veri çıkarma sırasında veri setinin kaynağını belirtmek için eklenen sabit bir değerdir.
Örnekler
Ivanti Service Manager
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Kaynak sistemden yapılan en son veri yenilemesinin zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin Ivanti Service Manager’dan en son çıkarıldığı tarih ve saati gösterir. Analiz edilen verilerin ne kadar güncel olduğunu ve hangi dönemi kapsadığını anlamanıza, ayrıca bir sonraki güncellemenin ne zaman beklendiğini görmenize yardımcı olur.
Neden önemli?
Kullanıcıları verilerin güncelliği hakkında bilgilendirir. Bu bilgi, mevcut süreç performansına ilişkin en güncel verilerle karar almak için önemlidir.
Nereden alınır?
Bu değer, veri çıkarma sırasında oluşturulur ve veri setine eklenir.
Örnekler
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Atanan ekip
AssignedTeam
|
Hizmet talebini şu anda ele almakla görevlendirilen destek ekibi veya grubu. | ||
|
Açıklama
Bu öznitelik, belirli bir anda hizmet talebinden sorumlu ekibi gösterir. Ekipler arasındaki devir teslimleri, her ekibin talep üzerinde harcadığı süreyi ve ekiplerin ele aldığı talep sayısını incelemek; iş yükü dağılımını anlamak, darboğazları belirlemek ve ekip performansını değerlendirmek açısından önemlidir. SLA uyumluluğu ve temsilci iş yüküyle ilgili Dashboardları doğrudan destekler.
Neden önemli?
Sorumlulukları ve devir teslimleri izleyerek ekipler arası gecikmeleri, iş yükü dengesini ve süreçte darboğaz oluşturan ekipleri incelemeye yardımcı olur.
Nereden alınır?
Bu bilgi genellikle Hizmet Talebi nesnesindeki OwnerTeam gibi bir alanda veya ilişkili atama kayıtlarında saklanır.
Örnekler
BT Hizmet MasasıAğ operasyonlarıİK desteğiTesis yönetimi
|
|||
|
Atanan temsilci
AssignedAgent
|
Hizmet talebiyle ilgilenmek üzere görevlendirilen kullanıcı veya temsilci. | ||
|
Açıklama
Atanan temsilci, hizmet talebi üzerinde çalışmaktan sorumlu kişidir. Bu öznitelik, performans yönetimi, iş yükü dengeleme ve eğitim ihtiyaçlarını belirleme amacıyla kişi düzeyinde analiz yapmayı sağlar. Temsilciler arasındaki yeniden atamaları izlemek, Talep başına ortalama yeniden atama gibi temel performans göstergelerini (KPI) hesaplamak ve süreçteki verimsizlikleri anlamak için önemlidir.
Neden önemli?
Kişi bazında iş yükünü, performansı ve yeniden atama örüntülerini incelemeyi sağlar. Bu örüntüler eğitim, beceri düzeyleri veya ilk yönlendirmeyle ilgili sorunlara işaret edebilir.
Nereden alınır?
Bu bilgi genellikle Hizmet Talebi nesnesindeki Owner gibi bir alanda bulunur. Her yeniden atamada değişebileceğinden olay günlüğünde izlenmelidir.
Örnekler
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Çözüm zaman damgası
ResolutionDateTime
|
Hizmet talebinin resmen çözüme kavuşturulduğu tarih ve saat. | ||
|
Açıklama
Bu vaka düzeyindeki öznitelik, talep resmen kapatılmadan önce hizmetin sunulduğu veya sorunun giderildiği son zamanı gösterir. Hizmet talebinin uçtan uca çevrim süresini hesaplamak için kullanılan temel zaman damgasıdır. Genel süreç verimliliğini ve SLA uyumluluğunu ölçmeye yardımcı olur.
Neden önemli?
Temel süreç çevrim süresinin hesaplanacağı bitiş noktasını belirler. Bu süre, hizmet sunumunun verimliliğini ölçmek için kullanılan önemli bir göstergedir.
Nereden alınır?
Hizmet Talebi nesnesinde bulunan ve genellikle ResolvedDateTime benzeri bir ad taşıyan özel bir zaman damgası alanı.
Örnekler
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Hizmet talebi durumu
ServiceRequestStatus
|
Olay gerçekleştiği sırada hizmet talebinin durumu. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin Kaydedildi, Devam ediyor, Beklemede, Çözüldü veya Kapatıldı gibi durumunu gösterir. Durum değişiklikleri, süreç günlüğündeki etkinlikleri tanımlamak için sıkça kullanılır. Her durumda geçirilen süreyi incelemek, örneğin taleplerin Beklemede durumunda gereğinden uzun kalması gibi darboğazları ortaya çıkarabilir.
Neden önemli?
Talebin belirli bir andaki durumunu gösterir. Böylece belirli durumlarda geçirilen süre hesaplanabilir ve süreçteki tıkanmalar belirlenebilir.
Nereden alınır?
Hizmet Talebi nesnesinde genellikle Status olarak adlandırılan standart bir alan.
Örnekler
KaydedildiEtkinMüşteri bekleniyorYerine getirildiKapatıldı
|
|||
|
Hizmet talebi türü
ServiceRequestType
|
Hizmet talebinin sınıflandırması veya kategorisi. | ||
|
Açıklama
Bu öznitelik, hizmet taleplerini örneğin Donanım talebi, Yazılım kurulumu veya Parola sıfırlama gibi kategorilere ayırır. Ekiplerin farklı hizmet türlerindeki süreç performansını, çevrim sürelerini ve SLA uyumluluğunu karşılaştırmasına olanak tanır. Bu farkları anlamak, süreç iyileştirmelerini ihtiyaca göre planlamaya ve kaynakları daha verimli dağıtmaya yardımcı olur.
Neden önemli?
Süreci talep türüne göre bölümlere ayırmak, belirli talep türlerinin gecikmeye, yeniden çalışmaya veya SLA ihlaline daha yatkın olup olmadığını ortaya çıkarır.
Nereden alınır?
Bu alan genellikle Hizmet Talebi iş nesnesinde bulunur ve çoğu zaman Service veya Category olarak adlandırılır. SvcReqTmplLink_Category gibi alan adları için Ivanti Service Manager dokümantasyonuna başvurun.
Örnekler
Yeni donanım talebiYazılım erişimiHesap değişikliğiBilgi talebi
|
|||
|
Olay bitiş zamanı
EventEndTime
|
Bir etkinliğin tamamlandığı zamanı gösteren zaman damgası. | ||
|
Açıklama
Olay bitiş zamanı, bir etkinliğin tamamlandığını gösterir. Olay zamanı (başlangıç) ile olay bitiş zamanı arasındaki süre, ilgili etkinliğin işlem süresidir. Bu bilgi, süreçte en çok zaman alan adımları ve iyileştirme fırsatlarını belirlemeye yardımcı olur.
Neden önemli?
Her etkinliğin süresini hesaplamayı sağlar. Bu, süreçteki darboğazları ve uzun süren görevleri belirlemek için gereklidir.
Nereden alınır?
Ayrı bir alan olarak bulunmayabilir. Çoğu zaman aynı vakadaki sıradaki etkinliğin başlangıç zamanı olarak kullanılır.
Örnekler
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Öncelik
Priority
|
Hizmet talebine atanan öncelik düzeyi. | ||
|
Açıklama
Öncelik, hizmet talebinin aciliyetini gösterir ve genellikle Düşük, Orta, Yüksek veya Kritik gibi düzeylerle ifade edilir. Bu öznitelik, sürecin yüksek öncelikli talepleri gerçekten öne alıp almadığını değerlendirmek için kullanılır. Öncelik kurallarının beklendiği gibi işleyip işlemediğini görmek amacıyla farklı öncelik düzeylerindeki çevrim süreleri ve SLA uyumluluğu karşılaştırılır.
Neden önemli?
Önceliklendirme stratejisinin ne kadar etkili olduğunu değerlendirmeye ve yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı çözüldüğünü doğrulamaya yardımcı olur.
Nereden alınır?
Hizmet Talebi nesnesinde genellikle Priority olarak adlandırılan standart bir alan.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
SLA durumu
SLAStatus
|
Hizmet talebinin SLA son tarihine kadar çözülüp çözülmediğini gösterir. | ||
|
Açıklama
Bu türetilmiş öznitelik, çözüm zamanını SLA son tarihiyle karşılaştırarak her hizmet talebini Karşılandı veya İhlal edildi olarak işaretler. SLA uyumluluk performansı Dashboardunun ve Hizmet Seviyesi Anlaşması uyumluluk oranı temel performans göstergesinin (KPI) temelini oluşturur. Her vaka için ResolutionDateTime ile SLADeadline değerlerini karşılaştırır.
Neden önemli?
Hizmet taahhütlerine göre performansı doğrudan ölçer. Hizmet kalitesini değerlendirmek ve kullanıcıların güvenini korumak için önemlidir.
Nereden alınır?
ResolutionDateTime ile SLADeadline karşılaştırılarak hesaplanır. ResolutionDateTime <= SLADeadline ise durum Karşılandı, değilse İhlal edildi olur.
Örnekler
Karşılandıİhlal edildi
|
|||
|
SLA son tarihi
SLADeadline
|
Hizmet talebinin çözülmesinin beklendiği son zamanı gösteren zaman damgası. | ||
|
Açıklama
SLA son tarihi, hizmet talebinin Hizmet Seviyesi Anlaşması’na uyması için çözülmesi gereken tarih ve saattir. Bu hedef genellikle talebin önceliği ve türü gibi etkenlere göre belirlenir. Gerçek çözüm zamanını bu son tarihle karşılaştırmak, SLA uyumluluğunu ölçmenin temelini oluşturur.
Neden önemli?
Gerçek performansın karşılaştırıldığı ölçüttür. SLA uyumluluk oranlarını hesaplamayı ve risk altındaki talepleri belirlemeyi doğrudan destekler.
Nereden alınır?
Ivanti içinde genellikle hesaplanan bir alandır. ResolutionTargetDateTime gibi alanlarda, Hizmet Seviyesi Anlaşması veya Teklif ile ilişkili olarak saklanabilir.
Örnekler
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Atama sayısı
AssignmentCount
|
Bir hizmet talebinin kaç kez atandığını veya yeniden atandığını gösteren toplam sayı. | ||
|
Açıklama
Bu hesaplanan metrik, her hizmet talebi için atamayla ilgili etkinliklerin sayısını hesaplar. Bunlara Ekibe atandı ve Temsilciye atandı gibi etkinlikler dahildir. Sık yeniden atama, genellikle talebin ekipler arasında gidip gelmesi olarak anılır ve yönlendirme verimsizliğine, ilk temasta çözülemeyen taleplere veya ekip sorumluluklarının belirsizliğine işaret eder. Bu öznitelik, Talep başına ortalama yeniden atama temel performans göstergesinin (KPI) hesaplanması için gereklidir.
Neden önemli?
Verimsiz devir teslimleri ve yönlendirme sorunlarını ölçer. Sayının yüksek olması, çözüm sürelerinin uzadığına ve kullanıcıların memnuniyetsiz kaldığına işaret edebilir.
Nereden alınır?
Veri hazırlığı sırasında her benzersiz ServiceRequestID için atamayla ilgili etkinliklerin sayısı hesaplanarak elde edilir.
Örnekler
12345
|
|||
|
Çözüm kategorisi
ResolutionCategory
|
Hizmet talebine sunulan çözümün sınıflandırması. | ||
|
Açıklama
Çözüm kategorisi, hizmet talebinin nasıl çözüldüğünü yapılandırılmış biçimde sınıflandırır. Genellikle kategori ve alt kategori gibi hiyerarşik sınıflandırmalar kullanılır; bunlar temel neden analizine ve eğilim raporlamasına yardımcı olur. Örneğin yinelenen sorunları veya sık kullanılan çözüm işlemlerini ortaya çıkarabilir. Bu bilgiler hizmetleri iyileştirmek veya bilgi bankası makaleleri hazırlamak için kullanılabilir.
Neden önemli?
Çözümlerin niteliğini anlamaya yardımcı olur; yaygın sorunları, hizmet iyileştirme fırsatlarını ve otomasyona uygun işleri belirlemeyi sağlar.
Nereden alınır?
Genellikle çözüm sırasında doldurulan sınıflandırma alanlarında saklanır. Bu alanlar ResolutionCategory veya özel bir kapatma kodu alanı olabilir.
Örnekler
Kullanıcı eğitimi gerekliYazılım dağıtıldıDonanım onarıldıErişim verildi
|
|||
|
Kanal
Channel
|
Hizmet talebinin gönderildiği yöntem veya kanal. | ||
|
Açıklama
Kanal, hizmet talebinin nasıl oluşturulduğunu gösterir. Talep self servis portalı, e-posta veya telefon aracılığıyla gönderilmiş ya da başka bir sistem tarafından otomatik olarak oluşturulmuş olabilir. Talepleri ve çözüm sürelerini kanala göre incelemek, hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi veya kullanıcı eğitimi gerektiğini anlamaya yardımcı olur.
Neden önemli?
Kullanıcı davranışını ve kanal verimliliğini anlamaya yardımcı olur. Bu bilgiler, hizmet sunum stratejisi ve otomasyon fırsatlarıyla ilgili kararlara yön verebilir.
Nereden alınır?
Bu bilgi genellikle Hizmet Talebi nesnesindeki Source veya CreatedBy türünde bir alanda saklanır.
Örnekler
Self servisE-postaTelefonDoğrudan giriş
|
|||
|
Talep sahibinin departmanı
RequestorDepartment
|
Hizmet talebini gönderen kullanıcının bağlı olduğu iş departmanı. | ||
|
Açıklama
Bu öznitelik, hizmet talebini başlatan çalışanın veya sistemin departmanını gösterir. Örneğin Satış, Finans veya İnsan Kaynakları olabilir. Kuruluşun farklı bölümlerindeki hizmet kalitesini ve talep yoğunluğunu incelemeyi sağlar. Böylece bazı departmanların daha uzun çözüm süreleriyle karşılaşıp karşılaşmadığı veya daha fazla talep gönderip göndermediği belirlenebilir.
Neden önemli?
İş birimine göre hizmet kullanımını ve kalitesini incelemeyi, departmana özgü sorunları veya eğilimleri belirlemeyi sağlar.
Nereden alınır?
Bu bilgi genellikle Hizmet Talebiyle ilişkilendirilmiş talep sahibinin kullanıcı profilinden alınır. Alan, Profile.Employee nesnesinde Department olarak adlandırılmış olabilir.
Örnekler
FinansSatışPazarlamaBilgi teknolojileri
|
|||
|
Tedarikçi adı
VendorName
|
Talebin çözümüne katkıda bulunan harici tedarikçinin adı. | ||
|
Açıklama
Bu öznitelik, hizmet talebine destek vermesi veya talebi tamamlaması için görevlendirilen üçüncü taraf tedarikçiyi gösterir. Farklı tedarikçilerin performansını ölçüp karşılaştırmayı sağladığından Harici tedarikçi etkinlik süresi Dashboardu için gereklidir. Bu bilgiyi izlemek, tedarikçi ilişkilerini yönetmeye ve dış bağımlılıkların yol açtığı darboğazları belirlemeye yardımcı olur.
Neden önemli?
Üçüncü tarafların performansını ve hizmet talebinin toplam çözüm süresine etkilerini incelemeyi sağlayarak tedarikçi yönetimini destekler.
Nereden alınır?
Bu bilgi, hizmet talebiyle ilişkili bir görev nesnesindeki alanda veya tedarikçi atanmışsa doğrudan Hizmet Talebi nesnesindeki özel bir alanda bulunabilir.
Örnekler
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
|
Yeniden açılma sayısı
ReopenCount
|
Çözüldükten sonra yeniden açılan hizmet talebinin kaç kez açıldığını gösterir. | ||
|
Açıklama
Bu sayaç, hizmet talebi Çözüldü veya Kapatıldı durumundan Etkin durumuna her döndüğünde bir artar. Yeniden açılma sayısının yüksek olması, ilk seferde çözüm kalitesinin düşük olduğuna, çözümün eksik kaldığına veya sorunun tekrarlandığına işaret edebilir. Hizmet talebinde yeniden çalışma oranı temel performans göstergesinin (KPI) hesaplanmasını doğrudan destekler.
Neden önemli?
Yeniden çalışmayı doğrudan ölçer ve çözüm kalitesini gösteren önemli bir göstergedir. Sayının yüksek olması, ilk çözümün etkili olmadığını düşündürür.
Nereden alınır?
Bu, genellikle durum uygun şekilde değiştiğinde bir iş kuralının artırdığı Hizmet Talebi nesnesindeki sayaç alanıdır. ReopenCounter olarak adlandırılmış olabilir.
Örnekler
0123
|
|||
|
Yeniden çalışma var
IsRework
|
Hizmet talebinde yeniden çalışma olup olmadığını gösteren mantıksal bir işaret. | ||
|
Açıklama
Bu hesaplanan işaret, hizmet talebinin çözümden sonra yeniden açılması veya bazı etkinliklerin döngü içinde tekrarlanması gibi yeniden çalışma belirtileri varsa true değerini alır. Hizmet talebinde yeniden çalışma oranı temel performans göstergesini (KPI) hesaplamayı kolaylaştırır ve Yeniden çalışma ve yeniden atama akışları gibi Dashboardlarda verimsiz süreç örneklerinin filtrelenmesine yardımcı olur.
Neden önemli?
Ek ve planlanmamış çaba gerektiren taleplerin sayısını kolayca belirleyip ölçmeye yardımcı olur; kalite ve verimlilik sorunlarını görünür kılar.
Nereden alınır?
Verilerden türetilir. Mantık, ReopenCount özniteliğinin sıfırdan büyük olmasına veya Bir temsilciye atandı gibi belirli etkinlik dizilerinin birden fazla kez gerçekleşmesinin saptanmasına dayanabilir.
Örnekler
truefalse
|
|||
Hizmet talebi yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi çözüldü
|
Hizmet talebi çözülmüş ve çözüm kullanıcıya sunulmuştur. Bu temel dönüm noktası, 'Resolved' durumuna geçişle kaydedilir ve çoğu zaman SLA sayacını durdurur. | ||
|
Neden önemli?
Bu, çözüm süresini ve SLA uyumunu ölçmek için temel bitiş noktasıdır. Oluşturulma anından bu etkinliğe kadar geçen süre, süreç performansının temel KPI’larından biridir.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Resolved' durumuna geçmesi ve buna karşılık gelen zaman damgasıyla anlaşılır.
Kaydedin
Denetim geçmişinden 'Status' alanının 'Resolved' olarak güncellendiğini tespit etme.
Olay türü
inferred
|
|||
|
Hizmet talebi kapatıldı
|
Hizmet talebi resmen kapatılmıştır ve artık başka işlem yapılamaz. Bu durum genellikle talep belirli bir süre 'Resolved' durumunda kaldıktan sonra otomatik olarak gerçekleşir ve yaşam döngüsünün sonunu gösterir. | ||
|
Neden önemli?
Bu etkinlik sürecin kesin bitiş noktasıdır. 'Resolved' ile 'Closed' arasında geçen süre, onay veya otomatik sistem işlemlerindeki gecikmeleri ortaya çıkarabilir.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Closed' durumuna geçmesi ve buna karşılık gelen zaman damgasıyla anlaşılır.
Kaydedin
Denetim geçmişinden 'Status' alanının 'Closed' olarak güncellendiğini tespit etme.
Olay türü
inferred
|
|||
|
Hizmet talebi oluşturuldu
|
Bu etkinlik, yeni bir talebin resmen iletilip Ivanti’ye kaydedilmesiyle hizmet talebi yaşam döngüsünü başlatır. Service Request iş nesnesinde yeni bir kayıt oluşturulduğunda ve benzersiz bir Hizmet Talebi kimliği üretildiğinde bu olay kaydedilir. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Bu noktadan çözüme kadar geçen süreyi analiz etmek, toplam çevrim süresini ve süreç verimliliğini ölçmenin temelidir.
Nereden alınır?
Bu bilgi, Hizmet Talebi kaydının oluşturulma zaman damgasından alınır (ör. ServiceReq iş nesnesindeki CreatedDateTime alanı).
Kaydedin
ServiceReq tablosundaki kayıt oluşturma olayı, oluşturulma zaman damgasıyla belirlenir.
Olay türü
explicit
|
|||
|
Talep ekibe atandı
|
Hizmet talebi, işleme alınması için belirli bir destek ekibine atanır. Bu bilgi, Hizmet Talebi kaydındaki 'OwnerTeam' alanının doldurulması veya değiştirilmesiyle kaydedilir. | ||
|
Neden önemli?
Bu olay, ekip performansını, iş yükü dağılımını ve ekipler arası devir teslim sürelerini analiz etmek için önemlidir. Süreçte hangi ekiplerin darboğaz oluşturduğunu belirlemeye yardımcı olur.
Nereden alınır?
Hizmet Talebi kaydının denetim geçmişinde veya günlüğünde 'OwnerTeam' alanındaki değişiklikler izlenerek kaydedilir.
Kaydedin
'OwnerTeam' alanındaki güncelleme olayı genellikle denetim izine kaydedilir.
Olay türü
explicit
|
|||
|
Talep temsilciye atandı
|
Belirli bir temsilci hizmet talebinin sorumluluğunu üstlenir. Bu etkinlik genellikle temsilciyi belirten 'Owner' alanının ilk kez doldurulması veya güncellenmesiyle anlaşılır. | ||
|
Neden önemli?
Bu etkinlik, ilk bekleme veya kuyruk süresinin sonunu gösterir. Bu noktaya kadar geçen süreyi ölçmek, kaynak dağılımındaki sorunları belirlemeye ve Temsilci iş yükü Dashboardunu desteklemeye yardımcı olur.
Nereden alınır?
Hizmet Talebi kaydındaki 'Owner' alanının doldurulması veya değiştirilmesiyle, denetim geçmişinden anlaşılır.
Kaydedin
Kayıt oluşturulduktan veya ekibe atandıktan sonra 'Owner' alanına bir temsilci adının ilk kez yazıldığı zaman damgası.
Olay türü
inferred
|
|||
|
Dış tedarikçi sürece dahil oldu
|
Hizmet talebinin karşılanması için görev dış tedarikçiye veya üçüncü tarafa devredilmiştir. Bu durum genellikle 'Waiting for 3rd Party' veya benzer bir duruma geçişle kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, tedarikçi performansını ve toplam çevrim süresine etkisini ölçmek için gereklidir. Tedarikçi kaynaklı gecikmeleri analiz etmeyi ve Dış tedarikçi faaliyet süresi Dashboardunu destekler.
Nereden alınır?
Hizmet Talebi kaydındaki durumun 'Waiting for 3rd Party' veya 'Pending Vendor' gibi bir duruma geçmesinden anlaşılır.
Kaydedin
'Status' alanının belirlenen 'tedarikçiden yanıt bekleniyor' durumuna geçişini tespit etme.
Olay türü
inferred
|
|||
|
Hizmet talebi iptal edildi
|
Hizmet talebi, çözülmeden önce kullanıcı veya temsilci tarafından iptal edilmiştir. 'Cancelled' veya 'Withdrawn' durumuna geçişle kaydedilen bu olay, sürecin alternatif bir bitiş durumudur. | ||
|
Neden önemli?
Bu, sürecin standart dışı biçimde sona erdiğini gösterir. Taleplerin neden iptal edildiğini analiz etmek, talep sürecindeki sorunları veya kullanıcı ihtiyaçlarındaki değişiklikleri ortaya çıkarabilir.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Cancelled' durumuna geçmesiyle anlaşılır.
Kaydedin
Denetim geçmişinden 'Status' alanının 'Cancelled' olarak güncellendiğini tespit etme.
Olay türü
inferred
|
|||
|
Hizmet talebi karşılandı
|
Hizmet talebini karşılamak için gereken tüm görevler temsilci veya sistem tarafından tamamlanmıştır. Bu durum, çoğu zaman son 'Resolved' durumundan önce gelen 'Fulfilled' durumuna geçişle kaydedilir. | ||
|
Neden önemli?
Bu dönüm noktası, teknik veya prosedürel işlerin tamamlandığını gösterir. Son onay ve kapatma öncesindeki aktif işlem süresini ölçmek için önemli bir noktadır.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Fulfilled' durumuna geçmesiyle anlaşılır.
Kaydedin
Kaydın geçmişinde tespit edilen, 'Status' alanının 'Fulfilled' durumuna geçişi.
Olay türü
inferred
|
|||
|
Hizmet talebi yeniden açıldı
|
Daha önce çözülmüş bir hizmet talebi, sorun devam ettiği veya sunulan çözüm yeterli bulunmadığı için yeniden etkinleştirilmiştir. Durum 'Resolved' değerinden 'Active' veya 'Assigned' gibi etkin bir duruma geçtiğinde bu bilgi kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, yeniden çalışmanın ve ilk seferde çözüm kalitesinin düşük olduğunun doğrudan göstergesidir. Yeniden açılma olaylarını analiz etmek, süreçteki zayıf noktaları belirlemeye ve Hizmet Talebi yeniden çalışma oranı KPI’ını iyileştirmeye yardımcı olur.
Nereden alınır?
Denetim geçmişinde 'Status' alanının 'Resolved' veya 'Closed' durumundan etkin bir duruma geçtiği görüldüğünde anlaşılır.
Kaydedin
Son durumdan ('Resolved', 'Closed') açık duruma ('Active', 'Assigned') geçiş.
Olay türü
inferred
|
|||
|
Kullanıcı bilgi verdi
|
Talep sahibi gerekli bilgileri sağlamıştır ve temsilci çalışmaya devam edebilir. Talep 'Waiting for Customer' durumundan etkin bir duruma geçtiğinde bu bilgi kaydedilir. | ||
|
Neden önemli?
Bu olay, bilgi talebi döngüsünü tamamlar. Bilginin istenmesiyle alınması arasında geçen süre, süreç gecikmelerinin ve yeniden çalışma döngülerinin önemli bir bölümünü oluşturur.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Waiting for Customer' durumundan 'Active' veya 'In Progress' gibi etkin bir duruma geçmesiyle anlaşılır.
Kaydedin
'Kullanıcıdan yanıt bekleniyor' durumundan etkin bir duruma geçişi tespit etme.
Olay türü
inferred
|
|||
|
Kullanıcıdan bilgi istendi
|
Atanan temsilcinin talebi karşılamaya devam edebilmesi için talep sahibinden daha fazla bilgi alması gerekir. Talep durumu 'Waiting for Customer' gibi bir duruma güncellendiğinde bu bilgi kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, başlangıçta eksik bilgi verilmesinden kaynaklanan gecikmeleri gösterir. Sıklığını ve süresini izlemek, Bilgi talebinin etkisi analizini yapmak ve süreç iyileştirme alanlarını belirlemek için önemlidir.
Nereden alınır?
Hizmet Talebi kaydındaki durumun 'Waiting for Customer' veya 'Pending' gibi bir duruma geçmesinden anlaşılır.
Kaydedin
'Status' alanının belirlenen 'kullanıcıdan yanıt bekleniyor' durumuna geçişini tespit etme.
Olay türü
inferred
|
|||
|
Öncelik değiştirildi
|
Hizmet talebinin önceliği, ilk oluşturulduktan sonra güncellenmiştir. Bu olay, alan düzeyindeki değişiklikleri izleyen denetim günlüğünden veya geçmişten alınır. | ||
|
Neden önemli?
Öncelik değişikliklerini izlemek, Önceliklendirme etkinliği genel görünümü için önemlidir. Eskalasyonların doğru yönetilip yönetilmediğini ve ilk önceliklendirmenin isabetli olup olmadığını belirlemeye yardımcı olur.
Nereden alınır?
Bu, Hizmet Talebi kaydının denetim geçmişinden alınan açık bir olaydır ve 'Priority' alanındaki değişiklikleri kaydeder.
Kaydedin
Sistemin denetim izine kaydedilen 'Priority' alanı güncelleme olayı.
Olay türü
explicit
|
|||
|
Talep onaya gönderildi
|
Hizmet talebi karşılanmadan önce gerekli onaylara sunulmuştur. Bu durum genellikle talep durumu 'Submitted' veya 'Pending Approval' olduğunda anlaşılır ve çoğu zaman bir onay iş akışını başlatır. | ||
|
Neden önemli?
Bu etkinliği izlemek, onay aşamasındaki gecikmeleri belirlemeye yardımcı olur. Buradaki uzun beklemeler önemli bir darboğaz oluşturarak toplam çözüm süresini ve kullanıcı memnuniyetini etkileyebilir.
Nereden alınır?
Hizmet Talebi kaydındaki durum değişikliğinden, genellikle 'Submitted' veya 'Waiting for Approval' durumuna geçişten anlaşılır. FRS_Approval veya FRS_ApprovalVoteTracking iş nesnelerinden de alınabilir.
Kaydedin
Hizmet Talebi kaydındaki 'Status' alanının onay bekleme durumuna geçmesi.
Olay türü
inferred
|
|||
|
Talep onaylandı
|
Hizmet talebi için gerekli tüm onaylar alınmıştır ve talep artık karşılanabilir. Onay iş akışı başarıyla tamamlanıp talebin durumu değiştiğinde bu olay kaydedilir. | ||
|
Neden önemli?
Bu etkinlik, onay aşamasının bittiğini ve talebin karşılanmaya başladığını gösteren önemli bir dönüm noktasıdır. Onay sürecinin verimliliğini ölçmenizi sağlar.
Nereden alınır?
'Waiting for Approval' durumundan 'Approved' veya 'Fulfilled' durumuna geçişten anlaşılır. FRS_Approval iş nesnesinde açık bir olay olarak da kaydedilmiş olabilir.
Kaydedin
Hizmet Talebi kaydındaki 'Status' alanının onay durumundan etkin bir duruma geçmesi.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu ayrıntılı Veri Templateiyle hizmet talebi yönetimi sürecinizin tüm potansiyelini keşfedin. Operasyonlarınızı iyileştirmeye bugün başlayın.
Hizmet talebi yönetiminizi bugün iyileştirmeye başlayın
Yavaş talep karşılamayı sona erdirin, kullanıcı memnuniyetsizliğini azaltın ve %70 otomasyon oranına ulaşın.
Kredi kartı gerekmez, kurulumu dakikalar içinde tamamlayın.