Hizmet Talebi Yönetimi Veri Şablonunuz
Hizmet Talebi Yönetimi Veri Şablonunuz
- Toplanması önerilen öznitelikler
- Süreç keşfi için izlenecek temel aktiviteler
- Adım adım veri çıkarma yönergeleri
Hizmet Talebi Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTime
|
Bir etkinliğin veya olayın ne zaman başladığını gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, hizmet talebi sürecindeki her etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. 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ı, çevrim sürelerini, bekleme sürelerini ve işleme sürelerini hesaplamak için büyük önem taşır. Bu veri, darboğazları, SLA ihlallerini ve zaman içindeki performans eğilimlerini belirlemenizi sağlar.
Neden önemli?
Olayları doğru sıraya koymak için zorunlu bir zaman damgasıdır. Çevrim süresi ve darboğaz belirleme dahil performans ve süreye dayalı tüm analizlerin temelini oluşturur.
Nereden alınır?
Genellikle ilgili ServiceNow tablolarındaki (ör. sc_request, sc_task) 'sys_updated_on' veya 'sys_created_on' alanlarında ya da denetim izinde (sys_audit) bulunur.
Örnekler
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
Etkinlik
ActivityName
|
Hizmet talebi yaşam döngüsü içinde gerçekleşen belirli olayın veya görevin adı. | ||
|
Açıklama
Activity özniteliği, hizmet talebi sürecindeki her adımın veya durum değişikliğinin adını kaydeder. Buna 'Request Created', 'Request Approved', 'Assigned to Agent' veya 'Request Closed' gibi olaylar dahil olabilir. Bu etkinlikleri analiz etmek, süreç akışını görselleştirmenize, yaygın yolları belirlemenize ve standart prosedürden sapmaları tespit etmenize olanak tanır. Talep yerine getirme sürecinde gerçekte neler olduğunu anlamanın temelini oluşturur.
Neden önemli?
Bu, süreç haritasındaki adımları tanımlayan zorunlu bir özniteliktir. Darboğazları, yeniden çalışma döngülerini ve uyumluluk sorunlarını keşfetme dahil tüm süreç analizleri için temel oluşturur.
Nereden alınır?
'sc_request' veya 'sc_req_item' gibi tablolardaki 'State' ya da 'Stage' alanlarında yapılan değişikliklerden veya denetim izinden (sys_audit) türetilir.
Örnekler
Hizmet talebi oluşturulduTalep grubuna atandıHizmet talebi çözüldüKullanıcıdan bilgi istendi
|
|||
|
Hizmet talebi kimliği
ServiceRequestID
|
Her hizmet talebi kaydını benzersiz şekilde tanımlayan benzersiz tanımlayıcı. | ||
|
Açıklama
Hizmet talebi 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 kapatmaya kadar sonraki tüm olayları birbirine bağlayan merkezi bir iz görevi görür. Process Mining kapsamında bu kimlik, her talebin uçtan uca yolculuğunu yeniden oluşturmak ve yaşam döngüsünü eksiksiz analiz etmek için gereklidir.
Neden önemli?
Bu, zorunlu Case ID alanıdır. İlgili tüm etkinlikleri tek bir süreç örneğinde birleştirerek süreç akışlarının, varyasyonların ve çevrim sürelerinin analiz edilmesini sağlar.
Nereden alınır?
ServiceNow Request [sc_request] tablosu, 'number' alanı.
Örnekler
REQ0010001REQ0010025REQ0010112
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin geldiği sistem. | ||
|
Açıklama
Bu öznitelik, verinin kaynak sistemini tanımlar. Bu örnekte kaynak sistem ServiceNow'dur. Birden fazla sistemden alınan verilerin bütünsel bir süreç görünümü oluşturmak üzere birleştirildiği ortamlarda kullanışlıdır. Tek kaynaklı analizlerde bu öznitelik önemli bir bağlam sağlar ve veri yönetişimi ile yönetimine yardımcı olur. Analiz edilen verinin kaynağının anlaşılmasını sağlar.
Neden önemli?
Özellikle birden fazla kurumsal sistemden alınan veriler birleştirildiğinde veri yönetişimi, izlenebilirlik ve bağlam için gerekli meta verileri sağlar.
Nereden alınır?
Bu, genellikle veri çıkarma ve dönüştürme sürecinde eklenen statik bir değerdir.
Örnekler
ServiceNow
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
En son veri yenileme veya çıkarma işleminin zaman damgası. | ||
|
Açıklama
Bu öznitelik, verilerin kaynak sistemden en son çıkarılıp Process Mining aracına yüklendiği tarih ve saati gösterir. Analiz edilen verilerin güncelliği hakkında şeffaflık sağlar. Analistler, en güncel verileri inceleyip incelemediklerini anlamak için bu bilgiyi kullanır. Bu bilgi, operasyonel izleme ve zamanında karar verme açısından önemlidir. İçgörülerin ne kadar güncel olduğu konusunda beklentileri netleştirmeye yardımcı olur.
Neden önemli?
Kullanıcıların verilerin güncelliğinden haberdar olmasını sağlar. Bu, analize güvenmek ve veriye dayalı zamanında kararlar almak için önemlidir.
Nereden alınır?
Veri alma sürecinde eklenen bir meta veri alanıdır ve ETL işinin tamamlandığı zaman damgasını gösterir.
Örnekler
2023-10-27T04:00:00Z
|
|||
|
Atama grubu
AssignmentGroup
|
Hizmet talebini ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Assignment Group, belirli bir aşamada hizmet talebinden sorumlu olan 'Service Desk', 'Network Operations' veya 'Database Administration' gibi ekibi temsil eder. Farklı işlevsel alanlar arasındaki süreç akışını analiz etmek için önemli bir özniteliktir. Atama grubundaki değişiklikleri izleyerek ekipler arasındaki devirleri görselleştirebilir, her grubun iş listesindeki kuyruk sürelerini ölçebilir ve ekipler arası bağımlılıkları veya gecikmeleri belirleyebilirsiniz. Bu, işlevler arası iş birliğini iyileştirmek için önemlidir.
Neden önemli?
İş dağılımını ekipler arasında izler, ekipler arası devirleri görünür kılar ve ekiplere özgü 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
Hizmet masasıBT Desteği 2. SeviyeDonanım tedariki
|
|||
|
Atanan kişi
AssignedTo
|
Belirli bir zamanda hizmet talebi üzerinde çalışmaktan sorumlu kullanıcı. | ||
|
Açıklama
Bu öznitelik, hizmet talebine atanan görevliyi veya teknisyeni tanımlar. Talep farklı kişiler arasında devredildikçe değişir. 'Assigned To' alanını analiz etmek, iş yükü dağılımını, bireysel performansı ve devirlerin çözüm sürelerine etkisini anlamak için önemlidir. Kaynak kullanımına ilişkin soruları yanıtlamaya ve yeniden atamaları azaltmak için eğitim veya süreç açıklığı fırsatlarını belirlemeye yardımcı olur.
Neden önemli?
Görevli iş yükünü, performansını ve devirleri analiz etmenizi sağlar. Kaynak yönetimi ve belirli kişilerle ilişkili darboğazları belirlemek için gereklidir.
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
State özniteliği, hizmet talebinin yaşam döngüsündeki mevcut aşamayı gösterir. Örnekler arasında 'Open', 'Work in Progress', 'Pending' ve 'Closed' bulunur. Bu alandaki değişiklikler genellikle süreç haritasındaki etkinlikleri oluşturmak için kullanılır. State alanını analiz etmek, taleplerin belirli durumlarda, özellikle bekleme veya beklemede durumlarında ne kadar zaman geçirdiğini anlamak için önemlidir. 'Awaiting User Information' durumunda geçirilen süre gibi kuyrukları ve gecikmeleri belirlemeye yardımcı olur. Bu tür süreler, çevrim sürelerinin uzamasına sıkça neden olur.
Neden önemli?
Talebin herhangi bir andaki durumunu göstererek bekleme sürelerini, kuyrukları ve belirli süreç aşamalarının süresini analiz etmenizi sağlar.
Nereden alınır?
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tabloları, 'state' veya 'stage' alanı.
Örnekler
AçıkÇalışma devam ediyorKullanıcı bilgilerinin alınması bekleniyorTamamlanarak kapatıldı
|
|||
|
Kategori
Category
|
Donanım veya Yazılım gibi hizmet talebinin temel sınıflandırması. | ||
|
Açıklama
Category, hizmet talebinin üst düzey sınıflandırmasını sağlar. Genellikle talebi doğru ekibe yönlendirmek ve gönderilen talep türlerini raporlamak için kullanılır. Process Mining kapsamında Category, filtreleme ve boyut bazlı analiz için etkili bir araçtır. Farklı talep türlerinin süreç akışlarını, çevrim sürelerini ve otomasyon oranlarını karşılaştırmanızı sağlar. Böylece toplu düzeyde görünmeyen farklılıkları ortaya çıkarabilirsiniz. Örneğin 'Hardware' talebinin süreci, 'Software' talebinin sürecinden temelde farklı olabilir.
Neden önemli?
Farklı hizmet türlerindeki süreçleri ayrıntılı biçimde segmentlere ayırıp karşılaştırmanızı sağlar. Kategoriye özgü sorunları ve iyileştirme fırsatlarını belirlemenize yardımcı olur.
Nereden alınır?
ServiceNow Request Item [sc_req_item] tablosu, genellikle ilişkili Catalog Item [sc_cat_item] kategorisi üzerinden.
Örnekler
DonanımYazılımErişim TalebiAğ
|
|||
|
Öncelik
Priority
|
Hizmet talebinin aciliyetini etkileyen öncelik düzeyi. | ||
|
Açıklama
Öncelik, bir hizmet talebinin göreli önemini ve aciliyetini belirleyen sınıflandırmadır. Genellikle etki ve aciliyetin birlikte değerlendirilmesiyle belirlenir ve temsilcilerin hangi talepleri önce ele alacağını yönlendirmek 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 gereklidir. Kritik talepler için SLA hedeflerine ulaşılıp ulaşılmadığını görmek üzere Dashboardları filtrelemenizi ve önceliklendirme sisteminin etkili olup olmadığını belirlemenizi sağlar.
Neden önemli?
Talepleri segmentlere ayırarak yüksek öncelikli öğelerin daha hızlı işlenip işlenmediğini doğrulamanızı sağlar. SLA analizi ve kaynak tahsisi için temel bir özniteliktir.
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
|
|||
|
SLA karşılandı
MadeSLA
|
Hizmet talebinin Hizmet Seviyesi Anlaşması içinde çözümlenip çözümlenmediğini gösteren boolean işareti. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin çözüm süresi için tanımlanan Hizmet Seviyesi Anlaşmasını (SLA) karşılayıp karşılamadığını gösterir. Hizmet performansını taahhütlere göre doğrudan ölçen önemli bir sonuç metriğidir. Bu işareti analiz etmek, SLA Uyumluluk Oranı KPI'ını ölçmenize yardımcı olur. Uyumluluk gösteren talepler ile SLA ihlali yaşanan taleplerin süreç yollarını karşılaştırmak için boyut olarak kullanılabilir. Böylece SLA başarısızlıklarına katkıda bulunan yaygın örüntüler veya etkinlikler ortaya çıkarılabilir. Bu, proaktif risk izleme ve sürekli hizmet iyileştirmesi için gereklidir.
Neden önemli?
Hizmet taahhütlerine göre performansı doğrudan ölçer ve uyumlu vakalarla uyumsuz vakaları karşılaştırarak SLA ihlallerinin kök neden analizini yapmanızı sağlar.
Nereden alınır?
ServiceNow Task SLA [task_sla] tablosu, 'has_breached' alanı. Değerin tersine çevrilmesi gerekir, örneğin MadeSLA = NOT has_breached.
Örnekler
truefalse
|
|||
|
Açan kişi
OpenedBy
|
Hizmet talebini ilk gönderen kişi. | ||
|
Açıklama
Bu öznitelik, hizmet talebini oluşturan kullanıcıyı tanımlar. Kullanıcı çoğu zaman talepten etkilenen kişiyle aynı olsa da yönetici, vekil veya otomatik sistem de olabilir. Talepleri 'Opened By' kullanıcısına veya kullanıcının departmanına göre analiz etmek, karmaşık ya da sorunlu talepleri sık gönderen belirli kullanıcı grupları gibi örüntüleri belirlemeye yardımcı olur. Bu bilgiler hedefli eğitimler planlamak veya self-service kullanımını artıracak daha iyi bilgi bankası makalelerine duyulan ihtiyacı ortaya çıkarmak için kullanılabilir.
Neden önemli?
Talepleri kullanıcı, departman veya role göre analiz etmeye yardımcı olur. Eğitim girişimlerine ve hedefli süreç iyileştirmelerine yön verebilir.
Nereden alınır?
ServiceNow Request [sc_request] tablosu, 'opened_by' alanı.
Örnekler
Abel TuterFred LuddyDon Goodliffe
|
|||
|
Bitiş zamanı
EndTime
|
Bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
Açıklama
End Time, bir etkinliğin sona erdiği zamanı gösterir. Sıradaki etkinliğin zaman damgasıdır ve mevcut etkinliğin süresini tamamlar. Her adımın ne kadar sürdüğünü hesaplamak için gereklidir. Bir etkinliğin Start Time ve End Time değerleri karşılaştırılarak işleme ve bekleme süreleri hesaplanabilir. Bu, darboğazları belirlemek, kaynak verimliliğini ölçmek ve performansı zamana dayalı hedeflere göre izlemek için temel oluşturur.
Neden önemli?
Her etkinliğin süresini hesaplamak için gereklidir. Bu süre, performans analizinin, darboğaz belirlemenin ve kaynak kullanım çalışmalarının temel bileşenidir.
Nereden alınır?
Türetilmiş bir özniteliktir ve vakadaki sonraki olayın 'StartTime' değeri alınarak hesaplanır.
Örnekler
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Çözüm kodu
ResolutionCode
|
Hizmet talebinin nihai çözümünü kategorilere ayıran kod. | ||
|
Açıklama
Resolution Code, bir hizmet talebinin nihai olarak nasıl çözümlendiğini yapılandırılmış biçimde sınıflandırır. Örnekler arasında 'Fulfilled by Automation', 'User Error' veya 'No Longer Required' bulunur. Bu öznitelik, Delays için Kök Neden Analizi Dashboard açısından büyük önem taşır. Çözüm kodlarını uzun çevrim süreleri veya yüksek yeniden çalışma oranlarıyla ilişkilendirerek sistemik sorunları belirleyebilirsiniz. Örneğin 'Incomplete Information' koduna sahip talepler sürekli olarak yavaş ilerliyorsa bu durum, ilk veri toplama adımında bir sorun olduğunu gösterir.
Neden önemli?
Çözüm sonuçları hakkında yapılandırılmış veri sağlar. Süreç gecikmelerinin, yeniden çalışmanın ve diğer verimsizliklerin kök neden analizini mümkün kılar.
Nereden alınır?
ServiceNow Request Item [sc_req_item] veya ilişkili bir görev tablosu, alan adı genellikle 'close_code' veya 'resolution_code' olur.
Örnekler
Kalıcı olarak çözüldüÇözülmedi, yeniden oluşturulamıyorTalep karşılandıKullanıcı tarafından iptal edildi
|
|||
|
İlk seferde çözüm mü
IsFirstPassResolution
|
Talebin yeniden açılmadan ilk denemede çözümlenip çözümlenmediğini gösteren işaret. | ||
|
Açıklama
Bu hesaplanmış öznitelik, hizmet talebi hiç yeniden açılmadan çözümlenip kapatılmışsa 'true' değerini alır. Hizmet masasının sunduğu çözümün kalitesini ve etkililiğini gösteren temel bir göstergedir. Bu metrik, First-Pass Resolution Rate KPI'ını doğrudan destekler. Yüksek oran istenir; çünkü verimliliğe ve yüksek hizmet kalitesine, dolayısıyla daha iyi müşteri memnuniyetine işaret eder. İlk seferde çözülemeyen vakaların özniteliklerini analiz etmek, yetersiz eğitim, zayıf dokümantasyon veya hatalı ilk teşhis gibi kök nedenleri ortaya çıkarabilir.
Neden önemli?
Çözüm sürecinin kalitesini ve verimliliğini ölçer. İlk seferde çözüm oranının düşük olması, yeniden çalışmaya ve müşteri memnuniyetsizliğine yol açan temel sorunlara işaret eder.
Nereden alınır?
Vaka düzeyinde hesaplanır. 'ReopenCount' değeri sıfır olan vaka ilk seferde çözülmüş kabul edilir.
Örnekler
truefalse
|
|||
|
Kanal
ContactType
|
Talep sahibinin hizmet talebini göndermek için kullandığı yöntem. | ||
|
Açıklama
Contact Type 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ç farklılıklarını analiz etmek için önemlidir. Örneğin portal üzerinden gönderilen talepler daha yapılandırılmış ve otomatik olabilir. Bu nedenle e-posta ile gönderilen taleplere kıyasla daha hızlı işlenebilir. Bu analiz, daha verimli kanalların yaygınlaştırılmasına yardımcı olur.
Neden önemli?
Farklı gönderim kanallarının süreç verimliliğini, otomasyon düzeyini ve genel çevrim sürelerini nasıl etkilediğini belirlemeye yardımcı olur. Böylece kullanıcı etkileşimlerini iyileştirme çalışmalarına yön verir.
Nereden alınır?
ServiceNow Request [sc_request] veya Interaction [interaction] tabloları. Alanın adı genellikle 'contact_type' olur.
Örnekler
PortalE-postaTelefonKendi kendine hizmet
|
|||
|
Memnuniyet puanı
SatisfactionScore
|
Talep sahibinin talep kapatılırken verdiği müşteri memnuniyeti puanı. | ||
|
Açıklama
Bu öznitelik, son kullanıcının hizmet talebi çözüldükten sonra genellikle 1-5 aralığında verdiği memnuniyet puanını kaydeder. Hizmet kalitesinin algılanan düzeyini doğrudan ölçer. Bu veri, Müşteri Memnuniyeti Etki Analizi Dashboard için gereklidir. Çevrim süresi, yeniden çalışma ve devirler gibi süreç metrikleriyle nihai müşteri deneyimi arasında doğrudan ilişki kurmanızı sağlar. Böylece operasyonel verimlilik ile müşteri sonuçlarını ilişkilendirerek süreç iyileştirmeleri için iş gerekçesini destekler.
Neden önemli?
Süreç performansı metriklerini müşteri sonuçlarıyla doğrudan ilişkilendirir ve süreç verimsizliklerinin kullanıcı deneyimine etkisini ölçmeye yardımcı olur.
Nereden alınır?
Genellikle özgün taleple ilişkilendirilmiş Survey [asmt_assessment_instance] tablosunda bulunur.
Örnekler
5431
|
|||
|
Otomatik mi
IsAutomated
|
Bir etkinliğin sistem veya otomasyon tarafından gerçekleştirilip gerçekleştirilmediğini gösteren işaret. | ||
|
Açıklama
Bu boolean öznitelik, bir insan görevli tarafından manuel olarak gerçekleştirilen etkinliklerle Workflow veya entegrasyon gibi otomatik bir sistem tarafından yürütülen etkinlikleri birbirinden ayırır. Örneğin 'Approval Requested' otomatik, 'Request Assigned to Agent' ise manuel olabilir. Bu özniteliği analiz etmek, hizmet talebi sürecindeki otomasyon düzeyini ölçmek ve artırmak için önemlidir. En çok zaman alan manuel görevleri belirlemenize ve bunların gelecekte otomatikleştirilebilecek adaylar olup olmadığını değerlendirmenize yardımcı olur. Böylece verimlilik artar ve maliyetler azalır.
Neden önemli?
Otomasyon oranlarını ölçmenizi ve manuel görevleri otomatikleştirme fırsatlarını belirlemenizi sağlar. Bu da verimliliği artırır ve operasyonel maliyetleri azaltır.
Nereden alınır?
Bir işlemi gerçekleştiren kullanıcının, örneğin 'sys_updated_by' değerinin, tanımlanmış bir sistem veya entegrasyon kullanıcısı olup olmadığı kontrol edilerek türetilir.
Örnekler
truefalse
|
|||
|
Vaka çevrim süresi
CaseCycleTime
|
Bir hizmet talebinin oluşturulmasından nihai olarak kapatılmasına kadar geçen toplam süre. | ||
|
Açıklama
Vaka çevrim süresi, bir hizmet talebinin toplam süresini ölçen hesaplanmış bir metriktir. Bu süre, ilk olayın zaman damgasından son olayın zaman damgasına kadar ölçülür. Müşteri açısından uçtan uca işlem süresinin tamamını gösterir. Bu metrik, genel süreç verimliliği için temel performans göstergelerinden biridir. Üst düzey Dashboardlarda hedeflere göre performansı izlemek ve zaman içindeki eğilimleri analiz etmek için kullanılır. En uzun süren talep türlerini belirlemek üzere Kategori veya Öncelik gibi boyutlara göre ayrıştırılabilir.
Neden önemli?
Uçtan uca süreç performansını ölçen önemli bir KPI'dır. Üst düzey izleme, kıyaslama ve iyileştirme alanlarını belirleme için gereklidir.
Nereden alınır?
Her benzersiz 'ServiceRequestID' için minimum 'StartTime' değerinden maksimum 'EndTime' değeri çı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ığını gösteren sayı. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebinin çözüldü veya kapalı durumdan yeniden açık ya da devam ediyor durumuna kaç kez alındığını sayar. Sıfırdan büyük bir değer, ilk çözümün başarılı olmadığını gösterir. Bu metrik, yeniden çalışmanın doğrudan göstergesidir ve First-Pass Resolution Rate KPI'ının temel bileşenlerinden biridir. Yüksek yeniden açılma sayıları, çözüm kalitesiyle ilgili sorunlara, eksik yerine getirmeye veya kullanıcı ihtiyaçlarının yanlış anlaşılmasına işaret eder. Bunların tümü süreç verimsizliğine ve kullanıcı memnuniyetsizliğine yol açar.
Neden önemli?
Yeniden çalışmayı ve çözüm kalitesini ölçer. Yüksek yeniden açılma sayısı verimsizliklere, ilk seferde çözüm oranının düşük olmasına ve müşteri memnuniyetinin azalmasına işaret eder.
Nereden alınır?
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tabloları, 'reopen_count' alanı.
Örnekler
012
|
|||
|
Yeniden çalışma mı
IsRework
|
Bir etkinliğin aynı vakadaki önceki bir etkinliğin tekrarı olup olmadığını gösteren hesaplanmış işaret. | ||
|
Açıklama
Bu boolean işaret, bir hizmet talebindeki yeniden çalışma döngülerini belirlemek için hesaplanır. Aynı etkinlik aynı vakada daha önce gerçekleşmişse 'true' olarak işaretlenir. Örneğin bir talep aynı ekibe iki kez atanmışsa veya kullanıcıdan birden fazla kez bilgi istenmişse bu durum geçerlidir. Bu öznitelik, Agent Handoffs and Rework Incidents Dashboard ve Request Rework Rate KPI için gereklidir. Toplu verilerde çoğu zaman gizli kalan verimsiz döngüleri doğrudan görselleştirmenizi ve ölçmenizi sağlar.
Neden önemli?
Süreçteki yeniden çalışmayı doğrudan işaretler ve ölçer. Böylece maliyetleri ve çevrim sürelerini artıran verimsiz döngülerin nedenlerini ve etkilerini analiz edebilirsiniz.
Nereden alınır?
Veri dönüştürme sırasında aynı etkinlik adının aynı vaka içindeki önceki oluşumları kontrol edilerek hesaplanır.
Örnekler
falsetrue
|
|||
Hizmet Talebi Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi çözüldü
|
Bu etkinlik, yerine getirme görevlisinin çalışmayı tamamladığını ve bir çözüm sunduğunu gösterir. Talebin durumu 'Resolved' veya benzer bir duruma güncellendiğinde kaydedilir. | ||
|
Neden önemli?
Bu, genellikle SLA süresini durduran önemli bir kilometre taşıdır. Aktif yerine getirme çalışmasının sona erdiğini gösterir ve toplam çözüm süresi hesaplamasının temel bileşenlerinden biridir.
Nereden alınır?
Kapatılmadan önce sc_req_item durum alanının 'Resolved' veya benzer bir son duruma güncellenmesinden anlaşılır. Değişiklik sys_audit tablosunda izlenir.
Yakalayın
sc_req_item.state alanının 'Resolved' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Hizmet talebi kapatıldı
|
Hizmet talebi yaşam döngüsünün nihai ve kesin olarak sona erdiğini gösterir. Bu durum genellikle talebin 'Resolved' durumunda belirli bir süre kalmasının ardından otomatik olarak gerçekleşir. Bu süre içinde kullanıcı talebi yeniden açabilir. | ||
|
Neden önemli?
Bu, sürecin başarılı şekilde sona erdiğini gösteren temel olaydır. 'Resolved' ile 'Closed' arasındaki süre de otomatik kapatma politikalarını anlamak için analiz edilebilir.
Nereden alınır?
sc_req_item durum alanının 'Closed Complete' gibi nihai bir kapalı duruma güncellenmesinden anlaşılır. Bu değişiklik sys_audit tablosunda kaydedilir.
Yakalayın
sc_req_item.state alanının 'Closed Complete' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Hizmet talebi oluşturuldu
|
Bu faaliyet, kullanıcının hizmet kataloğu üzerinden talep göndermesiyle kaydedilen hizmet talebi yaşam döngüsünün başlangıcını gösterir. Sistem bunu sc_req_item (Requested Item) tablosunda yeni bir kaydın oluşturulması olarak yakalar. | ||
|
Neden önemli?
Bu, sürecin birincil başlangıç olayıdır. Toplam çevrim süresini hesaplamak ve talep hacimleri ile gönderim örüntülerini analiz etmek için gereklidir.
Nereden alınır?
Bu, sc_req_item tablosundaki kaydın oluşturma zaman damgasından (sys_created_on alanı) yakalanan açık bir olaydır.
Yakalayın
sc_req_item kaydındaki sys_created_on zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Kullanıcıdan bilgi istendi
|
Karşılama temsilcisinin devam edebilmek için ilk talep sahibinden daha fazla bilgiye ihtiyaç duyduğu zaman gerçekleşir. Bu durum genellikle talebin durumunun 'Awaiting User Info' gibi bir değere değişmesinden çıkarılır. | ||
|
Neden önemli?
Bu etkinlik, kullanıcıdan gelecek harici girdiyi beklerken kaybedilen zamanı ölçmeye yardımcı olan "Talep Sahibi Bilgisi Gecikme Analizi" Dashboardu için önemlidir.
Nereden alınır?
sc_req_item state alanının belirlenmiş bir 'awaiting information' durumuna değişmesinden çıkarılır. Değişiklik sys_audit tablosuna kaydedilir.
Yakalayın
sc_req_item.state alanının 'Awaiting User Info' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep onaylandı
|
Talebin resmi olarak onaylandığını ve karşılanma aşamasına geçebileceğini gösterir. Onay mercii ilgili onay kaydını 'approved' olarak işaretlediğinde yakalanır. | ||
|
Neden önemli?
Bu önemli kilometre taşı, onay aşamasından karşılanma aşamasına geçişi gösterir. Bu adıma ulaşmak için geçen süreyi analiz etmek, karşılanma öncesi gecikmeleri anlamak için gereklidir.
Nereden alınır?
İlgili sysapproval_approver kaydındaki state alanının 'approved' değerine değişmesinden çıkarılır. Bu değişiklik daha sonra sc_req_item üzerinde bir durum değişikliğini tetikler.
Yakalayın
sysapproval_approver.state alanının 'approved' değerine dönüştüğü zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep temsilciye atandı
|
Belirli bir temsilcinin hizmet talebi üzerinde çalışmak üzere atandığı zaman gerçekleşir. Talep veya karşılanma görevlerindeki 'Assigned to' alanında yapılan değişiklikler izlenerek yakalanır. | ||
|
Neden önemli?
Devirleri ölçmek, temsilciye özel iş yüklerini hesaplamak ve bir kişinin talep üzerinde çalışmaya başlamasından önceki kuyruk sürelerini analiz etmek için gereklidir.
Nereden alınır?
sc_req_item veya sc_task tablosundaki assigned_to alanında gerçekleşen değişiklikten çıkarılır. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Yakalayın
sys_audit içindeki assigned_to alanı değişikliklerini izleyin.
Olay türü
inferred
|
|||
|
Harici tedarikçi devreye alındı
|
Bir hizmet talebinin veya talebe ait görevlerden birinin yerine getirilmesi için harici bir üçüncü taraf tedarikçiye devredilmesini ifade eder. Bu durum, talebin tedarikçiye özel bir gruba atanmasından veya talep üzerindeki bir işaretten anlaşılabilir. | ||
|
Neden önemli?
Bu etkinlik, tedarikçi performansını ve bunun genel talep yaşam döngüsüne etkisini analiz etmenizi sağlar. Bu analiz, 'External Vendor Engagement Cycle' Dashboard için büyük önem taşır.
Nereden alınır?
Bu bilgi genellikle çıkarım yoluyla elde edilir. assignment_group alanının bir tedarikçi grubuna atanmasına veya sc_req_item ya da sc_task kaydında belirli bir işaret alanının ayarlanmasına dayanabilir.
Yakalayın
assignment_group alanının bilinen bir tedarikçi grubuna değiştiğini belirleyin.
Olay türü
inferred
|
|||
|
Karşılama görevi oluşturuldu
|
Hizmet talebini karşılamak için gereken belirli bir iş öğesinin veya görevin oluşturulmasını gösterir. Bu, Catalog Task tablosunda yeni bir kayıt oluşturulduğunda kaydedilen açık bir olaydır. | ||
|
Neden önemli?
Karmaşık taleplerde, tek tek görevlerin oluşturulmasını ve tamamlanmasını analiz etmek, karşılanma sürecine ve gecikmelerin oluştuğu noktalara ilişkin daha ayrıntılı bir görünüm sunar.
Nereden alınır?
Bu, sc_req_item ile bağlantılı sc_task tablosundaki bir kaydın oluşturma zaman damgasından (sys_created_on alanı) yakalanan açık bir olaydır.
Yakalayın
sc_task kayıtlarındaki sys_created_on zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Kullanıcı bilgi sağladı
|
Talep sahibinin gerekli bilgileri sağladığı noktayı gösterir. Talebin 'Awaiting User Info' durumundan çıkarak 'Work in Progress' gibi etkin bir duruma dönmesiyle çıkarılır. | ||
|
Neden önemli?
'Kullanıcıdan bilgi istendi' faaliyetiyle birlikte kullanıldığında, kullanıcı kaynaklı gecikmelerin hassas biçimde ölçülmesini ve iletişim sürecinin verimliliğinin değerlendirilmesini sağlar.
Nereden alınır?
sc_req_item state alanının 'awaiting information' durumundan etkin bir duruma değişmesinden çıkarılır. Bu değişiklik çoğu zaman kullanıcının yorum eklemesi veya e-postaya yanıt vermesiyle tetiklenir.
Yakalayın
Durumun 'Awaiting User Info' değerinden 'Work in Progress' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Onay istendi
|
Bir hizmet talebinin yöneticiye veya belirlenmiş başka bir onay merciine onay için gönderildiği noktayı gösterir. Bu durum genellikle talebin durumunun 'Pending Approval' veya benzer bir değere değişmesinden çıkarılır. | ||
|
Neden önemli?
Onayları izlemek, onay sürecindeki darboğazları belirlemeye ve taleplerin karşılanmaya 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 bekleyen onay değerine değişmesinden veya sysapproval_approver tablosunda ilgili bir kaydın oluşturulmasından çıkarılır. Değişiklikler sys_audit tablosuna kaydedilir.
Yakalayın
sc_req_item.state alanının 'Pending Approval' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep grubuna atandı
|
Hizmet talebinin belirli bir karşılanma ekibine veya grubuna atandığını gösterir. Bu olay, talep öğesindeki veya ilişkili görevlerdeki atama grubu alanında gerçekleşen değişiklik belirlenerek çıkarılır. | ||
|
Neden önemli?
Grup atamalarını izlemek, ekipler arasındaki iş yükü dağılımını analiz etmeye ve talep doğru karşılayıcılara yönlendirilmeden önceki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır?
sc_req_item veya sc_task tablosundaki assignment_group alanında gerçekleşen değişiklikten çıkarılır. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Yakalayın
sys_audit içindeki assignment_group alanı değişikliklerini izleyin.
Olay türü
inferred
|
|||
|
Talep iptal edildi
|
Bu etkinlik, tamamlanmadan önce kullanıcı veya görevli tarafından iptal edilen talepler için son durumu ifade eder. Talep durumu 'Cancelled' veya 'Closed Cancelled' olarak ayarlandığında kaydedilir. | ||
|
Neden önemli?
Bu, başarısız bir sürecin sona erdiğini gösteren önemli bir 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ü sağlayabilir.
Nereden alınır?
sc_req_item durum alanının 'Closed Cancelled' gibi nihai bir iptal durumuna güncellenmesinden anlaşılır. Değişiklik sys_audit tablosunda kaydedilir.
Yakalayın
sc_req_item.state alanının 'Cancelled' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep reddedildi
|
Bu etkinlik, onay aşamasında bir talebin resmi olarak reddedilmesini ifade eder. Kapatmaya giden alternatif bir yoldur ve onaylayan kişi talebi 'rejected' olarak işaretlediğinde kaydedilir. | ||
|
Neden önemli?
Reddedilen talepleri izlemek, geçersiz veya yanlış yönlendirilmiş talepleri ve talep gönderme sürecindeki sorunları belirlemeye yardımcı olur. Ayrıca analiz için önemli bir istisna yolu sunar.
Nereden alınır?
İlgili sysapproval_approver kaydının state alanının 'rejected' değerine değişmesinden anlaşılır. Bu durum genellikle üst sc_req_item kaydını kapalı ve tamamlanmamış duruma getirir.
Yakalayın
sysapproval_approver.state alanının 'rejected' değerine dönüştüğü zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep yeniden açıldı
|
Bu etkinlik, daha önce çözüldü olarak işaretlenen bir talebin yeniden açık duruma alınmasını kaydeder. Bu durum, 'Resolved' değerinden 'Work in Progress' değerine veya benzer bir duruma geçişten anlaşılır. | ||
|
Neden önemli?
Bu, yeniden çalışmayı doğrudan ölçer ve 'First-Pass Resolution Rate' KPI hesaplaması için önemlidir. Yüksek değerler, çözüm kalitesinin düşük veya çözümün eksik olduğunu gösterir.
Nereden alınır?
sc_req_item durum alanının çözüldü ya da kapatıldı durumundan yeniden açık veya devam ediyor durumuna geçmesiyle anlaşılır. Bu değişiklik sys_audit içinde kaydedilir.
Yakalayın
sys_audit içinde durumun 'Resolved' değerinden 'Work in Progress' değerine değiştiğini tespit edin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Process Mining girişiminizi başlatmak ve hizmet talebi yönetiminizde önemli verimlilik kazanımları elde etmek için bu şablondan yararlanın. Daha hızlı çözüm ve daha yüksek müşteri memnuniyeti için iş akışlarınızı bugün optimize etmeye başlayın.
Hizmet talebi yönetimini dönüştürün: Şimdi harekete geçin
Hizmet taleplerinde %70 otomasyon ve daha hızlı çözüm elde edin.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.