Servis Talep Yönetimi Veri Şablonunuz
Servis Talep Yönetimi Veri Şablonunuz
- Kapsamlı analiz için önerilen özellikler
- Süreç keşfi için izlenecek temel faaliyetler
- Kaynak sisteminizden veri çekme konusunda rehberlik
Servis Talep Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Faaliyet Adı
ActivityName
|
Servis 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, servis talebi süreci içindeki belirli bir adımı veya durum değişikliğini, örneğin 'Onay İçin Gönderilen Talep' veya 'Çözülen Servis Talebi' gibi tanımlar. Aktivitelerin 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 temeldir.
Neden önemli
Süreç haritasındaki adımları tanımlar, yeniden işleme, darboğazları ve sapmaları belirleme dahil olmak üzere süreç akışının görselleştirilmesine ve analizine olanak tanır.
Nereden alınır
Genellikle Ivanti Service Manager içindeki durum değişiklikleri, günlük girişleri veya denetim logu olay açıklamalarından türetilir.
Örnekler
Servis Talebi OluşturulduTalep OnaylandıHizmet Talebi ÇözüldüHizmet Talebi Kapatıldı
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
|
Açıklama
Neden önemli
Bu zaman damgası, olayları kronolojik olarak sıralamak ve performans analizi için anahtar olan tüm süreye dayalı metrikleri hesaplamak için esastır.
Nereden alınır
Denetim kayıtlarında, günlük girişlerinde (örn. Journal.CreatedDateTime) veya Hizmet Talebi ile 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
|
|||
|
Servis Talebi Kimliği
ServiceRequestID
|
Her servis talebi için benzersiz tanımlayıcı. | ||
|
Açıklama
Servis Talep ID'si, bir kullanıcı veya sistem tarafından gönderilen her bir servis talebini benzersiz şekilde tanımlar. İlk kayıttan nihai kapanışa kadar tüm sonraki olayları birbirine bağlayan merkezi bir işlev görür ve her servis talebinin yolculuğunun eksiksiz, uçtan uca analizine olanak tanır.
Neden önemli
Bu, tüm ilgili aktiviteleri tek bir süreç örneğine bağlayan temel vaka tanımlayıcısıdır ve uçtan uca süreç analizine olanak tanır.
Nereden alınır
Bu, Servis Talep iş nesnesinin birincil anahtarıdır ve genellikle ServiceReq tablosunda ServiceReqNumber olarak bulunur.
Örnekler
SR-0012345SR-0012346SR-0012347
|
|||
|
Kaynak Sistem
SourceSystem
|
Verilerin çekildiği sistem. | ||
|
Açıklama
Bu öznitelik, süreç verilerinin kaynağını tanımlar. Bu görünüm için değer sabit olacak ve tüm verilerin Ivanti Service Manager'dan geldiğini gösterecektir. Bu, verilerin birden fazla sistemden birleştirilebileceği ortamlarda önemlidir ve net veri soy ağacı ve bağlam sağlar.
Neden önemli
Veri kökeni hakkında kritik bağlam sağlar, analizlerin özellikle çok sistemli ortamlarda belirli kaynak sisteme doğru şekilde atfedilmesini garanti eder.
Nereden alınır
Bu, genellikle veri çıkarma süreci sırasında veri setinin kaynağını etiketlemek için eklenen sabit (statik) bir değerdir.
Örnekler
Ivanti Service Manager
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenilemesinin zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin Ivanti Service Manager'dan en son ne zaman çıkarıldığını gösteren tarih ve saati belirtir. Analiz edilen verinin güncelliği hakkında bağlam sağlayarak, kullanıcıların analizin kapsadığı zaman diliminden ve bir sonraki güncellemenin ne zaman bekleneceğinden haberdar olmalarını sağlar.
Neden önemli
Kullanıcıları verilerin güncelliği hakkında bilgilendirir; bu da mevcut en güncel süreç performansı bilgilerine dayanarak karar vermek için kritik öneme sahiptir.
Nereden alınır
Bu değer,
Örnekler
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Atanan Ekip
AssignedTeam
|
Servis talebini şu anda işlemek üzere atanan destek ekibi veya grubu. | ||
|
Açıklama
Bu öznitelik, belirli bir zamanda servis talebini işlemekten sorumlu ekibi tanımlar. Ekipler arasındaki devirleri, her bir ekiple geçirilen süreyi ve farklı ekipler tarafından işlenen talep hacmini analiz etmek, iş yükü dağılımını anlamak, darboğazları belirlemek ve ekip performansını değerlendirmek için kritik öneme sahiptir. SLA uyumu ve temsilci iş yükü ile ilgili dashboard'ları doğrudan destekler.
Neden önemli
Sorumluluğu ve devirleri takip ederek, ekipler arası gecikmeleri, iş yükü dengesini ve süreçte hangi ekiplerin darboğaz olduğunu analiz etmeye yardımcı olur.
Nereden alınır
Bu bilgi genellikle Servis Talep nesnesindeki 'Sahip Ekibi' gibi bir alanda veya ilgili atama kayıtlarında saklanır.
Örnekler
BT Servis MasasıAğ OperasyonlarıİK DesteğiTesis Yönetimi
|
|||
|
Atanan Temsilci
AssignedAgent
|
Servis talebine atanan bireysel kullanıcı veya temsilci. | ||
|
Açıklama
Atanan Temsilci, servis talebi üzerinde çalışmaktan sorumlu belirli kişidir. Bu öznitelik, performans yönetimi, iş yükü dengeleme ve eğitim fırsatlarını belirleme açısından faydalı olan bireysel düzeyde analiz yapılmasını sağlar. Temsilciler arasındaki yeniden atamaları takip etmek, 'Talep Başına Ortalama Yeniden Atama' gibi KPI'ları hesaplamak ve süreç verimsizliklerini anlamak için anahtardır.
Neden önemli
Bireysel iş yükü, performans ve yeniden atama modellerinin analizini sağlar; bu da eğitim, beceri setleri veya ilk yönlendirme ile ilgili sorunları gösterebilir.
Nereden alınır
Genellikle Servis Talep nesnesindeki 'Sahip' gibi bir alanda bulunur. Bu, her yeniden atama ile değişebilir ve event logunda takip edilmelidir.
Örnekler
Alice JohnsonBob Williams`Charlie Brown`Diana Prince
|
|||
|
Çözüm Zaman Damgası
ResolutionDateTime
|
Servis talebinin resmi olarak çözüldüğü tarih ve saat. | ||
|
Açıklama
Bu, hizmetin teslim edildiği veya sorunun giderildiği, talebin resmi olarak kapatılmasından önceki son zaman damgasını işaretleyen vaka düzeyinde bir özniteliktir. Bu zaman damgası, bir servis talebinin uçtan uca döngü süresini hesaplamak için birincil bitiş noktasıdır. Genel süreç verimliliğini ve SLA uyumunu ölçmek için kritik bir bileşendir.
Neden önemli
Hizmet sunumu verimliliği için temel performans göstergesi olan ana süreç döngü süresi hesaplamasının bitiş noktasını tanımlar.
Nereden alınır
Hizmet Talep nesnesi üzerinde, genellikle 'ÇözümlenmeTarihiSaati' veya benzeri adlandırılan belirli bir zaman damgası alanı.
Örnekler
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Döngü Süresi
CycleTime
|
Servis talebinin oluşturulmasından nihai çözümüne kadar geçen toplam süre. | ||
|
Açıklama
Neden önemli
Bu, uçtan uca süreç verimliliğini ölçmek için birincil bir KPI'dır ve kullanıcı açısından hizmet deneyimini doğrudan yansıtır.
Nereden alınır
Her hizmet talebi için oluşturma zaman damgasının çözüm zaman damgasından çıkarılmasıyla hesaplanır.
Örnekler
25920000060480000086400000
|
|||
|
Hizmet Talebi Türü
ServiceRequestType
|
Servis talebinin sınıflandırması veya kategorisi. | ||
|
Açıklama
Bu öznitelik, servis talebini örneğin 'Donanım Talebi', 'Yazılım Kurulumu' veya 'Şifre Sıfırlama' gibi kategorize eder. Analiz için kritik bir boyuttur ve ekiplerin farklı hizmet türleri arasında süreç performansını, döngü sürelerini ve SLA uyumunu karşılaştırmasına olanak tanır. Bu farklılıkları anlamak, süreç iyileştirmelerini uyarlamaya ve kaynakları daha etkili bir şekilde tahsis etmeye yardımcı olur.
Neden önemli
Süreci talep türüne göre bölümlendirmek, hedeflenmiş analiz imkanı sunar ve belirli talep türlerinin gecikmelere, yeniden çalışmaya veya SLA ihlallerine daha yatkın olup olmadığını ortaya koyar.
Nereden alınır
Muhtemelen Hizmet Talep iş nesnesi üzerinde 'Hizmet' veya 'Kategori' olarak adlandırılan bir alan. 'SvcReqTmplLink_Category' gibi belirli alan adları için Ivanti Service Manager dokümantasyonuna başvurun.
Örnekler
Yeni Donanım TalebiYazılım ErişimiHesap DeğişikliğiBilgi Sorgulama
|
|||
|
Olay Bitiş Zamanı
EventEndTime
|
Bir aktivitenin tamamlandığını gösteren timestamp. | ||
|
Açıklama
Event End Time, bir aktivitenin tamamlandığını işaretler. Event Time (başlangıç) ile Event End Time arasındaki süre, o belirli aktivitenin işlem süresini temsil eder. Bu, süreçteki hangi adımların en çok zaman tükettiğini belirlemek, verimsizlikleri ve iyileştirme alanlarını tespit etmek için kritik öneme sahiptir.
Neden önemli
Bireysel etkinlik sürelerinin hesaplanmasını sağlar, bu da süreç darboğazlarını ve uzun süren görevleri belirlemek için hayati öneme sahiptir.
Nereden alınır
Ayrı bir alan olarak bulunmayabilir. Genellikle, aynı vaka için ardışık etkinliğin başlangıç zamanıdır.
Örnekler
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Öncelik
Priority
|
Servis talebine atanan öncelik seviyesi. | ||
|
Açıklama
Öncelik, bir hizmet talebinin aciliyetini belirtir, genellikle 'Düşük', 'Orta', 'Yüksek', 'Kritik' gibi bir ölçekte. Bu nitelik, sürecin yüksek öncelikli talepleri etkin bir şekilde hızlandırıp hızlandırmadığını değerlendirmek için temeldir. Analiz genellikle, önceliklendirme kurallarının amaçlandığı gibi çalıştığından emin olmak için farklı öncelik seviyeleri arasındaki döngü sürelerini ve SLA uyumluluğunu karşılaştırmayı içerir.
Neden önemli
Önceliklendirme stratejisinin etkinliğini değerlendirmek ve yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı çözülmesini sağlamak için kritik öneme sahiptir.
Nereden alınır
Hizmet Talep nesnesi üzerinde, genellikle 'Öncelik' olarak adlandırılan standart bir alan.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
Servis Talep Durumu
ServiceRequestStatus
|
Olay anındaki servis talebinin durumu. | ||
|
Açıklama
Bu öznitelik, servis talebinin 'Kaydedildi', 'Devam Ediyor', 'Beklemede', 'Çözüldü' veya 'Kapalı' gibi durumunu yakalar. Durum değişiklikleri genellikle süreç logundaki aktiviteleri tanımlar. Her bir durumda geçirilen süreyi analiz etmek, darboğazları ortaya çıkarabilir; örneğin, talepler 'Beklemede' durumunda çok uzun süre kalırsa.
Neden önemli
Talebin herhangi bir zamandaki durumunun anlık görüntüsünü sağlar, bu da belirli durumlarda geçirilen süreyi hesaplamak ve süreç duraklamalarını belirlemek için esastır.
Nereden alınır
Hizmet Talep nesnesi üzerinde, yaygın olarak 'Durum' olarak adlandırılan standart bir alan.
Örnekler
KaydedildiAktifMüşteri BekleniyorTamamlandıKapalı
|
|||
|
SLA Son Teslim Tarihi
SLADeadline
|
Servis talebinin çözülmesi beklenen zaman damgası. | ||
|
Açıklama
SLA Süresi, bir servis talebinin Hizmet Seviyesi Anlaşması'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 süresini bu süreyle karşılaştırmak, SLA uyumunu ölçmenin temelidir.
Neden önemli
Gerçek performansın ölçüldüğü bir kıyaslama noktasıdır, SLA uyum oranlarının hesaplanmasını ve risk altındaki taleplerin belirlenmesini doğrudan destekler.
Nereden alınır
Bu genellikle Ivanti içinde hesaplanmış bir alan olup, Hizmet Seviyesi Anlaşması veya Teklif ile ilgili alanlarda, örneğin 'ResolutionTargetDateTime' olarak saklanır.
Örnekler
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
SLA Statüsü
SLAStatus
|
Hizmet talebinin SLA son teslim tarihi içinde çözülüp çözülmediğini belirtir. | ||
|
Açıklama
Bu, servis talebinin SLA süresine göre çözüm zamanına bağlı olarak her bir servis talebini 'Karşılandı' veya 'İhlal Edildi' olarak işaretleyen türetilmiş bir özniteliktir. 'SLA Uygunluk Performansı' dashboard'unun ve 'Hizmet Seviyesi Anlaşması Uygunluk Oranı' KPI'ının temelini oluşturur. Mantık, her vaka için ResolutionDateTime ile SLADeadline'ı karşılaştırır.
Neden önemli
Hizmet taahhütlerine karşı performansı doğrudan ölçer, bu da hizmet kalitesini değerlendirmek ve kullanıcı güvenini sürdürmek için kritik öneme sahiptir.
Nereden alınır
'ÇözümlenmeTarihiSaati'nin 'SLASonTeslimTarihi' ile karşılaştırılmasıyla hesaplanır. Eğer ÇözümlenmeTarihiSaati <= SLASonTeslimTarihi ise durum 'Karşılandı'; aksi takdirde 'İhlal Edildi'dir.
Örnekler
Karşılandıİhlal Edildi
|
|||
|
Atama Sayısı
AssignmentCount
|
Bir servis talebinin kaç kez atandığı veya yeniden atandığı toplam sayısı. | ||
|
Açıklama
Bu hesaplanmış metrik, her servis talebi için atama ile ilgili aktivitelerin (örneğin, 'Ekibe Atandı', 'Temsilciye Atandı') sayısını sayar. Genellikle 'bilet pinponu' olarak adlandırılan yüksek yeniden atama sayısı, yönlendirmedeki verimsizlikleri, ilk temasta çözüm eksikliğini veya net olmayan ekip sorumluluklarını gösterir. Bu öznitelik, 'Talep Başına Ortalama Yeniden Atama' KPI'ı için esastır.
Neden önemli
Verimsiz devir ve yönlendirme sorunlarını nicelendirir. Yüksek bir sayı, uzayan çözüm sürelerinin ve kullanıcı memnuniyetsizliğinin güçlü bir göstergesidir.
Nereden alınır
Veri hazırlığı sırasında her benzersiz HizmetTalepID'si için atama ile ilgili faaliyetlerin tekrarlanma sayısını sayarak hesaplanır.
Örnekler
12345
|
|||
|
Çözüm Kategorisi
ResolutionCategory
|
Hizmet talebi için sağlanan çözümün bir sınıflandırması. | ||
|
Açıklama
Çözüm Kategorisi, bir servis talebinin nihayetinde nasıl çözüldüğünü sınıflandırmak için yapılandırılmış bir yol sunar. Bu genellikle (örneğin, Kategori, Alt Kategori gibi) kök neden analizi ve trend raporlamasına yardımcı olan hiyerarşik bir sınıflandırmadır. Örneğin, tekrar eden sorunları veya yaygın karşılama eylem türlerini vurgulayabilir; bu da hizmetleri iyileştirmek veya bilgi tabanı makaleleri oluşturmak için kullanılabilir.
Neden önemli
Çözümlerin niteliğine dair içgörüler sağlar, yaygın sorunları, hizmet iyileştirme fırsatlarını ve otomasyon adaylarını belirlemeye yardımcı olur.
Nereden alınır
Genellikle çözüm sırasında doldurulan kategorizasyon alanlarında saklanır, örneğin 'ÇözümKategorisi' veya özel bir kapanış kodu alanı.
Örnekler
Kullanıcı Eğitimi GerekliYazılım DağıtıldıDonanım OnarıldıErişim Verildi
|
|||
|
Kanal
Channel
|
Servis talebinin gönderildiği yöntem veya kanal. | ||
|
Açıklama
Kanal, servis talebinin nasıl oluşturulduğunu gösterir; örneğin, Self-Service Portal, E-posta, Telefon aracılığıyla veya otomatik olarak başka bir sistem tarafından. Kanal bazında talep hacimlerini ve çözüm sürelerini analiz etmek, hangi kanalların en verimli olduğuna ve hangilerinin süreç iyileştirmeleri veya kullanıcı eğitimi gerektirebileceğine dair içgörüler sağlayabilir.
Neden önemli
Kullanıcı davranışlarını ve kanal verimliliğini anlamaya yardımcı olur, bu da hizmet sunumu stratejisi ve otomasyon fırsatları hakkında kararlar alınmasına rehberlik edebilir.
Nereden alınır
Bu genellikle Servis Talep nesnesindeki 'Kaynak' veya 'Oluşturan' türünde bir alanda saklanır.
Örnekler
`Self-Service`E-postaTelefonDoğrudan Giriş
|
|||
|
Talep Sahibi Departmanı
RequestorDepartment
|
Servis talebini gönderen kullanıcının iş departmanı. | ||
|
Açıklama
Bu öznitelik, servis talebini başlatan çalışanın veya sistemin departmanını, örneğin 'Satış', 'Finans' veya 'İnsan Kaynakları' gibi tanımlar. Organizasyonun farklı bölümleri arasında hizmet kalitesi ve talep analizine olanak tanır. Örneğin, belirli departmanların daha uzun çözüm süreleri yaşadığını veya daha yüksek hacimde talep gönderdiğini belirlemeye yardımcı olabilir.
Neden önemli
Hizmet tüketiminin ve kalitesinin iş birimine göre analiz edilmesini sağlayarak departmana özgü sorunların veya eğilimlerin belirlenmesine yardımcı olur.
Nereden alınır
Bu bilgi genellikle talep sahibinin kullanıcı profilinden, Servis Talebi ile ilişkilendirilmiş olarak alınır. Alan, Profile.Employee nesnesinde 'Departman' olabilir.
Örnekler
FinansSatışPazarlamaBilgi Teknolojileri
|
|||
|
Tedarikçi Adı
VendorName
|
Talebin çözülmesinde yer alan harici tedarikçinin adı. | ||
|
Açıklama
Bu öznitelik, bir servis talebine yardımcı olmak veya tamamlamak için görevlendirilen üçüncü taraf tedarikçiyi tanımlar. 'Harici Tedarikçi Aktivite Süresi' dashboard'u için esastır, çünkü farklı tedarikçilerin performansını ölçmeye ve karşılaştırmaya olanak tanır. Bunu takip etmek, 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ın ve genel hizmet talebi çözüm süreleri üzerindeki etkilerinin analizini sağlar, tedarikçi yönetimini destekler.
Nereden alınır
Bu, servis talebiyle ilişkili bir görev nesnesindeki bir alan veya bir tedarikçi atandığında Servis Talebinin kendisindeki belirli bir alan olabilir.
Örnekler
Dell DesteğiOracle ConsultingMicrosoft Premiernull
|
|||
|
Yeniden Açılma Sayısı
ReopenCount
|
Çözülmüş bir servis talebinin kaç kez yeniden açıldığı sayısı. | ||
|
Açıklama
Bu öznitelik, bir servis talebinin 'Çözüldü' veya 'Kapalı' durumundan 'Aktif' duruma geri taşındığı her seferde artan bir sayaçtır. Yüksek yeniden açılma sayısı, zayıf ilk seferde çözüm kalitesinin, eksik çözümlerin veya tekrar eden sorunların güçlü bir göstergesidir. 'Servis Talep Yeniden Çalışma Oranı' KPI'ını doğrudan destekler.
Neden önemli
Yeniden işleme miktarını doğrudan ölçer ve çözüm kalitesinin önemli bir göstergesidir. Yüksek sayılar, ilk düzeltmenin etkili olmadığını gösterir.
Nereden alınır
Bu, genellikle Servis Talep nesnesinde, durum uygun şekilde değiştiğinde bir iş kuralı tarafından artırılan bir sayaç alanıdır. 'Yeniden AçılmaSayacı' olarak adlandırılabilir.
Örnekler
0123
|
|||
|
Yeniden İşleme mi?
IsRework
|
Hizmet talebinin yeniden işleme faaliyetleri içerip içermediğini gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu hesaplanmış bayrak, bir servis talebinin çözüldükten sonra yeniden açılması veya belirli aktivitelerin bir döngüde tekrarlanması gibi yeniden çalışma belirtileri gösteriyorsa doğru (true) olarak ayarlanır. 'Servis Talep Yeniden Çalışma Oranı' KPI'ının hesaplanmasını basitleştirir ve 'Yeniden Çalışma ve Yeniden Atama Akışları' gibi dashboard'larda verimsiz süreç örneklerini filtrelemeye yardımcı olur.
Neden önemli
Ek, plansız çaba gerektiren taleplerin hacmini kolayca belirlemeye ve ölçmeye yardımcı olarak kalite ve verimlilik sorunlarını vurgular.
Nereden alınır
Verilerden türetilmiştir. Mantık, 'YenidenAçılmaSayısı' niteliğinin sıfırdan büyük olmasına veya birden çok 'Temsilciye Atandı' olayları gibi belirli etkinlik dizilerinin tespit edilmesine dayanabilir.
Örnekler
truefalse
|
|||
Servis Talep Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet Talebi Çözüldü
|
Servis talebi çözülmüş kabul edilir ve çözüm kullanıcıya teslim edilmiştir. Bu, 'Çözüldü' durumuna geçişle kaydedilen birincil bir dönüm noktasıdır ve genellikle bir SLA sayacının durmasını tetikler. | ||
|
Neden önemli
Bu, çözüm süresini ve SLA uyumunu ölçmek için kritik bir bitiş noktasıdır. Oluşturulmadan bu aktiviteye kadar geçen süre, süreç performansı için temel bir KPI'dır.
Nereden alınır
Hizmet Talep kaydındaki 'Durum' alanının 'Çözüldü' olarak değişmesinden ve ilişkili zaman damgasından çıkarılır.
Yakala
Denetim geçmişinden 'Durum' alanının 'Çözüldü' olarak güncellenmesinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Hizmet Talebi Kapatıldı
|
Servis talebi resmi olarak kapatılmıştır ve başka hiçbir işlem yapılamaz. Bu genellikle 'Çözüldü' durumunda belirli bir süre geçtikten sonra otomatik olarak gerçekleşir ve yaşam döngüsünün nihai sonucunu temsil eder. | ||
|
Neden önemli
Bu aktivite, sürecin kesin sonudur. 'Çözüldü' ve 'Kapalı' arasındaki süre, onay veya otomatik sistem süreçlerindeki gecikmeleri vurgulayabilir.
Nereden alınır
Hizmet Talep kaydındaki 'Durum' alanının 'Kapalı' olarak değişmesinden ve ilişkili zaman damgasından çıkarılır.
Yakala
Denetim geçmişinden 'Durum' alanının 'Kapalı' olarak güncellenmesinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Servis Talebi Oluşturuldu
|
Bu aktivite, yeni bir talebin resmi olarak gönderildiği ve Ivanti'ye kaydedildiği servis talebi yaşam döngüsünün başlangıcını işaret eder. Bu olay, Servis Talebi iş nesnesinde yeni bir kayıt oluşturulduğunda ve benzersiz bir Servis Talep ID'si üretildiğinde yakalanır. | ||
|
Neden önemli
Bu, süreç için birincil başlangıç olayıdır. Bu noktadan çözüme kadar geçen süreyi analiz etmek, genel döngü süresini ve süreç verimliliğini ölçmek için temeldir.
Nereden alınır
Bu, Servis Talebi kaydının oluşturulma zaman damgasından (örneğin, ServiceReq iş nesnesindeki CreatedDateTime alanı) yakalanır.
Yakala
ServiceReq tablosundaki kayıt oluşturma olayı, oluşturulma zaman damgasıyla tanımlanır.
Event tipi
explicit
|
|||
|
Talep Ekibe Atandı
|
Servis talebi, işlenmek üzere belirli bir destek ekibine atanır. Bu, Servis Talebi kaydındaki 'Sahip Ekibi' alanının doldurulması veya değişmesi gözlemlenerek 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 kritik öneme sahiptir. Süreçte hangi ekiplerin darboğaz olduğunu belirlemeye yardımcı olur.
Nereden alınır
Servis Talebinin denetim geçmişindeki veya günlüğündeki 'Sahip Ekibi' alanındaki değişiklikler tarafından takip edilir.
Yakala
'SahipEkibi' alanına yapılan bir güncelleme olayı, genellikle bir denetim kaydında tutulur.
Event tipi
explicit
|
|||
|
Talep Temsilciye Atandı
|
Belirli bir temsilci hizmet talebinin sahipliğini alır. Bu etkinlik genellikle, bireysel temsilciyi belirten 'Sahip' alanı ilk kez doldurulduğunda veya güncellendiğinde çıkarılır. | ||
|
Neden önemli
Bu, başlangıçtaki bekleme veya kuyruk süresinin sonunu işaretler. Bu aktiviteden önceki süreyi ölçmek, kaynak tahsisi sorunlarını belirlemeye ve Temsilci İş Yükü dashboard'unu desteklemeye yardımcı olur.
Nereden alınır
Denetim geçmişinde görüldüğü üzere, Hizmet Talep kaydındaki 'Sahip' alanının doldurulmasından veya değişmesinden çıkarılır.
Yakala
Oluşturulduktan veya ekibe atandıktan sonra 'Sahip' alanının bir temsilcinin adıyla doldurulduğu ilk zaman damgası.
Event tipi
inferred
|
|||
|
Harici Tedarikçi Devrede
|
Servis talebi karşılaması harici bir tedarikçiye veya üçüncü tarafa devredilmiştir. Bu durum genellikle '3. Taraf Bekleniyor' veya benzer bir duruma geçişle kaydedilir. | ||
|
Neden önemli
Bu aktivite, tedarikçi performansını ve bunun genel döngü süresi üzerindeki etkisini ölçmek için esastır. Tedarikçi kaynaklı gecikmelerin analizine olanak tanır ve Harici Tedarikçi Aktivite Süresi dashboard'unu destekler.
Nereden alınır
Hizmet Talep kaydındaki durum değişikliğinden 'Üçüncü Taraf Bekleniyor' veya 'Tedarikçi Bekleniyor' gibi bir duruma çıkarılır.
Yakala
'Durum' alanındaki bir değişikliğin belirlenmiş bir 'tedarikçi bekleniyor' durumuna geçişinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Hizmet Talebi Karşılandı
|
Hizmet talebini yerine getirmek için gereken tüm görevler temsilci veya sistem tarafından tamamlandı. Bu, genellikle nihai 'Çözüldü' durumundan önce gelen 'Gerçekleştirildi' durumuna bir durum değişikliğiyle yakalanır. | ||
|
Neden önemli
Bu dönüm noktası, teknik veya prosedürel çalışmanın tamamlandığını işaretler. Nihai onay ve kapanıştan önceki aktif işlem süresini ölçmek için önemli bir noktadır.
Nereden alınır
Hizmet Talep kaydındaki 'Durum' alanının 'Gerçekleştirildi' olarak değişmesinden çıkarılır.
Yakala
Kaydın geçmişinden tespit edilen 'Durum' alanının 'Gerçekleştirildi' olarak değişmesi.
Event tipi
inferred
|
|||
|
Hizmet Talebi Yeniden Açıldı
|
Daha önce çözülmüş bir hizmet talebi, sorunun devam etmesi veya çözümün yetersiz olması nedeniyle yeniden etkinleştirildi. Bu, durumun 'Çözüldü'den 'Aktif' veya 'Atandı' gibi aktif bir duruma geri dönmesiyle yakalanır. | ||
|
Neden önemli
Bu aktivite, yeniden çalışmanın ve zayıf ilk seferde çözüm kalitesinin doğrudan bir göstergesidir. Yeniden açılma olaylarını analiz etmek, süreç zayıflıklarını belirlemeye ve Servis Talep Yeniden Çalışma Oranı KPI'ını iyileştirmeye yardımcı olur.
Nereden alınır
Denetim geçmişinden, 'Durum' alanı 'Çözüldü' veya 'Kapalı'dan aktif bir duruma değiştiğinde çıkarılır.
Yakala
Terminal bir durumdan ('Çözüldü', 'Kapalı') açık bir duruma ('Aktif', 'Atandı') durum değişikliği.
Event tipi
inferred
|
|||
|
Kullanıcı Tarafından Sağlanan Bilgi
|
Talep sahibi gerekli bilgiyi sağlamış ve temsilcinin çalışmaya devam etmesine olanak tanımıştır. Bu durum, talep 'Müşteri Bekleniyor' durumundan çıkarak 'aktif' bir duruma geri döndüğünde kaydedilir. | ||
|
Neden önemli
Bu olay, bilgi talepleri döngüsünü kapatır. Bilgi talep etme ve alma arasındaki süre, süreç gecikmelerinin ve yeniden çalışma döngülerinin kritik bir bileşenidir.
Nereden alınır
Hizmet Talebinin 'Durum' alanı 'Müşteri Bekleniyor' durumundan 'Aktif' veya 'Devam Ediyor' gibi aktif bir duruma değiştiğinde çıkarılır.
Yakala
Bir 'kullanıcı bekleniyor' durumundan aktif bir duruma durum değişikliğinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Kullanıcıdan Bilgi Talep Edildi
|
Atanan temsilcinin, talebin karşılanmasına devam etmek için talep sahibinden daha fazla bilgiye ihtiyacı vardır. Bu durum, talep durumu 'Müşteri Bekleniyor' gibi bir duruma güncellendiğinde kaydedilir. | ||
|
Neden önemli
Bu aktivite, eksik başlangıç bilgileri nedeniyle oluşan gecikmeleri vurgular. Sıklığını ve süresini takip etmek, Bilgi Talep Etki Analizi ve süreç iyileştirme alanlarını belirlemek için anahtardır.
Nereden alınır
Hizmet Talep kaydındaki durum değişikliğinden 'Müşteri Bekleniyor' veya 'Beklemede' gibi bir duruma çıkarılır.
Yakala
'Durum' alanındaki bir değişikliğin belirlenmiş bir 'kullanıcı bekleniyor' durumuna geçişinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Öncelik Değiştirildi
|
Servis talebinin önceliği, ilk oluşturulduktan sonra güncellenmiştir. Bu olay, alan düzeyindeki değişiklikleri izleyen denetim logundan veya geçmişten yakalanır. | ||
|
Neden önemli
Öncelik değişikliklerini takip etmek, Önceliklendirme Etkinliği Genel Bakışı için hayati öneme sahiptir. Yükseltmelerin doğru yönetilip yönetilmediğini ve ilk önceliklendirmenin doğru olup olmadığını belirlemeye yardımcı olur.
Nereden alınır
Bu, 'Öncelik' alanındaki değişiklikleri kaydeden Servis Talebi kaydının denetim geçmişinden yakalanan açık bir olaydır.
Yakala
Sistemin denetim kaydında kaydedilen 'Öncelik' alanına yapılan bir güncelleme olayı.
Event tipi
explicit
|
|||
|
Servis Talebi İptal Edildi
|
Servis talebi, çözümden önce kullanıcı veya bir temsilci tarafından iptal edilmiştir. Bu, 'İptal Edildi' veya 'Geri Çekildi' durumuna geçişle kaydedilen alternatif bir son durumdur. | ||
|
Neden önemli
Bu, standart dışı bir süreç sonlandırmayı temsil eder. Taleplerin neden iptal edildiğini analiz etmek, talep sürecinin kendisiyle ilgili sorunları veya değişen kullanıcı ihtiyaçlarını ortaya çıkarabilir.
Nereden alınır
Hizmet Talep kaydındaki 'Durum' alanının 'İptal Edildi' olarak değişmesinden çıkarılır.
Yakala
Denetim geçmişinden 'Durum' alanının 'İptal Edildi' olarak güncellenmesinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Talep Onay İçin Gönderildi
|
Servis talebi, karşılanmadan önce gerekli onaylar için gönderilmiştir. Bu genellikle talep durumu 'Gönderildi' veya 'Onay Bekleniyor' olarak değiştiğinde anlaşılır ve genellikle bir onay iş akışını tetikler. | ||
|
Neden önemli
Bu aktiviteyi takip etmek, onay aşamasındaki gecikmeleri belirlemeye yardımcı olur. Buradaki uzun beklemeler, genel çözüm sürelerini ve kullanıcı memnuniyetini etkileyen önemli bir darboğaz olabilir.
Nereden alınır
Hizmet Talep kaydındaki bir durum değişikliğinden, muhtemelen 'Gönderildi' veya 'Onay Bekleniyor' gibi bir duruma çıkarılır. Bu aynı zamanda FRS_Approval veya FRS_ApprovalVoteTracking iş nesnelerinden de alınabilir.
Yakala
Hizmet Talep kaydındaki 'Durum' alanının onaya bekleyen bir duruma geçmesi.
Event tipi
inferred
|
|||
|
Talep Onaylandı
|
Servis talebi gerekli tüm onayları almış ve şimdi 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 aktivite, onay aşamasının sonunu ve karşılamanın başlangıcını işaret eden önemli bir dönüm noktasıdır. Onay sürecinin kendi verimliliğini ölçmeye olanak tanır.
Nereden alınır
'Onay Bekleniyor' durumundan 'Onaylandı' veya 'Gerçekleştirildi' durumuna bir durum değişikliğinden çıkarılır. Bu, FRS_Approval iş nesnesinde kaydedilmiş açık bir olay da olabilir.
Yakala
Hizmet Talep kaydındaki 'Durum' alanının bir onay durumundan aktif bir duruma geçmesi.
Event tipi
inferred
|
|||