Hizmet Talebi Yönetimi Veri Şablonunuz
Hizmet Talebi Yönetimi Veri Şablonunuz
- Ayrıntılı analiz için önerilen öznitelikler
- Süreç keşfi için izlenecek temel etkinlikler
- Kaynak sisteminizden veri çıkarma yönlendirmesi
Hizmet Talebi Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
Hizmet talebi yaşam döngüsünün belirli bir noktasında gerçekleşen olayın veya görevin adı. | ||
|
Açıklama
Bu öznitelik, 'Request Submitted for Approval' veya 'Service Request Resolved' gibi hizmet talebi sürecindeki belirli bir adımı veya durum değişikliğini tanımlar. Faaliyetlerin sırasını ve sıklığını analiz etmek, süreç akışını anlamak, darboğazları belirlemek ve standart prosedürden sapmaları ortaya çıkarmak için temeldir.
Neden önemli?
Süreç haritasındaki adımları tanımlar ve yeniden işleme, darboğazlar ile sapmalar dahil olmak üzere süreç akışının görselleştirilmesini ve analiz edilmesini sağlar.
Nereden alınır?
Genellikle Ivanti Service Manager içindeki durum değişikliklerinden, günlük girdilerinden 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 talebi için benzersiz tanımlayıcı. | ||
|
Açıklama
Hizmet Talebi Kimliği, bir kullanıcı veya sistem tarafından gönderilen her bir hizmet talebini benzersiz şekilde tanımlar. İlk kayıttan nihai kapatmaya kadar sonraki tüm olayları birbirine bağlayan merkezi bir iz görevi görür. Böylece her hizmet talebinin uçtan uca yolculuğu analiz edilebilir.
Neden önemli?
Bu, ilgili tüm faaliyetleri tek bir süreç örneğinde birleştiren ve uçtan uca süreç analizini mümkün kılan temel vaka tanımlayıcısıdır.
Nereden alınır?
Bu, Service Request iş nesnesinin birincil anahtarıdır ve çoğu zaman ServiceReq tablosunda ServiceReqNumber olarak bulunur.
Örnekler
SR-0012345SR-0012346SR-0012347
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyet veya olayın gerçekleştiği zamanı gösteren zaman damgası. | ||
|
Açıklama
Başlangıç zamanı olarak da bilinen Olay Zamanı, bir faaliyetin sistemde kaydedildiği kesin tarih ve saattir. Bu zaman damgası, olayların doğru sıraya konulması için önemlidir ve çevrim süreleri, bekleme süreleri ve faaliyet süreleri gibi zamana dayalı tüm Process Mining analizlerinin temelini oluşturur.
Neden önemli?
Bu zaman damgası, olayları kronolojik olarak sıralamak ve performans analizi için önemli olan süreye dayalı tüm metrikleri hesaplamak açısından gereklidir.
Nereden alınır?
Denetim günlüklerinde, günlük girdilerinde (örneğin 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ı tanımlar. Bu görünümde değer sabit olur ve tüm verilerin Ivanti Service Manager'dan geldiğini gösterir. Verilerin birden fazla sistemden birleştirilebildiği ortamlarda veri kökeninin ve bağlamının net olmasını sağladığı için önemlidir.
Neden önemli?
Verilerin kökeni hakkında önemli bağlam sağlar. Özellikle birden fazla sistemin bulunduğu ortamlarda analizlerin doğru kaynak sisteme atfedilmesini sağlar.
Nereden alınır?
Bu, genellikle veri çıkarma sürecinde Veri Setinin kaynağını belirtmek için eklenen statik bir değerdir.
Örnekler
Ivanti Service Manager
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemdeki 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 kapsadığı dönemi ve bir sonraki güncellemenin ne zaman beklenebileceğini anlamanızı sağlayarak verilerin güncelliği hakkında bağlam sunar.
Neden önemli?
Verilerin güncelliği hakkında bilgi verir. Bu, mevcut en güncel süreç performansı bilgilerine dayanarak karar almak için önemlidir.
Nereden alınır?
Bu değer oluşturulur ve veri çıkarma sırasında veri setine zaman damgasıyla 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 grup. | ||
|
Açıklama
Bu öznitelik, belirli bir anda hizmet talebine işlem yapan sorumlu ekibi belirler. Ekipler arasındaki devir teslimleri, her ekiple geçirilen süreyi ve farklı ekiplerin ele aldığı talep hacmini analiz etmek; iş yükü dağılımını anlamak, darboğazları belirlemek ve ekip performansını değerlendirmek için önemlidir. SLA uyumu ve temsilci iş yüküyle ilgili Dashboardları doğrudan destekler.
Neden önemli?
Sorumlulukları ve devirleri izleyerek ekipler arası gecikmeleri, iş yükü dengesini ve süreçte darboğaz oluşturan ekipleri analiz etmenize yardımcı olur.
Nereden alınır?
Bu bilgi genellikle Service Request nesnesindeki 'OwnerTeam' benzeri bir alanda veya ilgili atama kayıtlarında saklanır.
Örnekler
BT Hizmet MasasıAğ OperasyonlarıİK DesteğiTesis Yönetimi
|
|||
|
Atanan Temsilci
AssignedAgent
|
Hizmet talebine atanan kullanıcı veya temsilci. | ||
|
Açıklama
Atanan Temsilci, hizmet talebi üzerinde çalışmaktan sorumlu kişidir. Bu öznitelik, bireysel düzeyde analiz yapmanızı sağlar ve performans yönetimi, iş yükü dengesi ile eğitim ihtiyaçlarını belirlemek için kullanışlıdır. Temsilciler arasındaki yeniden atamaları izlemek, 'Talep Başına Ortalama Yeniden Atama' gibi KPI'ları hesaplamak ve süreçteki verimsizlikleri anlamak için önemlidir.
Neden önemli?
Bireysel iş yükünü, performansı ve yeniden atama örüntülerini analiz etmenizi sağlar. Bu veriler eğitim, beceri setleri veya ilk yönlendirmeyle ilgili sorunlara işaret edebilir.
Nereden alınır?
Genellikle Service Request nesnesindeki 'Owner' benzeri bir alanda bulunur. Her yeniden atamada değişebilir ve Event Log içinde izlenmelidir.
Örnekler
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Çözüm Zaman Damgası
ResolutionDateTime
|
Hizmet talebinin resmi olarak çözüldüğü tarih ve saat. | ||
|
Açıklama
Bu vaka düzeyindeki öznitelik, talep resmi olarak kapatılmadan önce hizmetin sunulduğu veya sorunun giderildiği son zaman damgasını gösterir. Bu zaman damgası, hizmet talebinin uçtan uca çevrim süresini hesaplamak için temel bitiş noktasıdır. Genel süreç verimliliğini ve SLA uyumluluğunu ölçmek için önemli bir bileşendir.
Neden önemli?
Ana süreç çevrim süresinin hesaplanacağı bitiş noktasını tanımlar ve hizmet sunumu verimliliği için önemli bir performans göstergesidir.
Nereden alınır?
Service Request nesnesindeki belirli bir zaman damgası alanıdır ve genellikle 'ResolvedDateTime' veya benzer bir adla bulunur.
Ö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 genellikle süreç günlüğündeki etkinlikleri tanımlar. Her durumda geçirilen süreyi analiz etmek, örneğin taleplerin 'Beklemede' durumunda çok uzun kalması gibi darboğazları ortaya çıkarabilir.
Neden önemli?
Herhangi bir anda talebin durumunu gösteren bir anlık görünüm sunar. Bu bilgi, belirli durumlarda geçirilen süreyi hesaplamak ve süreçteki tıkanmaları belirlemek için gereklidir.
Nereden alınır?
Service Request nesnesindeki standart bir alandır ve genellikle 'Status' olarak adlandırılır.
Örnekler
KaydedildiAktifMüşteriden yanıt bekleniyorYerine getirildiKapatıldı
|
|||
|
Hizmet Talebi Türü
ServiceRequestType
|
Hizmet talebinin sınıflandırması veya kategorisi. | ||
|
Açıklama
Bu öznitelik, hizmet talebini örneğin 'Donanım Talebi', 'Yazılım Kurulumu' veya 'Parola Sıfırlama' olarak kategorilere ayırır. Ekiplerin farklı hizmet türlerinde süreç performansını, çevrim sürelerini ve SLA uyumluluğunu karşılaştırmasına imkan veren önemli bir analiz boyutudur. Bu farklılıkları anlamak, süreç iyileştirmelerini ihtiyaca göre şekillendirmenize ve kaynakları daha verimli dağıtmanıza yardımcı olur.
Neden önemli?
Süreci talep türüne göre segmentlere ayırmak, hedefli analiz yapmanızı sağlar. Böylece belirli talep türlerinin gecikmeye, yeniden çalışmaya veya SLA ihlallerine daha yatkın olup olmadığını görebilirsiniz.
Nereden alınır?
Muhtemelen Service Request iş nesnesindeki bir alandır ve genellikle 'Service' veya 'Category' olarak adlandırılır. 'SvcReqTmplLink_Category' gibi belirli alan adları için Ivanti Service Manager belgelerine 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üresini ifade eder. Bu bilgi, süreçte en fazla zaman alan adımları belirlemek, verimsizlikleri ve iyileştirme alanlarını ortaya çıkarmak için büyük önem taşır.
Neden önemli?
Her bir etkinliğin süresini hesaplamanızı sağlar. Bu, süreç darboğazlarını ve uzun süren görevleri belirlemek için gereklidir.
Nereden alınır?
Ayrı bir alan olarak bulunmayabilir. Çoğu zaman aynı vaka içindeki bir sonraki etkinliğin başlangıç zamanıdı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, bir hizmet talebinin aciliyetini gösterir ve genellikle 'Düşük', 'Orta', 'Yüksek' veya 'Kritik' gibi seviyelerden oluşur. Bu öznitelik, sürecin yüksek öncelikli talepleri gerçekten öne alıp almadığını değerlendirmek için temel bir göstergedir. Analizde genellikle farklı öncelik seviyelerindeki çevrim süreleri ve SLA uyumluluğu karşılaştırılarak önceliklendirme kurallarının beklendiği gibi çalışıp çalışmadığı kontrol edilir.
Neden önemli?
Önceliklendirme stratejisinin ne kadar etkili olduğunu değerlendirmek ve yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı çözüldüğünden emin olmak için önemlidir.
Nereden alınır?
Service Request nesnesindeki standart bir alandır ve genellikle 'Priority' olarak adlandırılır.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
SLA Durumu
SLAStatus
|
Hizmet talebinin SLA son tarihi içinde çözülüp çözülmediğini gösterir. | ||
|
Açıklama
Bu, her hizmet talebini çözüm süresinin SLA son tarihiyle karşılaştırılmasına göre "Met" veya "Breached" olarak işaretleyen türetilmiş bir özniteliktir. SLA Adherence Performance Dashboardunun ve Service Level Agreement Adherence Rate KPI’ının temelini oluşturur. Mantık, her vaka için ResolutionDateTime ile SLADeadline alanlarını karşılaştırır.
Neden önemli?
Performansı hizmet taahhütlerine göre doğrudan ölçer. Bu, hizmet kalitesini değerlendirmek ve kullanıcı 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ı', aksi halde 'İhlal Edildi' olur.
Örnekler
Karşılandıİhlal edildi
|
|||
|
SLA Son Tarihi
SLADeadline
|
Hizmet talebinin çözülmesinin beklendiği son zaman damgası. | ||
|
Açıklama
SLA Son Tarihi, bir hizmet talebinin Service Level Agreement koşullarını karşılamak için çözülmesi gereken hesaplanmış tarih ve saattir. Bu hedef genellikle talebin önceliği ve türü gibi faktörlere göre belirlenir. Gerçek çözüm zamanının bu son tarihle karşılaştırılması, SLA uyumluluğunun ölçülmesini sağlar.
Neden önemli?
Gerçek performansın ölçüldüğü referans noktasıdır. SLA uyumluluk oranlarını hesaplamayı ve risk altındaki talepleri belirlemeyi doğrudan destekler.
Nereden alınır?
Bu değer genellikle Ivanti içinde hesaplanan bir alandır ve 'ResolutionTargetDateTime' gibi Service Level Agreement veya Offering ile ilgili alanlarda saklanır.
Örnekler
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Atama Sayısı
AssignmentCount
|
Bir hizmet talebinin atandığı veya yeniden atandığı toplam sayı. | ||
|
Açıklama
Bu hesaplanan metrik, her hizmet talebi için atamayla ilgili etkinliklerin, örneğin 'Ekibe Atandı' ve 'Temsilciye Atandı' etkinliklerinin sayısını hesaplar. Genellikle 'ticket ping-pong' olarak adlandırılan yüksek yeniden atama sayısı, yönlendirmedeki verimsizliklere, ilk temas çözümünün yetersizliğine veya ekip sorumluluklarının net olmamasına işaret eder. Bu öznitelik, 'Talep Başına Ortalama Yeniden Atama' KPI'ı için gereklidir.
Neden önemli?
Verimsiz devirleri ve yönlendirme sorunlarını ölçer. Yüksek değerler, uzayan çözüm sürelerinin ve kullanıcı memnuniyetsizliğinin güçlü bir göstergesidir.
Nereden alınır?
Veri hazırlama sırasında her benzersiz ServiceRequestID için atamayla ilgili etkinliklerin gerçekleşme sayısı hesaplanarak elde edilir.
Örnekler
12345
|
|||
|
Çözüm Kategorisi
ResolutionCategory
|
Hizmet talebi için sunulan çözümün sınıflandırması. | ||
|
Açıklama
Çözüm Kategorisi, bir hizmet talebinin nasıl çözüldüğünü yapılandırılmış biçimde sınıflandırır. Bu sınıflandırma genellikle kök neden analizi ve eğilim raporlaması için kullanılan hiyerarşik bir yapıdadır, örneğin Kategori ve Alt Kategori. Tekrarlanan sorunları veya yaygın karşılama işlemlerini ortaya çıkararak hizmetleri iyileştirmenize ya da bilgi bankası makaleleri oluşturmanıza yardımcı olabilir.
Neden önemli?
Çözümlerin niteliği hakkında içgörü sağlar; yaygın sorunları, hizmet iyileştirme fırsatlarını ve otomasyona uygun adayları belirlemenize yardımcı olur.
Nereden alınır?
Genellikle çözüm sırasında doldurulan 'ResolutionCategory' gibi sınıflandırma alanlarında veya özel bir kapatma kodu alanında saklanır.
Ö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. Örneğin talep Self-Service Portal, e-posta veya telefon üzerinden gönderilmiş ya da başka bir sistem tarafından otomatik olarak oluşturulmuş olabilir. Talep hacimlerini ve çözüm sürelerini kanala göre analiz etmek, hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi veya kullanıcı eğitimi gerektiğini gösterebilir.
Neden önemli?
Kullanıcı davranışını ve kanal verimliliğini anlamanıza yardımcı olur. Bu bilgiler, hizmet sunumu stratejisi ve otomasyon fırsatlarıyla ilgili kararları destekler.
Nereden alınır?
Bu bilgi genellikle Service Request nesnesindeki 'Source' veya 'CreatedBy' türünde bir alanda saklanır.
Örnekler
Self servisE-postaTelefonDoğrudan giriş
|
|||
|
Talep Eden Departman
RequestorDepartment
|
Hizmet talebini gönderen kullanıcının bağlı olduğu iş departmanı. | ||
|
Açıklama
Bu öznitelik, 'Satış', 'Finans' veya 'İnsan Kaynakları' gibi hizmet talebini başlatan çalışanın ya da sistemin departmanını gösterir. Kurumun farklı bölümlerindeki hizmet kalitesini ve talep yoğunluğunu analiz etmenizi sağlar. Örneğin belirli departmanların daha uzun çözüm süreleri yaşayıp yaşamadığını veya daha fazla talep gönderip göndermediğini belirlemenize yardımcı olur.
Neden önemli?
Hizmet tüketimini ve kalitesini iş birimine göre analiz etmenizi sağlar. Böylece departmana özgü sorunları veya eğilimleri belirleyebilirsiniz.
Nereden alınır?
Bu bilgi genellikle talep sahibinin Service Request ile ilişkilendirilmiş kullanıcı profilinden alınır. Alan, Profile.Employee nesnesinde 'Department' olarak adlandırılabilir.
Örnekler
FinansSatışPazarlamaBilgi Teknolojileri
|
|||
|
Tedarikçi Adı
VendorName
|
Talebin çözümüne dahil olan harici tedarikçinin adı. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebine yardımcı olmak veya talebi tamamlamak üzere görevlendirilen üçüncü taraf tedarikçiyi belirler. Farklı tedarikçilerin performansını ölçmeyi ve karşılaştırmayı sağladığı için External Vendor Activity Duration Dashboardu açısından önemlidir. Bu bilgiyi izlemek, tedarikçi ilişkilerini yönetmeye ve dış bağımlılıkların neden olduğu darboğazları belirlemeye yardımcı olur.
Neden önemli?
Üçüncü taraf performansını ve bu performansın genel hizmet talebi çözüm sürelerine etkisini analiz etmenizi sağlar. Tedarikçi yönetimini destekler.
Nereden alınır?
Hizmet talebiyle ilişkilendirilmiş bir görev nesnesindeki alan olabilir. Tedarikçi atanmışsa Service Request nesnesinde de özel bir alan olarak bulunabilir.
Örnekler
Dell DesteğiOracle DanışmanlığıMicrosoft Premiernull
|
|||
|
Yeniden Açılma Sayısı
ReopenCount
|
Çözüldükten sonra yeniden açılan bir hizmet talebinin yeniden açılma sayısı. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebi 'Çözüldü' veya 'Kapatıldı' durumundan 'Aktif' durumuna her döndüğünde artan bir sayaçtır. Yüksek yeniden açılma sayısı, ilk seferde çözüm kalitesinin düşük olduğuna, çözümlerin eksik kaldığına veya sorunların tekrarlandığına işaret eder. 'Hizmet Talebi Yeniden Çalışma Oranı' KPI'ını doğrudan destekler.
Neden önemli?
Yeniden çalışmayı doğrudan ölçer ve çözüm kalitesinin önemli bir göstergesidir. Yüksek değerler, ilk çözümün etkili olmadığını gösterir.
Nereden alınır?
Genellikle Service Request nesnesindeki bir sayaç alanıdır. Durum uygun şekilde değiştiğinde bir iş kuralı tarafından artırılır ve 'ReopenCounter' olarak adlandırılabilir.
Örnekler
0123
|
|||
|
Yeniden Çalışma Var mı
IsRework
|
Hizmet talebinde yeniden çalışma etkinlikleri bulunup bulunmadığını gösteren boolean işareti. | ||
|
Açıklama
Bu hesaplanan işaret, bir hizmet talebinin çözümden sonra yeniden açılması veya belirli etkinliklerin bir döngü içinde tekrarlanması gibi yeniden çalışma belirtileri göstermesi durumunda true olarak ayarlanır. Service Request Rework Rate KPI’ının hesaplanmasını kolaylaştırır ve Rework and Reassignment Flows gibi Dashboardlarda verimsiz süreç örneklerinin filtrelenmesine yardımcı olur.
Neden önemli?
Ek ve planlanmamış çaba gerektiren taleplerin hacmini kolayca belirleyip ölçmenizi sağlar. Böylece 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 'Temsilciye Atandı' gibi belirli etkinlik dizilerinin birden fazla kez gerçekleştiğinin algılanmasına dayanabilir.
Örnekler
truefalse
|
|||
Hizmet Talebi Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet Talebi Çözüldü
|
Hizmet talebi çözülmüş kabul edilir ve çözüm kullanıcıya sunulmuştur. Bu, 'Resolved' durumuna geçişle kaydedilen temel bir kilometre taşıdır ve çoğu zaman SLA sayacını durdurur. | ||
|
Neden önemli?
Bu, çözüm süresini ve SLA uyumluluğunu ölçmek için önemli bir bitiş noktasıdır. Oluşturma ile bu faaliyet arasında 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 ilgili zaman damgasıyla birlikte 'Resolved' olarak değiştirilmesinden anlaşılır.
Yakalayın
Denetim geçmişinden 'Status' alanının 'Resolved' olarak güncellendiğinin tespit edilmesi.
Olay türü
inferred
|
|||
|
Hizmet Talebi Kapatıldı
|
Hizmet talebi resmi olarak kapatılmıştır ve başka işlem yapılamaz. Bu durum çoğu zaman talebin 'Resolved' durumunda belirli bir süre kalmasından sonra otomatik olarak gerçekleşir ve yaşam döngüsünün nihai sonucunu gösterir. | ||
|
Neden önemli?
Bu faaliyet sürecin kesin bitişidir. 'Resolved' ile 'Closed' arasında geçen süre, onay veya otomatik sistem işlemlerindeki gecikmeleri gösterebilir.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının ilgili zaman damgasıyla birlikte 'Closed' olarak değiştirilmesinden anlaşılır.
Yakalayın
Denetim geçmişinden 'Status' alanının 'Closed' olarak güncellendiğinin tespit edilmesi.
Olay türü
inferred
|
|||
|
Hizmet Talebi Oluşturuldu
|
Bu faaliyet, yeni bir talebin resmi olarak gönderilip Ivanti'ye kaydedilmesiyle hizmet talebi yaşam döngüsünün başlangıcını gösterir. 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 birincil 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. Örneğin ServiceReq iş nesnesindeki CreatedDateTime alanı.
Yakalayın
ServiceReq tablosundaki kayıt oluşturma olayı, oluşturulma zaman damgasıyla tanımlanır.
Olay türü
explicit
|
|||
|
Talep Ekibe Atandı
|
Hizmet talebi, işlenmesi için belirli bir destek ekibine atanır. Bu durum, Hizmet Talebi kaydındaki 'OwnerTeam' alanının doldurulması veya değiştirilmesi izlenerek kaydedilir. | ||
|
Neden önemli?
Bu olay, ekip düzeyindeki performansı, iş yükü dağılımını ve ekipler arası devir 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 denetim geçmişinde veya günlüğünde 'OwnerTeam' alanındaki değişiklikler izlenerek kaydedilir.
Yakalayın
Genellikle denetim izinde kaydedilen 'OwnerTeam' alanı güncelleme olayı.
Olay türü
explicit
|
|||
|
Talep Temsilciye Atandı
|
Belirli bir temsilci hizmet talebinin sorumluluğunu alır. Bu faaliyet, kişisel temsilciyi belirleyen 'Owner' alanının ilk kez doldurulması veya güncellenmesiyle anlaşılır. | ||
|
Neden önemli?
Bu etkinlik, ilk bekleme veya kuyruk süresinin sona erdiğini gösterir. Bu etkinlikten önce geçen süreyi ölçmek, kaynak dağılımı sorunlarını belirlemeye yardımcı olur ve Agent Workload Dashboardunu destekler.
Nereden alınır?
Hizmet Talebi kaydındaki 'Owner' alanının doldurulması veya değiştirilmesinden, denetim geçmişinde görüldüğü şekilde anlaşılır.
Yakalayın
Oluşturma veya ekip atamasından sonra 'Owner' alanının bir temsilci adıyla ilk kez doldurulduğu zaman damgası.
Olay türü
inferred
|
|||
|
Bilgi Kullanıcı Tarafından Sağlandı
|
Talep sahibi gerekli bilgileri sağlamıştır ve temsilcinin çalışmaya devam etmesine imkan verir. Talep 'Waiting for Customer' durumundan etkin bir duruma geçtiğinde bu olay kaydedilir. | ||
|
Neden önemli?
Bu olay, bilgi taleplerinin döngüsünü tamamlar. Bilginin istenmesiyle alınması arasında geçen süre, süreç gecikmelerinin ve yeniden işleme 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 değişmesiyle anlaşılır.
Yakalayın
'waiting on user' durumundan etkin bir duruma geçişin tespit edilmesi.
Olay türü
inferred
|
|||
|
Harici Tedarikçi Sürece Dahil Oldu
|
Hizmet talebinin karşılanması harici bir 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 bunun genel çevrim süresine etkisini ölçmek için önemlidir. Tedarikçi kaynaklı gecikmelerin analiz edilmesini sağlar ve External Vendor Activity Duration Dashboardunu destekler.
Nereden alınır?
Hizmet Talebi kaydındaki durumun 'Waiting for 3rd Party' veya 'Pending Vendor' gibi bir duruma değiştirilmesinden anlaşılır.
Yakalayın
'Status' alanının belirlenmiş bir 'waiting on vendor' durumuna değiştirilmesiyle tespit edilir.
Olay türü
inferred
|
|||
|
Hizmet Talebi İptal Edildi
|
Hizmet talebi, çözümden önce kullanıcı veya temsilci tarafından iptal edilmiştir. Bu, 'Cancelled' veya 'Withdrawn' durumuna geçişle kaydedilen alternatif bir bitiş durumudur. | ||
|
Neden önemli?
Bu durum, standart dışı bir süreç sonlandırmasını gösterir. Taleplerin neden iptal edildiğini analiz etmek, talep sürecindeki sorunları veya değişen kullanıcı ihtiyaçlarını ortaya çıkarabilir.
Nereden alınır?
Hizmet Talebi kaydındaki 'Status' alanının 'Cancelled' olarak değiştirilmesinden anlaşılır.
Yakalayın
Denetim geçmişinden 'Status' alanının 'Cancelled' olarak güncellendiğinin tespit edilmesi.
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 kilometre taşı, teknik veya prosedürel çalışmanın 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' olarak değiştirilmesinden anlaşılır.
Yakalayın
Kayıt geçmişinden tespit edilen, 'Status' alanının 'Fulfilled' olarak değiştirilmesi.
Olay türü
inferred
|
|||
|
Hizmet Talebi Yeniden Açıldı
|
Daha önce çözülmüş bir hizmet talebi, sorun devam ettiği veya çözüm yetersiz kaldığı için yeniden etkinleştirilmiştir. Durum 'Resolved' durumundan 'Active' veya 'Assigned' gibi etkin bir duruma geçtiğinde bu olay kaydedilir. | ||
|
Neden önemli?
Bu faaliyet, yeniden işlemenin ve ilk seferde çözüm kalitesinin düşük olduğunun doğrudan göstergesidir. Yeniden açma olaylarını analiz etmek, süreç zayıflıklarını belirlemeye ve Hizmet Talebi Yeniden İşleme 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 değişmesiyle anlaşılır.
Yakalayın
Terminal bir durumdan ('Resolved', 'Closed') açık bir duruma ('Active', 'Assigned') geçiş.
Olay türü
inferred
|
|||
|
Kullanıcıdan Bilgi İstendi
|
Atanan temsilcinin talebi karşılamaya devam edebilmesi için talep sahibinden daha fazla bilgiye ihtiyacı vardır. Bu durum, talep durumu 'Waiting for Customer' gibi bir duruma güncellendiğinde kaydedilir. | ||
|
Neden önemli?
Bu faaliyet, başlangıç bilgilerinin eksik olmasından kaynaklanan gecikmeleri gösterir. Sıklığını ve süresini izlemek, Bilgi Talebi Etki Analizi için ve süreç iyileştirme alanlarını belirlemek açısından önemlidir.
Nereden alınır?
Hizmet Talebi kaydındaki durumun 'Waiting for Customer' veya 'Pending' gibi bir duruma değiştirilmesinden anlaşılır.
Yakalayın
'Status' alanının belirlenmiş bir 'waiting on user' durumuna değiştirilmesiyle tespit edilir.
Olay türü
inferred
|
|||
|
Öncelik Değiştirildi
|
Hizmet talebinin önceliği, ilk oluşturulmasından 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 doğru 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. Geçmiş, 'Priority' alanındaki değişiklikleri kaydeder.
Yakalayın
Sistemin denetim izinde kaydedilen 'Priority' alanı güncelleme olayı.
Olay türü
explicit
|
|||
|
Talep Onaya Gönderildi
|
Hizmet talebi, karşılanabilmesi için gerekli onaylara gönderilmiştir. Bu durum genellikle talep durumu "Submitted" veya "Pending Approval" olarak değiştiğinde ve çoğu zaman bir onay iş akışı başlatıldığında anlaşılır. | ||
|
Neden önemli?
Bu faaliyeti izlemek, onay aşamasındaki gecikmeleri belirlemeye yardımcı olur. Buradaki uzun beklemeler önemli bir darboğaz oluşturarak toplam çözüm sürelerini ve kullanıcı memnuniyetini etkileyebilir.
Nereden alınır?
Hizmet Talebi kaydındaki durum değişikliğinden, büyük olasılıkla 'Submitted' veya 'Waiting for Approval' gibi bir duruma geçişten anlaşılır. Bu bilgi FRS_Approval veya FRS_ApprovalVoteTracking iş nesnelerinden de alınabilir.
Yakalayın
Hizmet Talebi kaydındaki 'Status' alanının onay bekleyen bir duruma değiştirilmesi.
Olay türü
inferred
|
|||
|
Talep Onaylandı
|
Hizmet talebi gerekli tüm onayları almıştır ve artık karşılanma aşamasına geçebilir. Bu olay, onay iş akışı başarıyla tamamlandığında ve talebin durumu değiştiğinde kaydedilir. | ||
|
Neden önemli?
Bu faaliyet önemli bir kilometre taşını gösterir. Onay aşamasının sona erdiğini ve karşılama aşamasının başladığını belirtir. Ayrıca onay sürecinin verimliliğinin ölçülmesini sağlar.
Nereden alınır?
'Waiting for Approval' durumundan 'Approved' veya 'Fulfilled' durumuna geçişten anlaşılır. Bu, FRS_Approval iş nesnesinde açıkça kaydedilmiş bir olay olarak da bulunabilir.
Yakalayın
Hizmet Talebi kaydındaki 'Status' alanının bir onay durumundan etkin bir duruma değiştirilmesi.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu ayrıntılı veri şablonuyla hizmet talebi yönetimi sürecinizin tüm potansiyelinden yararlanın. Operasyonlarınızı bugün iyileştirmeye başlayın.
Hizmet talebi yönetiminizi bugün optimize etmeye başlayın
Yavaş talep karşılamaya son verin, kullanıcı memnuniyetsizliğini azaltın ve %70 otomasyon oranına ulaşın.
Kredi kartı gerekmez, kurulumu dakikalar içinde tamamlayın.