Hizmet Talebi Yönetimi Veri Template'iniz
Hizmet Talebi Yönetimi Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Süreç keşfi için izlenecek temel faaliyetler
- Adım adım veri çıkarma rehberliği
Hizmet Talep Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Hizmet talebi yaşam döngüsü içinde meydana gelen belirli olayın veya görevin adı. | ||
|
Açıklama
Faaliyet niteliği, hizmet talep sürecindeki her bir adımın veya durum değişikliğinin adını kaydeder. Bu, 'Talep Oluşturuldu', 'Talep Onaylandı', 'Temsilciye Atandı' veya 'Talep Kapatıldı' gibi olayları içerebilir. Bu faaliyetlerin analizi, süreç akışının görselleştirilmesine, yaygın yolların belirlenmesine ve standart prosedürden sapmaların tespit edilmesine olanak tanır. Talep gerçekleştirme sürecinde gerçekten ne olduğunu anlamanın temelidir.
Neden önemli
Bu, süreç haritasındaki adımları tanımlayan zorunlu bir niteliktir. Darboğazları, tekrar işi döngülerini ve uyumluluk sorunlarını keşfetmek de dahil olmak üzere tüm süreç analizleri için temeldir.
Nereden alınır
Örnekler
Servis Talebi OluşturulduTalep Gruba AtandıHizmet Talebi ÇözüldüKullanıcıdan Bilgi Talep Edildi
|
|||
|
Başlangıç Zamanı
EventTime
|
Bir aktivitenin veya olayın başladığını gösteren zaman damgası. | ||
|
Açıklama
Bu nitelik, hizmet talep sürecindeki her bir faaliyetin meydana geldiği kesin tarih ve saati yakalar. Süreç haritasını oluşturmak ve zamana dayalı analizler yapmak için gerekli olayların kronolojik sırasını sağlar. Doğru zaman damgaları, döngü sürelerini, bekleme sürelerini ve işlem sürelerini hesaplamak için çok önemlidir. Bu veri, darboğazların, SLA ihlallerinin ve zaman içindeki performans eğilimlerinin belirlenmesini sağlar.
Neden önemli
Bu, olayları doğru sıralamak için zorunlu bir zaman damgasıdır. Döngü süresi ve darboğaz tespiti dahil tüm performans ve süre tabanlı analizlerin temelidir.
Nereden alınır
Genellikle ilgili ServiceNow tablolarının (örn. sc_request, sc_task) 'sys_updated_on' veya 'sys_created_on' alanlarında veya denetim izinde (sys_audit) bulunur.
Örnekler
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
Servis Talebi Kimliği
ServiceRequestID
|
Her hizmet talebi kaydı için benzersiz tanımlayıcı. | ||
|
Açıklama
Hizmet Talep Kimliği, bir kullanıcı veya sistem tarafından gönderilen her hizmet talebini benzersiz şekilde tanımlayan birincil anahtardır. İlk kayıttan nihai kapanışa kadar tüm sonraki olayları birbirine bağlayan merkezi bir bağlantı görevi görür. Süreç madenciliğinde, bu kimlik her bir talebin uçtan uca yolculuğunu yeniden yapılandırmak için esastır ve yaşam döngüsünün tam bir analizine olanak tanır.
Neden önemli
Bu, zorunlu Vaka Kimliğidir. Tüm ilgili faaliyetleri tek bir süreç örneğine bağlayarak süreç akışlarının, varyasyonlarının ve döngü sürelerinin analizine olanak tanır.
Nereden alınır
ServiceNow Request [sc_request] tablosu, 'number' alanı.
Örnekler
REQ0010001REQ0010025REQ0010112
|
|||
|
Kaynak Sistem
SourceSystem
|
`Data`nın kaynaklandığı sistem. | ||
|
Açıklama
Bu nitelik, verinin kaynak sistemini tanımlar; bu durumda ServiceNow'dur. Birden fazla sistemden gelen verilerin bütünsel bir süreç görünümü için birleştirildiği ortamlarda faydalıdır. Tek kaynaklı bir analiz için, bu nitelik önemli bağlam sağlar ve veri yönetişimi ve yönetimine yardımcı olur. Herhangi bir kullanıcının analiz ettikleri verinin kaynağını anlamasını sağlar.
Neden önemli
Özellikle birden fazla kurumsal sistemden veri birleştirilirken, veri yönetişimi, izlenebilirlik ve bağlam için temel metadata sağlar.
Nereden alınır
Bu, genellikle veri çıkarma ve dönüştürme (data extraction and transformation) süreci sırasında eklenen statik bir değerdir.
Örnekler
ServiceNow
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
En son veri yenileme veya çıkarma zaman damgası. | ||
|
Açıklama
Bu nitelik, verinin kaynak sistemden en son ne zaman çıkarıldığını ve süreç madenciliği aracına yüklendiğini gösterir. Analiz edilen verinin güncelliği hakkında şeffaflık sağlar. Analistler, operasyonel izleme ve gerçek zamanlı karar verme için kritik olan en güncel verilere bakıp bakmadıklarını anlamak için bu bilgiyi kullanır. İçgörülerin ne kadar yeni olduğu konusunda beklentileri belirlemeye yardımcı olur.
Neden önemli
Kullanıcıların verilerin güncelliğinden haberdar olmasını sağlar, bu da analize güvenmek ve zamanında, veri odaklı kararlar almak için kritik öneme sahiptir.
Nereden alınır
Bu, veri alımı sırasında eklenen, ETL işi tamamlanma zaman damgasını yansıtan bir metadata alanıdır.
Örnekler
2023-10-27T04:00:00Z
|
|||
|
`SLA` Karşılandı
MadeSLA
|
Hizmet talebinin Hizmet Seviyesi Anlaşması kapsamında çözülüp çözülmediğini gösteren bir boole işareti. | ||
|
Açıklama
Bu nitelik, hizmet talebinin tanımlanmış Hizmet Seviyesi Anlaşması (SLA) çözüm süresini karşılayıp karşılamadığını gösterir. Taahhütlere karşı hizmet performansını doğrudan ölçen kritik bir sonuç metriğidir. Bu bayrağı analiz etmek, SLA Uyumluluk Oranı KPI'sını nicelleştirmeye yardımcı olur. Uyumlu taleplerin süreç yollarını ihlal edilen taleplerle karşılaştırmak için bir boyut olarak kullanılabilir, bu da SLA başarısızlıklarına katkıda bulunan yaygın desenleri veya faaliyetleri ortaya çıkarır. Bu, proaktif risk izleme ve sürekli hizmet iyileştirme için esastır.
Neden önemli
Hizmet taahhütlerine karşı performansı doğrudan ölçer ve uyumlu ile uyumsuz vakaları karşılaştırarak SLA ihlallerinin temel neden analizini yapmaya olanak tanır.
Nereden alınır
ServiceNow Task SLA [task_sla] tablosu, 'has_breached' alanı. Değerin ters çevrilmesi gerekir (örn. MadeSLA = NOT has_breached).
Örnekler
truefalse
|
|||
|
Atama Grubu
AssignmentGroup
|
Hizmet talebini ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Atama Grubu (Assignment Group), 'Servis Masası', 'Ağ Operasyonları' veya 'Veritabanı Yönetimi' gibi, belirli bir aşamada bir hizmet talebinden sorumlu olan ekibi temsil eder. Bu, farklı fonksiyonel alanlar arasındaki süreç akışını analiz etmek için önemli bir niteliktir. Atama Grubundaki değişiklikleri izleyerek, kuruluşlar ekipler arasındaki devirleri görselleştirebilir, her grubun birikmiş iş yükündeki kuyruk sürelerini ölçebilir ve ekipler arası bağımlılıkları veya gecikmeleri belirleyebilir. Bu, çapraz fonksiyonel işbirliğini optimize etmek için çok önemlidir.
Neden önemli
Ekipler arası iş dağılımını izler, ekipler arası devirleri vurgular ve ekibe özel darboğazları veya performans sorunlarını belirlemeye yardımcı olur.
Nereden alınır
ServiceNow Request Item [sc_req_item] veya Catalog Task [sc_task] tabloları, 'assignment_group' alanı.
Örnekler
Servis MasasıBT Destek L2Donanım Tedariki
|
|||
|
Atanan Kişi
AssignedTo
|
Belirli bir zamanda hizmet talebi üzerinde çalışmaktan sorumlu olan bireysel kullanıcı. | ||
|
Açıklama
Bu nitelik, hizmet talebine atanan belirli temsilciyi veya teknisyeni tanımlar. Talep farklı bireyler arasında devredildikçe değişir. 'Atanan Kişi' alanını analiz etmek, iş yükü dağılımını, bireysel performansı ve devirlerin çözüm süreleri üzerindeki etkisini anlamak için kritiktir. Kaynak kullanımına ilişkin soruları yanıtlamaya ve yeniden atamaları azaltmak için eğitim veya süreç açıklama fırsatlarını belirlemeye yardımcı olur.
Neden önemli
Temsilci iş yükü, performans ve devir analizini sağlar. Kaynak yönetimi ve belirli kişilerle ilgili darboğazları belirlemek için esastır.
Nereden alınır
ServiceNow Request Item [sc_req_item] veya Catalog Task [sc_task] tabloları, 'assigned_to' alanı.
Örnekler
Beth AnglinDavid LooHoward Johnson
|
|||
|
Durum
State
|
Hizmet talebinin mevcut operasyonel durumu. | ||
|
Açıklama
Durum niteliği, hizmet talebinin yaşam döngüsündeki mevcut aşamasını gösterir; örneğin 'Açık', 'Devam Ediyor', 'Beklemede' veya 'Kapalı'. Bu alandaki değişiklikler genellikle süreç haritası için faaliyetleri oluşturmak için kullanılır. Durumu analiz etmek, taleplerin belirli durumlarda, özellikle bekleme veya askıda kalma durumlarında ne kadar zaman geçirdiğini anlamak için çok önemlidir. 'Kullanıcı Bilgisi Bekleniyor' gibi, uzamış döngü sürelerinin yaygın bir kaynağı olan kuyrukları ve gecikmeleri belirlemeye yardımcı olur.
Neden önemli
Talebin herhangi bir andaki durumu hakkında bilgi sağlar, bekleme süreleri, kuyruklar ve belirli süreç aşamalarının süresi analizine olanak tanır.
Nereden alınır
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tabloları, 'state' veya 'stage' alanı.
Örnekler
AçıkİşlemdeKullanıcı Bilgisi BekleniyorTamamen Kapatıldı
|
|||
|
Kategori
Category
|
Donanım veya Yazılım gibi hizmet talebinin birincil sınıflandırması. | ||
|
Açıklama
Kategori, hizmet talebinin üst düzey bir sınıflandırmasını sağlar. Bu genellikle talebi doğru ekibe yönlendirmek ve gönderilen talep türleri hakkında raporlama yapmak için kullanılır. Süreç madenciliğinde Kategori, filtreleme ve boyut tabanlı analiz için güçlü bir araçtır. Analistlerin farklı talep türleri için süreç akışlarını, döngü sürelerini ve otomasyon oranlarını karşılaştırmasına olanak tanıyarak, toplu düzeyde görünmeyebilecek varyasyonları ortaya çıkarır. Örneğin, bir 'Donanım' talebinin süreci, bir 'Yazılım' talebinden temelden farklı olabilir.
Neden önemli
Farklı hizmet türleri arasında süreçlerin güçlü bir şekilde segmentasyonuna ve karşılaştırılmasına olanak tanır, kategoriye özgü sorunları ve iyileştirme fırsatlarını belirlemeye yardımcı olur.
Nereden alınır
ServiceNow Request Item [sc_req_item] tablosu, genellikle ilişkili Katalog Öğesinin [sc_cat_item] kategorisi aracılığıyla.
Örnekler
DonanımYazılımErişim TalebiAğ
|
|||
|
Öncelik
Priority
|
Hizmet talebinin aciliyetini etkileyen öncelik seviyesi. | ||
|
Açıklama
Öncelik, bir hizmet talebinin göreceli önemini ve aciliyetini belirleyen bir sınıflandırmadır. Genellikle etki ve aciliyetin bir kombinasyonuyla belirlenir ve temsilcilere hangi talepleri önce ele alacakları konusunda rehberlik etmek için kullanılır. Verileri önceliğe göre analiz etmek, yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı işlenip işlenmediğini anlamak için çok önemlidir. Bu, kritik talepler için SLA'ların karşılanıp karşılanmadığını görmek amacıyla Dashboard'ları filtrelemeye olanak tanır ve önceliklendirme sisteminin etkili olup olmadığını belirlemeye yardımcı olur.
Neden önemli
Yüksek öncelikli öğelerin daha hızlı işlendiğini doğrulamak için taleplerin segmentasyonunu sağlar. SLA analizi ve kaynak tahsisi için anahtardır.
Nereden alınır
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tabloları, 'priority' alanı.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
Açan Kişi
OpenedBy
|
Hizmet talebini başlangıçta gönderen kişi. | ||
|
Açıklama
Bu nitelik, hizmet talebini oluşturan kullanıcıyı tanımlar. Genellikle talepten etkilenen kişiyle aynı olsa da, bir yönetici, bir delege veya otomatik bir sistem de olabilir. 'Açan Kişi' kullanıcısına veya departmanına göre talepleri analiz etmek, sık sık karmaşık veya sorunlu talepler gönderen belirli bir kullanıcı grubu gibi desenleri belirlemeye yardımcı olur. Bu, hedeflenen eğitimlere bilgi sağlayabilir veya self-service'i teşvik etmek için daha iyi bilgi tabanı makalelerine olan ihtiyacı vurgulayabilir.
Neden önemli
Kullanıcı, departman veya role göre talep modellerini analiz etmeye yardımcı olur, bu da eğitim girişimlerine ve hedeflenen süreç iyileştirmelerine ışık tutabilir.
Nereden alınır
ServiceNow Request [sc_request] tablosu, 'opened_by' alanı.
Örnekler
Abel TuterFred LuddyDon Goodliffe
|
|||
|
Bitiş Saati
EndTime
|
Bir aktivitenin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
Bitiş Saati, bir faaliyetin sona ermesini işaret eder. Sıradaki bir sonraki faaliyetin zaman damgasıdır ve mevcut faaliyetin süresini etkili bir şekilde kapatır. Bu nitelik, süreçteki her adımın ne kadar sürdüğünü hesaplamak için esastır. Bir faaliyetin Başlangıç Saati ve Bitiş Saatini karşılaştırarak, analistler işlem sürelerini ve bekleme sürelerini hesaplayabilirler. Bu, darboğazları belirlemek, kaynak verimliliğini ölçmek ve zamana dayalı hedeflere karşı performansı izlemek için temeldir.
Neden önemli
Bu nitelik, performans analizi, darboğaz tespiti ve kaynak kullanım çalışmaları için temel bir bileşen olan her bir faaliyetin süresini hesaplamak için gereklidir.
Nereden alınır
Bu, vaka içindeki sonraki olayın 'BaşlangıçZamanı' alınarak hesaplanan türetilmiş bir niteliktir.
Örnekler
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Çözüm Kodu
ResolutionCode
|
Hizmet talebinin nihai çözümünü kategorize eden bir kod. | ||
|
Açıklama
Çözüm Kodu, bir hizmet talebinin nihayetinde nasıl çözüldüğüne dair yapılandırılmış bir sınıflandırmadır. Örnekler arasında 'Otomasyonla Karşılandı', 'Kullanıcı Hatası' veya 'Artık Gerekli Değil' yer alır. Bu nitelik, Gecikmeler için Kök Neden Analizi Dashboard'u için hayati öneme sahiptir. Çözüm kodlarını uzun döngü süreleri veya yüksek tekrar işi oranlarıyla ilişkilendirerek, analistler sistemik sorunları belirleyebilirler. Örneğin, 'Eksik Bilgi' kodlu talepler sürekli yavaşsa, bu başlangıçtaki veri toplama adımında bir soruna işaret eder.
Neden önemli
Çözüm sonuçları hakkında yapılandırılmış veri sağlar, süreç gecikmelerinin, tekrar işlerinin ve diğer verimsizliklerin kök neden analizine olanak tanır.
Nereden alınır
ServiceNow Request Item [sc_req_item] veya ilgili bir görev tablosu, alan genellikle 'close_code' veya 'resolution_code' olarak adlandırılır.
Örnekler
Çözüldü (Kalıcı)Çözülmedi (Tekrarlanamaz)Talep KarşılandıKullanıcı Tarafından İptal Edildi
|
|||
|
İlk Seferde Çözüm mü?
IsFirstPassResolution
|
Talebin herhangi bir yeniden açılma olmadan ilk denemede çözülüp çözülmediğini gösteren bir işaret. | ||
|
Açıklama
Bu hesaplanmış nitelik, hizmet talebinin hiç yeniden açılmadan çözülüp kapatıldığı durumlarda 'doğru' olan bir boolean bayrağıdır. Servis masası tarafından sağlanan çözümün kalitesi ve etkinliğinin önemli bir göstergesidir. Bu metrik, İlk Seferde Çözüm Oranı KPI'sını doğrudan destekler. Yüksek bir oran, verimliliği ve yüksek kaliteli hizmeti gösterdiği için arzu edilir, bu da daha iyi müşteri memnuniyetine yol açar. İlk seferde çözümde başarısız olan vakaların niteliklerini analiz etmek, yetersiz eğitim, kötü dokümantasyon veya yanlış başlangıç teşhisi gibi kök nedenleri ortaya çıkarabilir.
Neden önemli
Çözüm sürecinin kalitesini ve verimliliğini ölçer. Düşük ilk seferde çözüm oranı, tekrar işine ve müşteri memnuniyetsizliğine yol açan temel sorunları gösterir.
Nereden alınır
Vaka düzeyinde hesaplanır. Bir vaka, 'Yeniden Açılma Sayısı' sıfır ise ilk geçiş çözümü olarak kabul edilir.
Örnekler
truefalse
|
|||
|
İşlem Süresi
ProcessingTime
|
Belirli bir faaliyet üzerinde aktif olarak çalışılan sürenin uzunluğu. | ||
|
Açıklama
İşlem Süresi, aynı zamanda aktif süre veya işlem süresi olarak da bilinir, bir görevi aktif olarak yerine getirirken harcanan süredir. Bir faaliyetin Bitiş Saati ile Başlangıç Saati arasındaki fark olarak hesaplanır. Bu, bir talebin boşta kaldığı bekleme süresinden farklıdır. Bu metrik, Darboğaz ve Kuyruk Analizi Dashboard'u için çok önemlidir. Her bir faaliyet türü için işlem sürelerini toplayarak, analistler hangi adımların en çok kaynak ve çaba tükettiğini belirleyebilirler. Bu, süreç iyileştirme girişimlerini en çok zaman alan görevlere odaklanmak için önceliklendirmeye yardımcı olur.
Neden önemli
Her bir faaliyetin aktif çalışma süresini ölçer, süreçteki en çok zaman alan adımları belirlemeye ve operasyonel darboğazları tespit etmeye yardımcı olur.
Nereden alınır
Her olay kaydı için 'Bitiş Zamanı' eksi 'Başlangıç Zamanı' olarak hesaplanır.
Örnekler
0 00:05:100 01:14:450 00:09:55
|
|||
|
Kanal
ContactType
|
Talep sahibinin hizmet talebini göndermek için kullandığı yöntem. | ||
|
Açıklama
İletişim Türü veya kanal, hizmet talebinin nasıl başlatıldığını belirtir. Yaygın kanallar arasında hizmet portalı, e-posta, telefon görüşmesi veya otomatik uyarı bulunur. Kanalı anlamak, gönderim yönteminden etkilenebilecek süreç varyasyonlarını analiz etmek için önemlidir. Örneğin, portal aracılığıyla gönderilen talepler, e-posta aracılığıyla gönderilenlere göre daha yapılandırılmış ve otomatik olabilir, bu da daha hızlı işlem sürelerine yol açar. Bu analiz, daha verimli kanalların teşvik edilmesine yardımcı olur.
Neden önemli
Farklı başvuru kanallarının süreç verimliliğini, otomasyon seviyelerini ve genel döngü sürelerini nasıl etkilediğini belirlemeye yardımcı olur, kullanıcı etkileşimlerini optimize etme çabalarına rehberlik eder.
Nereden alınır
ServiceNow Request [sc_request] veya Interaction [interaction] tabloları. Alan genellikle 'contact_type' olarak adlandırılır.
Örnekler
PortalE-postaTelefonSelf-servis
|
|||
|
Memnuniyet Puanı
SatisfactionScore
|
Talep sahibi tarafından kapanışta sağlanan müşteri memnuniyeti derecesi. | ||
|
Açıklama
Bu nitelik, son kullanıcının hizmet talebi çözüldükten sonra gönderdiği, genellikle 1-5 ölçeğinde olan memnuniyet puanını yakalar. Bu, algılanan hizmet kalitesinin doğrudan bir ölçüsüdür. Bu veri, Müşteri Memnuniyeti Etki Analizi Dashboard'u için esastır. Süreç metrikleri (döngü süresi, tekrar işi ve devirler gibi) ile nihai müşteri deneyimi arasında doğrudan bir ilişki kurulmasına olanak tanır. Bu, operasyonel verimliliği müşteri sonuçlarına bağlayarak süreç iyileştirmeleri için iş gerekçesini kanıtlamaya yardımcı olur.
Neden önemli
Süreç performansı metriklerini doğrudan müşteri sonuçlarına bağlar, süreç verimsizliklerinin kullanıcı deneyimi üzerindeki etkisini nicel olarak belirlemeye yardımcı olur.
Nereden alınır
Genellikle orijinal talebe bağlı olan ilgili bir Survey [asmt_assessment_instance] tablosunda bulunur.
Örnekler
5431
|
|||
|
Otomatikleştirildi mi?
IsAutomated
|
Bir etkinliğin bir sistem veya otomasyon tarafından gerçekleştirilip gerçekleştirilmediğini gösteren bir işaret. | ||
|
Açıklama
Bu boolean nitelik, bir insan temsilci tarafından manuel olarak gerçekleştirilen faaliyetler ile iş akışı veya entegrasyon gibi otomatik bir sistem tarafından yürütülen faaliyetler arasında ayrım yapar. Örneğin, 'Onay Talep Edildi' otomatik olabilirken, 'Talep Temsilciye Atandı' manuel olabilir. Bu niteliği analiz etmek, hizmet talebi sürecindeki otomasyon seviyesini ölçmek ve artırmak için anahtardır. Hangi manuel görevlerin en çok zaman aldığını ve gelecekteki otomasyon için aday olabileceğini belirlemeye yardımcı olur, böylece verimliliği artırır ve maliyetleri azaltır.
Neden önemli
Otomasyon oranlarının ölçülmesine olanak tanır ve manuel görevleri otomatikleştirmek için fırsatları belirlemeye yardımcı olarak verimliliği artırır ve operasyonel maliyetleri azaltır.
Nereden alınır
Bir eylemi gerçekleştiren kullanıcının (örn. 'sys_updated_by') belirlenmiş bir sistem veya entegrasyon kullanıcısı olup olmadığı kontrol edilerek türetilir.
Örnekler
truefalse
|
|||
|
Vaka Cycle Time
CaseCycleTime
|
Bir hizmet talebinin oluşturulmasından nihai kapanışına kadar geçen toplam süre. | ||
|
Açıklama
Vaka Döngü Süresi, bir hizmet talebinin en ilk olay zaman damgasından en son olayın zaman damgasına kadar toplam süresini ölçen hesaplanmış bir metriktir. Müşteri bakış açısından tam uçtan uca işleme süresini temsil eder. Bu, genel süreç verimliliği için birincil bir Temel Performans Göstergesidir (KPI). Hedeflere karşı performansı izlemek ve zaman içindeki eğilimleri analiz etmek için üst düzey Dashboard'larda kullanılır. Hangi tür taleplerin en uzun sürdüğünü belirlemek için Kategori veya Öncelik gibi boyutlara göre dilimlenebilir.
Neden önemli
Bu, uçtan uca süreç performansını ölçen kritik bir KPI'dır. Yüksek seviye izleme, kıyaslama ve iyileştirme alanlarını belirlemek için esastır.
Nereden alınır
Her benzersiz 'ServiceRequestID' için maksimum 'EndTime'dan minimum 'StartTime' çıkarılarak hesaplanır.
Örnekler
2 10:30:000 04:15:2210 00:05:00
|
|||
|
Yeniden Açılma Sayısı
ReopenCount
|
Bir hizmet talebinin çözüldükten sonra kaç kez yeniden açıldığı sayısı. | ||
|
Açıklama
Bu nitelik, bir hizmet talebinin çözülmüş veya kapalı bir durumdan açık veya devam eden bir duruma kaç kez geri döndürüldüğünü izleyen bir sayacın niteliğidir. Sıfırdan büyük bir sayı, başlangıçtaki çözümün başarılı olmadığını gösterir. Bu metrik, tekrar işinin doğrudan bir göstergesidir ve İlk Seferde Çözüm Oranı KPI'sının temel bir bileşenidir. Yüksek yeniden açılma sayıları, çözüm kalitesiyle, eksik gerçekleştirmeyle veya kullanıcının ihtiyaçlarının yanlış anlaşılmasıyla ilgili sorunları gösterir; bunların hepsi süreç verimsizliğine ve kullanıcı memnuniyetsizliğine yol açar.
Neden önemli
Tekrar işini ve çözüm kalitesini ölçer. Yüksek yeniden açılma sayısı, verimsizliklere, düşük ilk seferde düzeltme oranlarına ve azalan müşteri memnuniyetine işaret eder.
Nereden alınır
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tabloları, 'reopen_count' alanı.
Örnekler
012
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir etkinliğin aynı vaka içinde önceki bir etkinliğin tekrarı olup olmadığını gösteren hesaplanmış bir işaret. | ||
|
Açıklama
Bu boolean bayrağı, bir hizmet talebindeki tekrar işi döngülerini belirlemek için hesaplanır. Aynı faaliyet aynı vakada daha önce zaten meydana gelmişse, örneğin bir talep iki kez aynı ekibe atanmışsa veya kullanıcıdan birden çok kez bilgi istenmişse, 'doğru' olarak işaretlenir. Bu nitelik, Temsilci Devirleri ve Tekrar İşi Olayları Dashboard'u ve Talep Tekrar İşi Oranı KPI'sı için esastır. Süreçteki verimsiz döngülerin doğrudan görselleştirilmesine ve nicelleştirilmesine olanak tanır, bu döngüler genellikle toplu verilerde gizlidir.
Neden önemli
Süreç yeniden işlenmesini doğrudan işaretler ve ölçer, maliyetleri ve döngü sürelerini artıran verimsiz döngülerin nedenlerini ve etkilerini analiz etmeyi mümkün kılar.
Nereden alınır
Aynı vaka içinde aynı etkinlik adının önceki oluşumları kontrol edilerek veri dönüşümü sırasında hesaplanır.
Örnekler
falsetrue
|
|||
Hizmet Talep Yönetimi Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet Talebi Çözüldü
|
Bu faaliyet, gerçekleştirme temsilcisinin işi tamamladığını ve bir çözüm sağladığını gösterir. Talebin durumu 'Çözüldü' veya benzer bir duruma güncellendiğinde yakalanır. | ||
|
Neden önemli
Bu, genellikle SLA saatini durduran kritik bir dönüm noktasıdır. Aktif gerçekleştirme işinin sonunu işaret eder ve toplam çözüm süresi hesaplamasının temel bir bileşenidir.
Nereden alınır
sc_req_item durum alanının son kapanmadan önce 'Çözüldü' veya benzer bir nihai duruma güncellenmesinden çıkarılır. Değişiklik sys_audit tablosunda izlenir.
Yakala
sc_req_item.state 'Çözüldü' durumuna geçtiğinde zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Hizmet Talebi Kapatıldı
|
Hizmet talebi yaşam döngüsünün nihai, kesin sonunu işaret eder. Bu genellikle 'Çözüldü' durumunda belirli bir süre sonra otomatik olarak gerçekleşir ve bu süre zarfında kullanıcı talebi yeniden açabilir. | ||
|
Neden önemli
Bu, süreç için birincil başarılı son olaydır. 'Çözüldü' ve 'Kapalı' arasındaki süre, otomatik kapanış politikalarını anlamak için de analiz edilebilir.
Nereden alınır
sc_req_item durum alanının 'Tamamen Kapandı' gibi nihai bir kapalı duruma güncellenmesinden çıkarılır. Bu, sys_audit tablosuna kaydedilir.
Yakala
sc_req_item.state 'Tamamen Kapandı' durumuna geçtiğinde zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Kullanıcıdan Bilgi Talep Edildi
|
Gerçekleştirme temsilcisinin devam etmek için orijinal talep sahibinden daha fazla bilgiye ihtiyaç duyması durumunda meydana gelir. Bu genellikle talebin durumu 'Kullanıcı Bilgisi Bekleniyor' gibi bir değere değiştiğinde çıkarılır. | ||
|
Neden önemli
Bu faaliyet, 'Talep Sahibi Bilgi Gecikmesi Analizi' Dashboard'u için çok önemlidir ve kullanıcıdan harici girdi beklerken kaybedilen süreyi nicelleştirmeye yardımcı olur.
Nereden alınır
sc_req_item durum alanının belirlenmiş bir 'bilgi bekleniyor' durumuna değişmesinden çıkarılır. Değişiklik sys_audit tablosuna kaydedilir.
Yakala
Event tipi
inferred
|
|||
|
Servis Talebi Oluşturuldu
|
Bu faaliyet, bir kullanıcının hizmet kataloğu aracılığıyla bir talep göndermesiyle hizmet talebi yaşam döngüsünün başlangıcını işaret eder. Sistem bunu, sc_req_item (Talep Edilen Öğe) tablosunda yeni bir kaydın oluşturulma olayı olarak yakalar. | ||
|
Neden önemli
Bu, süreç için birincil başlangıç olayıdır. Genel döngü süresini hesaplamak ve talep hacimlerini ve gönderim desenlerini analiz etmek için esastır.
Nereden alınır
Bu, sc_req_item tablosundaki kaydın oluşturulma zaman damgasından (sys_created_on alanı) yakalanan açık bir olaydır.
Yakala
sc_req_item kaydındaki sys_created_on zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Talep Onaylandı
|
Bu faaliyet, talebin resmi olarak onaylandığını ve gerçekleştirme aşamasına geçebileceğini gösterir. Bir onaylayıcı, ilgili onay kaydını 'onaylandı' olarak işaretlediğinde yakalanır. | ||
|
Neden önemli
Bu önemli dönüm noktası, onay aşamasından gerçekleştirme aşamasına geçişi işaret eder. Bu adıma ulaşmak için geçen süreyi analiz etmek, gerçekleştirme öncesi gecikmeleri anlamak için çok önemlidir.
Nereden alınır
İlgili sysapproval_approver kaydının durum alanının 'onaylandı' olarak değişmesi ve bunun sonucunda sc_req_item üzerinde bir durum değişikliği tetiklenmesinden çıkarılır.
Yakala
sysapproval_approver.state 'onaylandı' olduğunda zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Temsilciye Atandı
|
Bu faaliyet, belirli bir bireysel temsilcinin hizmet talebi üzerinde çalışmak üzere atandığında meydana gelir. Talebin veya gerçekleştirme görevlerinin 'Atanan Kişi' alanındaki değişiklikler izlenerek yakalanır. | ||
|
Neden önemli
Bu, devirleri ölçmek, temsilciye özel iş yüklerini hesaplamak ve bir birey bir talep üzerinde çalışmaya başlamadan önceki kuyruk sürelerini analiz etmek için kritiktir.
Nereden alınır
sc_req_item veya sc_task tablosundaki assigned_to alanında yapılan bir değişiklikten çıkarılır. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Yakala
sys_audit'teki assigned_to alanındaki değişiklikleri izleyin.
Event tipi
inferred
|
|||
|
Harici Tedarikçi Devreye Alındı
|
Bir hizmet talebinin veya görevlerinden birinin, gerçekleştirme için harici bir üçüncü taraf tedarikçiye devredilmesini temsil eder. Bu, tedarikçiye özel bir gruba atamadan veya talep üzerindeki bir bayraktan çıkarılabilir. | ||
|
Neden önemli
Bu faaliyet, tedarikçi performansının ve genel talep yaşam döngüsü üzerindeki etkisinin analizini sağlar; bu, 'Dış Tedarikçi Etkileşim Döngüsü' Dashboard'u için çok önemlidir.
Nereden alınır
Bu genellikle çıkarılır. assignment_group'un bir tedarikçi grubuna ayarlanmasına veya sc_req_item veya sc_task kaydında belirli bir bayrak alanının ayarlanmasına dayanabilir.
Yakala
Event tipi
inferred
|
|||
|
Kullanıcı Tarafından Sağlanan Bilgi
|
Bu faaliyet, talep sahibinin gerekli bilgiyi sağladığı noktayı işaret eder. Talep, 'Kullanıcı Bilgisi Bekleniyor' durumundan 'Devam Ediyor' gibi aktif bir duruma geçtiğinde çıkarılır. | ||
|
Neden önemli
'Kullanıcıdan Bilgi Talep Edildi' ile eşleştirildiğinde, bu faaliyet kullanıcının neden olduğu gecikmelerin hassas bir şekilde ölçülmesine olanak tanır ve iletişim sürecinin verimliliğini değerlendirmeye yardımcı olur.
Nereden alınır
sc_req_item durum alanının 'bilgi bekleniyor' durumundan aktif bir duruma değişmesinden çıkarılır. Bu genellikle kullanıcının bir yorum eklemesi veya bir e-postayı yanıtlamasıyla tetiklenir.
Yakala
Durum 'Kullanıcı Bilgisi Bekleniyor'dan 'Devam Ediyor'a değiştiğinde zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Onay Talep Edildi
|
Bir hizmet talebinin bir yöneticiden veya başka bir belirlenmiş onaylayıcıdan onay almak üzere gönderildiği noktayı temsil eder. Bu genellikle talebin durumu 'Onay Bekliyor' veya benzer bir duruma değiştiğinde çıkarılır. | ||
|
Neden önemli
Onayları izlemek, onay sürecindeki darboğazları belirlemeye ve taleplerin gerçekleştirme başlamadan önce yetkilendirme için ne kadar beklediğini ölçmeye yardımcı olur.
Nereden alınır
sc_req_item durum alanının onay bekleyen bir değere değişmesinden veya sysapproval_approver tablosunda ilgili bir kaydın oluşturulmasından çıkarılır. Değişiklikler sys_audit tablosuna kaydedilir.
Yakala
sc_req_item.state 'Onay Bekliyor' durumuna geçtiğinde zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Gruba Atandı
|
Hizmet talebinin belirli bir gerçekleştirme ekibine veya grubuna atandığını gösterir. Bu olay, talep öğesindeki veya ilgili görevlerdeki atama grubu (assignment group) alanındaki bir değişikliğin tespit edilmesiyle çıkarılır. | ||
|
Neden önemli
Grup atamalarını izlemek, ekipler arasındaki iş yükü dağılımını analiz etmeye ve bir talebin doğru gerçekleştiricilere yönlendirilmeden önceki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır
sc_req_item veya sc_task tablosundaki assignment_group alanında yapılan bir değişiklikten çıkarılır. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Yakala
sys_audit'teki assignment_group alanındaki değişiklikleri izleyin.
Event tipi
inferred
|
|||
|
Talep İptal Edildi
|
Bu faaliyet, tamamlanmadan önce kullanıcı veya bir temsilci tarafından iptal edilen talepler için bir terminal durumu görevi görür. Talep durumu 'İptal Edildi' veya 'Kapalı İptal Edildi' olarak ayarlandığında yakalanır. | ||
|
Neden önemli
Bu, başarısız olan önemli bir son olaydır. Taleplerin neden iptal edildiğini analiz etmek, kullanıcı ihtiyaçları, süreç verimsizlikleri veya değişen iş öncelikleri hakkında içgörüler sağlayabilir.
Nereden alınır
sc_req_item durum alanının 'Kapalı İptal Edildi' gibi nihai bir iptal durumuna güncellenmesinden çıkarılır. Değişiklik sys_audit tablosunda günlüğe kaydedilir.
Yakala
sc_req_item.state 'İptal Edildi' durumuna geçtiğinde zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Reddedildi
|
Bu faaliyet, bir talebin onay aşamasında resmi olarak reddedildiği sonucu temsil eder. Kapanışa giden alternatif bir yoldur ve bir onaylayıcı talebi 'reddedildi' olarak işaretlediğinde yakalanır. | ||
|
Neden önemli
Redleri izlemek, geçersiz veya yanlış yönlendirilmiş talepleri, talep gönderim sürecindeki sorunları belirlemeye yardımcı olur ve analiz için önemli bir istisna yolu görevi görür.
Nereden alınır
İlgili sysapproval_approver kaydının durum alanının 'reddedildi' olarak değişmesinden çıkarılır. Bu genellikle üst sc_req_item'ı kapalı, tamamlanmamış bir duruma ayarlar.
Yakala
sysapproval_approver.state 'reddedildi' olduğunda zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Yeniden Açıldı
|
Bu faaliyet, daha önce çözüldü olarak işaretlenen bir talebin açık bir duruma geri döndüğü durumları yakalar. Bu, 'Çözüldü' durumundan 'Devam Ediyor' veya benzer bir duruma geri dönüşle çıkarılır. | ||
|
Neden önemli
Bu, tekrar işinin doğrudan bir ölçüsüdür ve 'İlk Seferde Çözüm Oranı' KPI'sını hesaplamak için kritiktir. Yüksek sayılar, düşük çözüm kalitesini veya eksik çözümü gösterir.
Nereden alınır
sc_req_item durum alanında, çözülmüş veya kapalı bir durumdan açık, devam eden bir duruma geri dönen bir değişiklikten çıkarılır. Bu değişiklik sys_audit'te günlüğe kaydedilir.
Yakala
Event tipi
inferred
|
|||
|
Yerine Getirme Görevi Oluşturuldu
|
Hizmet talebini yerine getirmek için gereken belirli bir iş öğesinin veya görevin oluşturulmasını temsil eder. Bu, Catalog Task tablosunda yeni bir kayıt oluşturulduğunda günlüğe kaydedilen açık bir olaydır. | ||
|
Neden önemli
Karmaşık talepler için, bireysel görevlerin oluşturulması ve tamamlanmasının analizi, yerine getirme sürecinin ve gecikmelerin nerede meydana geldiğinin daha ayrıntılı bir görünümünü sağlar.
Nereden alınır
Bu, sc_req_item'a bağlanan sc_task tablosundaki bir kaydın oluşturulma zaman damgasından (sys_created_on alanı) yakalanan açık bir olaydır.
Yakala
sc_task kayıtlarındaki sys_created_on zaman damgasını kullanın.
Event tipi
explicit
|
|||