Hizmet Talebi Yönetimi Veri Templateiniz
Hizmet Talebi Yönetimi Veri Templateiniz
- Toplanması önerilen öznitelikler
- Süreç keşfi için izlenecek temel etkinlikler
- Adım adım veri çıkarma kılavuzu
Hizmet talebi yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Hizmet talebi yaşam döngüsünde gerçekleşen belirli olayın veya görevin adı. | ||
|
Açıklama
Aktivite özniteliği, hizmet talebi sürecindeki her adımın veya durum değişikliğinin adını kaydeder. 'Talep oluşturuldu', 'Talep onaylandı', 'Temsilciye atandı' veya 'Talep kapatıldı' gibi olayları içerebilir. Bu etkinlikleri analiz ederek süreç akışını görselleştirebilir, sık izlenen yolları belirleyebilir ve standart prosedürden sapmaları tespit edebilirsiniz. Talebin yerine getirilmesi sırasında gerçekte neler olduğunu anlamanın temelini oluşturur.
Neden önemli?
Bu zorunlu öznitelik, süreç haritasındaki adımları tanımlar. Darboğazları, yeniden çalışma döngülerini ve uyumluluk sorunlarını keşfetmek dahil tüm süreç analizlerinin temelidir.
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) elde edilir.
Örnekler
Hizmet talebi oluşturulduTalep gruba atandıHizmet talebi çözüldüKullanıcıdan bilgi istendi
|
|||
|
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 gereken olay sıralamasını sağlar. Çevrim sürelerini, bekleme sürelerini ve işlem sürelerini hesaplamak için doğru zaman damgaları gerekir. Bu veriler darboğazları, SLA ihlallerini ve performansın zaman içindeki eğilimlerini belirlemeyi sağlar.
Neden önemli?
Olayları doğru sıraya koymak için bu zaman damgası zorunludur. Çevrim süresi ve darboğaz tespiti 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
|
|||
|
Hizmet talebi kimliği
ServiceRequestID
|
Her hizmet talebi kaydını benzersiz biçimde tanımlayan kimlik. | ||
|
Açıklama
Hizmet talebi kimliği, bir kullanıcı veya sistem tarafından gönderilen her hizmet talebini benzersiz biçimde tanımlayan birincil anahtardır. İlk kayıttan nihai kapanışa kadar sonraki tüm olayları birbirine bağlar. Process Mining için bu kimlik, her talebin uçtan uca yolculuğunu yeniden oluşturmayı ve yaşam döngüsünü bütünüyle analiz etmeyi sağlar.
Neden önemli?
Bu, zorunlu Vaka kimliğidir. İlgili tüm etkinlikleri tek bir süreç örneğinde birleştirerek süreç akışlarının, farklılıkların ve çevrim sürelerinin analiz edilmesini sağlar.
Nereden alınır?
ServiceNow Request [sc_request] tablosundaki 'number' alanı.
Örnekler
REQ0010001REQ0010025REQ0010112
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin alındığı sistem. | ||
|
Açıklama
Bu öznitelik, bu örnekte ServiceNow olan veri kaynağı sistemi tanımlar. Bütünsel bir süreç görünümü elde etmek için birden fazla sistemden gelen verilerin birleştirildiği ortamlarda yararlıdır. Tek kaynaklı analizlerde bu öznitelik önemli bir bağlam sağlar, veri yönetişimi ve yönetimine yardımcı olur. Analiz edilen verinin nereden geldiğini herkesin anlamasını sağlar.
Neden önemli?
Özellikle birden fazla kurumsal sistemden gelen veriler birleştirildiğinde, veri yönetişimi, izlenebilirlik ve bağlam için gerekli üst verileri sağlar.
Nereden alınır?
Bu genellikle veri çıkarımı ve dönüştürme sırasında eklenen statik bir değerdir.
Örnekler
ServiceNow
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
En son veri yenileme veya çıkarımının zaman damgası. | ||
|
Açıklama
Bu öznitelik, verinin kaynak sistemden en son ne zaman çıkarılıp Process Mining aracına yüklendiğini gösterir. Analiz edilen verinin güncelliği konusunda şeffaflık sağlar. Analistler bu bilgiyi, en güncel verilerle çalışıp çalışmadıklarını anlamak için kullanır. Bu, operasyonel izleme ve zamanında karar alma açısından önemlidir. Bulguların ne kadar güncel olduğuna ilişkin beklentileri belirlemeye yardımcı olur.
Neden önemli?
Kullanıcıların verinin güncelliğini bilmesini sağlar. Bu, analize güvenmek ve veriye dayalı kararları zamanında almak için önemlidir.
Nereden alınır?
Bu, veri alımı sırasında eklenen ve ETL işinin tamamlandığı zaman damgasını yansıtan bir üst veri alanıdır.
Örnekler
2023-10-27T04:00:00Z
|
|||
|
Atama grubu
AssignmentGroup
|
Hizmet talebini ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Atama grubu, hizmet talebinden belirli bir aşamada sorumlu olan 'Hizmet Masası', 'Ağ Operasyonları' veya 'Veritabanı Yönetimi' gibi ekibi temsil eder. Farklı işlev alanları arasındaki süreç akışını analiz etmek için önemli bir özniteliktir. Kuruluşlar, atama grubundaki değişiklikleri izleyerek ekipler arasındaki devir teslimleri görselleştirebilir, her grubun iş kuyruğundaki bekleme sürelerini ölçebilir ve ekipler arası bağımlılıkları veya gecikmeleri belirleyebilir. Bu, işlevler arası iş birliğini iyileştirmek açısından önemlidir.
Neden önemli?
Ekipler arasındaki iş dağılımını izler, ekipler arası devir teslimleri 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ındaki 'assignment_group' alanı.
Örnekler
Hizmet MasasıBT desteği L2Donanım tedariki
|
|||
|
Atanan kişi
AssignedTo
|
Belirli bir zamanda hizmet talebi üzerinde çalışmaktan sorumlu kullanıcı. | ||
|
Açıklama
Bu öznitelik, hizmet talebine atanan temsilciyi 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ı, kişisel performansı ve devir teslimlerin çözüm sürelerine etkisini anlamak açısından önemlidir. Kaynak kullanımına ilişkin soruları yanıtlamaya, yeniden atamaları azaltmak için eğitim veya süreç açıklığı gereken alanları belirlemeye yardımcı olur.
Neden önemli?
Temsilci iş yükünü, performansını ve devir teslimleri analiz etmeyi 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ındaki 'assigned_to' alanı.
Örnekler
Beth AnglinDavid LooHoward Johnson
|
|||
|
Durum
State
|
Hizmet talebinin mevcut operasyonel durumu. | ||
|
Açıklama
Durum özniteliği, hizmet talebinin yaşam döngüsündeki mevcut aşamasını gösterir. Örneğin 'Open', 'Work in Progress', 'Pending' veya 'Closed' olabilir. Bu alandaki değişiklikler genellikle süreç haritasındaki etkinlikleri oluşturmak için kullanılır. Taleplerin belirli durumlarda, özellikle bekleme durumlarında ne kadar zaman geçirdiğini anlamak için durumu analiz etmek önemlidir. Sıkça çevrim sürelerinin uzamasına yol açan 'Awaiting User Information' gibi durumlarda geçen süre dahil, kuyrukları ve gecikmeleri belirlemeye yardımcı olur.
Neden önemli?
Talebin herhangi bir andaki durumunu göstererek bekleme sürelerinin, kuyrukların ve belirli süreç aşamalarının süresinin analiz edilmesini sağlar.
Nereden alınır?
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tablolarındaki 'state' ya da 'stage' alanı.
Örnekler
AçıkDevam EdiyorKullanıcı Bilgisi BekleniyorTamamlandı ve Kapatıldı
|
|||
|
Kategori
Category
|
Hizmet talebinin Donanım veya Yazılım gibi ana sınıflandırması. | ||
|
Açıklama
Kategori, 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 çalışmalarında Kategori, filtreleme ve boyut bazlı analiz için etkili bir araçtır. Analistlerin farklı talep türlerine ait süreç akışlarını, çevrim sürelerini ve otomasyon oranlarını karşılaştırmasına yardımcı olur. Böylece toplu verilerde görünmeyen farklılıklar ortaya çıkar. Örneğin, Donanım talebinin işleyişi Yazılım talebininkinden temelden farklı olabilir.
Neden önemli?
Farklı hizmet türlerine ait süreçleri segmentlere ayırıp karşılaştırmanızı sağlar. Böylece kategoriye özgü sorunları ve iyileştirme fırsatlarını belirleyebilirsiniz.
Nereden alınır?
ServiceNow Request Item [sc_req_item] tablosu; genellikle ilişkili Catalog Item [sc_cat_item] kaydının kategorisi kullanılır.
Örnekler
DonanımYazılımErişim TalebiAğ
|
|||
|
Öncelik
Priority
|
Hizmet talebinin aciliyetini etkileyen öncelik düzeyi. | ||
|
Açıklama
Öncelik, hizmet talebinin göreli önemini ve aciliyetini belirleyen bir sınıflandırmadır. Genellikle etki ve aciliyet birlikte değerlendirilerek belirlenir ve temsilcilere hangi talepleri önce ele almaları gerektiğini gösterir. Önceliğe göre veri analizi yapmak, yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı işlenip işlenmediğini anlamak için önemlidir. Kritik taleplerde SLA’lara uyulup uyulmadığını görmek üzere Dashboardları filtrelemeyi ve önceliklendirme sisteminin etkili olup olmadığını belirlemeyi sağlar.
Neden önemli?
Yüksek öncelikli öğelerin daha hızlı işlenip işlenmediğini doğrulamak için talepleri gruplandırmayı sağlar. SLA analizi ve kaynak tahsisi açısından önemlidir.
Nereden alınır?
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tablolarındaki 'priority' alanı.
Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
|
|||
|
SLA Karşılandı
MadeSLA
|
Hizmet talebinin Hizmet Seviyesi Anlaşması kapsamında çözüldüğünü belirten bir boole değeri. | ||
|
Açıklama
Bu öznitelik, hizmet talebinin çözüm süresi için belirlenen Hizmet Seviyesi Anlaşmasını (SLA) karşılayıp karşılamadığını gösterir. Taahhütlere göre hizmet performansını doğrudan ölçen önemli bir sonuç metriğidir. Bu değeri analiz ederek SLA Uyumluluk Oranı KPI’ını hesaplayabilirsiniz. Uyumlu taleplerin süreç yollarını SLA ihlali olan taleplerle karşılaştırmak için bir boyut olarak kullanıldığında, ihlallere yol açan yaygın örüntüleri ve etkinlikleri ortaya çıkarır. Bu analiz, riskleri önceden izlemek ve hizmeti sürekli iyileştirmek için gereklidir.
Neden önemli?
Hizmet taahhütlerine göre performansı doğrudan ölçer. Uyumlu ve uyumsuz vakaları karşılaştırarak SLA ihlallerinin temel nedenlerini incelemenizi sağlar.
Nereden alınır?
ServiceNow Task SLA [task_sla] tablosundaki 'has_breached' alanı. Değerin tersine çevrilmesi gerekir (ör. 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ı belirtir. Talebin etkilediği kişi çoğu zaman talebi açan kişiyle aynı olsa da talebi bir yönetici, temsilci veya otomatik sistem de oluşturabilir. Talepleri 'Açan Kişi’ye veya bu kişinin departmanına göre analiz ederek karmaşık ya da sorunlu talepleri sıkça gönderen kullanıcı grupları gibi örüntüleri belirleyebilirsiniz. Bu bulgular, hedefli eğitimler planlamanıza veya self servis kullanımını teşvik edecek bilgi bankası içeriklerine duyulan ihtiyacı görmenize yardımcı olur.
Neden önemli?
Talepleri kullanıcıya, departmana veya role göre incelemenize yardımcı olur. Bu analiz, eğitim çalışmalarına ve hedefli süreç iyileştirmelerine yön verebilir.
Nereden alınır?
ServiceNow Request [sc_request] tablosundaki '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
Bitiş zamanı, bir etkinliğin sona erdiği anı gösterir. Sıradaki etkinliğin zaman damgasıdır ve mevcut etkinliğin süresini belirler. Her süreç adımının ne kadar sürdüğünü hesaplamak için gereklidir. Analistler, bir etkinliğin başlangıç ve bitiş zamanlarını karşılaştırarak işlem ve bekleme sürelerini hesaplayabilir. Bu, darboğazları belirlemek, kaynak verimliliğini ölçmek ve performansı zamana bağlı hedeflere göre izlemek için temel oluşturur.
Neden önemli?
Performans analizi, darboğaz tespiti ve kaynak kullanımını incelemek için temel olan her etkinliğin süresini hesaplamak üzere bu öznitelik gereklidir.
Nereden alınır?
Bu, vakadaki sonraki olayın 'StartTime' değeri alınarak hesaplanan türetilmiş bir özniteliktir.
Örnekler
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Çözüm Kodu
ResolutionCode
|
Hizmet talebinin nihai çözümünü sınıflandıran kod. | ||
|
Açıklama
Çözüm Kodu, hizmet talebinin nasıl çözüldüğünü yapılandırılmış biçimde sınıflandırır. Örnekler arasında 'Otomasyonla Karşılandı', 'Kullanıcı Hatası' ve 'Artık Gerekli Değil' bulunur. Bu öznitelik, Gecikmelerin Temel Neden Analizi Dashboardı için büyük önem taşır. Çözüm kodlarını uzun çevrim süreleri veya yüksek yeniden çalışma oranlarıyla ilişkilendiren analistler, sistemik sorunları belirleyebilir. Örneğin, 'Eksik Bilgi' koduna sahip talepler sürekli gecikiyorsa, ilk veri toplama adımında bir sorun olduğuna işaret eder.
Neden önemli?
Çözüm sonuçlarına ilişkin yapılandırılmış veri sunarak süreç gecikmelerinin, yeniden çalışmanın ve diğer verimsizliklerin temel nedenlerini analiz etmenizi sağlar.
Nereden alınır?
ServiceNow Request Item [sc_req_item] veya ilişkili bir görev tablosu. Alanın adı genellikle 'close_code' ya da 'resolution_code' olur.
Örnekler
Kalıcı Olarak ÇözüldüÇözülmedi (Tekrarlanamıyor)Talep KarşılandıKullanıcı Tarafından İptal Edildi
|
|||
|
İlk Seferde Çözüldü mü
IsFirstPassResolution
|
Talebin yeniden açılmadan ilk denemede çözülüp çözülmediğini belirten bir değer. | ||
|
Açıklama
Bu hesaplanmış öznitelik, hizmet talebi yeniden açılmadan çözüldüyse ve kapatıldıysa 'true' değerini alan bir boole değeridir. Hizmet masasının sunduğu çözümün kalitesini ve etkililiğini gösteren temel bir metriktir. Bu metrik, İlk Seferde Çözüm Oranı KPI’ını doğrudan destekler. Oranın yüksek olması verimli ve kaliteli hizmet sunulduğunu, dolayısıyla müşteri memnuniyetinin arttığını gösterir. İlk seferde çözülemeyen vakaların özniteliklerini analiz ederek yetersiz eğitim, eksik dokümantasyon veya hatalı ilk teşhis gibi temel nedenleri ortaya çıkarabilirsiniz.
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 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üş sayılır.
Örnekler
truefalse
|
|||
|
Kanal
ContactType
|
Talep sahibinin hizmet talebini iletmek 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 araması ve otomatik uyarı bulunur. Kanal bilgisi, talebin iletilme yönteminden etkilenebilecek süreç farklılıklarını analiz etmek açısından önemlidir. Örneğin, portal üzerinden gönderilen talepler daha yapılandırılmış ve otomatik olabilir; bu da e-postayla gönderilen taleplere kıyasla işlem sürelerini kısaltabilir. Bu analiz, daha verimli kanalların kullanımını teşvik etmenize yardımcı olur.
Neden önemli?
Farklı talep kanallarının süreç verimliliğini, otomasyon düzeyini ve toplam çevrim sürelerini nasıl etkilediğini belirlemenize yardımcı olur. Böylece kullanıcı etkileşimlerini iyileştirmeye yönelik çalışmalara yön verebilirsiniz.
Nereden alınır?
ServiceNow Request [sc_request] veya Interaction [interaction] tabloları. Alanın adı genellikle 'contact_type' olur.
Örnekler
PortalE-postaTelefonSelf servis
|
|||
|
Memnuniyet Puanı
SatisfactionScore
|
Talep kapatılırken talep sahibinin verdiği müşteri memnuniyeti puanı. | ||
|
Açıklama
Bu öznitelik, hizmet talebi çözüldükten sonra son kullanıcının verdiği memnuniyet puanını kaydeder. Puan genellikle 1-5 aralığındadır ve hizmet kalitesine ilişkin algıyı doğrudan ölçer. Bu veri, Müşteri Memnuniyeti Etki Analizi Dashboardı için gereklidir. Çevrim süresi, yeniden çalışma ve devir teslim gibi süreç metriklerini müşteri deneyimiyle doğrudan ilişkilendirmenizi sağlar. Operasyonel verimlilik ile müşteri sonuçları arasındaki bağlantıyı göstererek süreç iyileştirmelerinin iş gerekçesini ortaya koyar.
Neden önemli?
Süreç performansı metriklerini müşteri sonuçlarıyla doğrudan ilişkilendirir. Böylece süreç verimsizliklerinin kullanıcı deneyimine etkisini ölçebilirsiniz.
Nereden alınır?
Genellikle ilk 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 belirten bir değer. | ||
|
Açıklama
Bu boole özniteliği, bir insan temsilcinin manuel olarak gerçekleştirdiği etkinliklerle iş akışı veya entegrasyon gibi otomatik bir sistemin yürüttüğü etkinlikleri birbirinden ayırır. Örneğin, 'Onay İstendi' otomatik olabilirken 'Talep Temsilciye Atandı' 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 gelecekte otomatikleştirilebilecek adımları görmenize yardımcı olur. Böylece verimliliği artırıp maliyetleri azaltabilirsiniz.
Neden önemli?
Otomasyon oranlarını ölçmenizi ve manuel görevleri otomatikleştirme fırsatlarını belirlemenizi sağlar. Böylece verimlilik artar, operasyonel maliyetler düşer.
Nereden alınır?
Bir işlemi gerçekleştiren kullanıcının (ör. 'sys_updated_by') belirlenmiş bir sistem veya entegrasyon kullanıcısı olup olmadığı kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
|
Vaka Çevrim Süresi
CaseCycleTime
|
Hizmet talebinin oluşturulmasından nihai olarak kapatılmasına kadar geçen toplam süre. | ||
|
Açıklama
Vaka Çevrim Süresi, hizmet talebinin ilk etkinliğinin zaman damgası ile son etkinliğinin zaman damgası arasındaki toplam süreyi ölçen hesaplanmış bir metriktir. Müşteri açısından baştan sona geçen işlem süresini gösterir. Bu metrik, genel süreç verimliliğini ölçen temel performans göstergelerinden (KPI) biridir. Hedeflere göre performansı izlemek ve zaman içindeki eğilimleri incelemek için üst düzey Dashboardlarda kullanılır. En uzun süren talep türlerini belirlemek için Kategori veya Öncelik gibi boyutlara göre ayrıştırılabilir.
Neden önemli?
Bu temel performans göstergesi (KPI), sürecin baştan sona performansını ölçer. Üst düzey izleme, kıyaslama ve iyileştirme alanlarını belirleme çalışmalarında kullanılır.
Nereden alınır?
Her benzersiz 'ServiceRequestID' için en yüksek 'EndTime' değerinden en düşük 'StartTime' değeri çıkarılarak hesaplanır.
Örnekler
2 10:30:000 04:15:2210 00:05:00
|
|||
|
Yeniden Açılma Sayısı
ReopenCount
|
Çözüldükten sonra hizmet talebinin kaç kez yeniden açıldığını gösterir. | ||
|
Açıklama
Bu sayaç, hizmet talebinin çözüldü veya kapatıldı durumundan tekrar açık ya da işlemde durumuna kaç kez döndüğünü izler. Sayının sıfırdan büyük olması, ilk çözümün başarılı olmadığını gösterir. Bu metrik, yeniden çalışmayı doğrudan gösterir ve İlk Seferde Çözüm Oranı KPI’ının temel bileşenlerinden biridir. Yeniden açılma sayısının yüksek olması; çözüm kalitesiyle ilgili sorunlara, talebin eksik karşılanmasına veya kullanıcının ihtiyaçlarının yanlış anlaşılmasına işaret edebilir. Bunların tümü süreç verimliliğini düşürür ve kullanıcı memnuniyetsizliğine yol açar.
Neden önemli?
Yeniden çalışma miktarını ve çözüm kalitesini ölçer. Yeniden açılma sayısının yüksek olması verimsizliğe, ilk seferde çözüm oranının düşüklüğüne ve müşteri memnuniyetinin azalmasına işaret eder.
Nereden alınır?
ServiceNow Request [sc_request] veya Request Item [sc_req_item] tablolarındaki 'reopen_count' alanı.
Örnekler
012
|
|||
|
Yeniden Çalışma mı
IsRework
|
Bir etkinliğin aynı vakadaki önceki bir etkinliğin tekrarı olup olmadığını belirten hesaplanmış bir değer. | ||
|
Açıklama
Bu boole değeri, hizmet talebindeki yeniden çalışma döngülerini belirlemek için hesaplanır. Aynı etkinlik aynı vakada daha önce gerçekleşmişse değer 'true' olur. Örneğin, bir talebin aynı ekibe iki kez atanması veya kullanıcıdan birden fazla kez bilgi istenmesi bu duruma örnektir. Bu öznitelik, Temsilci Devir Teslimleri ve Yeniden Çalışma Olayları Dashboardı ile Talepte Yeniden Çalışma Oranı KPI’ı için gereklidir. Toplu verilerde çoğu zaman görünmeyen verimsiz döngüleri doğrudan görselleştirip ölçmenizi sağlar.
Neden önemli?
Süreçteki yeniden çalışmayı doğrudan işaretleyip ölçer. Böylece maliyetleri ve çevrim sürelerini artıran verimsiz döngülerin nedenlerini ve etkilerini inceleyebilirsiniz.
Nereden alınır?
Veri dönüşümü sırasında aynı vaka içinde aynı etkinlik adının daha önce kullanılıp kullanılmadığı kontrol edilerek hesaplanır.
Örnekler
falsetrue
|
|||
Hizmet talebi yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Hizmet talebi çözüldü
|
Bu etkinlik, yerine getirme temsilcisinin işi tamamlayıp çözüm sunduğunu gösterir. Talebin durumu 'Resolved' veya benzer bir değere güncellendiğinde kaydedilir. | ||
|
Neden önemli?
Bu önemli kilometre taşı genellikle SLA süresini durdurur. Etkin yerine getirme çalışmalarının sonunu gösterir ve toplam çözüm süresi hesabının temel bileşenlerinden biridir.
Nereden alınır?
sc_req_item durum alanının, nihai kapanıştan önce 'Resolved' veya benzer bir son duruma güncellenmesinden çıkarımla belirlenir. Değişiklik sys_audit tablosunda izlenir.
Kaydedin
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 kesin sonunu gösterir. Bu işlem genellikle talep, kullanıcının yeniden açabileceği 'Resolved' durumunda belirli bir süre kaldıktan sonra otomatik olarak gerçekleşir. | ||
|
Neden önemli?
Bu, sürecin temel başarılı bitiş olayıdır. Otomatik kapatma politikalarını anlamak için 'Resolved' ile 'Closed' arasındaki süre de analiz edilebilir.
Nereden alınır?
sc_req_item durum alanının 'Closed Complete' gibi nihai bir kapalı duruma güncellenmesinden çıkarımla belirlenir. Bu değişiklik sys_audit tablosuna kaydedilir.
Kaydedin
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 etkinlik, hizmet talebi yaşam döngüsünün başlangıcını gösterir ve kullanıcı hizmet kataloğu üzerinden talep gönderdiğinde kaydedilir. Sistem, bunu sc_req_item (Requested Item) tablosunda yeni bir kaydın oluşturulması olayı olarak kaydeder. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Toplam çevrim süresini hesaplamak, talep hacmini ve gönderim örüntülerini analiz etmek için gereklidir.
Nereden alınır?
Bu, sc_req_item tablosundaki kaydın oluşturulma zaman damgasından (sys_created_on alanı) alınan açık bir olaydır.
Kaydedin
sc_req_item kaydındaki sys_created_on zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Kullanıcıdan bilgi istendi
|
Yerine getirme temsilcisinin ilerlemek için ilk talep sahibinden daha fazla bilgiye ihtiyaç duyduğu durumda gerçekleşir. Genellikle talebin durumu 'Awaiting User Info' gibi bir değere değiştiğinde çıkarımla belirlenir. | ||
|
Neden önemli?
Bu etkinlik, 'Talep sahibinden bilgi bekleme gecikmesi analizi' Dashboardu için önemlidir. Kullanıcıdan yanıt beklerken kaybedilen süreyi ölçmeye yardımcı olur.
Nereden alınır?
sc_req_item durum alanının belirlenmiş bir 'awaiting information' durumuna değişmesinden çıkarımla belirlenir. Değişiklik sys_audit tablosuna kaydedilir.
Kaydedin
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ı
|
Bu etkinlik, talebin resmen onaylandığını ve yerine getirme aşamasına geçebileceğini gösterir. Onaylayıcı, ilgili onay kaydını 'approved' olarak işaretlediğinde kaydedilir. | ||
|
Neden önemli?
Bu önemli kilometre taşı, onay aşamasından yerine getirme aşamasına geçişi gösterir. Bu adıma ulaşma süresini analiz etmek, yerine getirme öncesindeki gecikmeleri anlamak açısından önemlidir.
Nereden alınır?
İlgili sysapproval_approver kaydının durum alanının 'approved' değerine değişmesinden çıkarımla belirlenir. Bu değişiklik daha sonra sc_req_item durumunun değişmesini tetikler.
Kaydedin
sysapproval_approver.state alanının 'approved' olduğu zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep temsilciye atandı
|
Bu etkinlik, hizmet talebi üzerinde çalışması için belirli bir temsilci atandığında gerçekleşir. Talepteki veya yerine getirme görevlerindeki 'Assigned to' alanı değişiklikleri izlenerek kaydedilir. | ||
|
Neden önemli?
Devir teslimleri ölçmek, temsilci bazında iş yükünü hesaplamak ve bir temsilci talep üzerinde çalışmaya başlamadan önceki kuyruk sürelerini analiz etmek için önemlidir.
Nereden alınır?
sc_req_item veya sc_task tablosundaki assigned_to alanının değişmesinden çıkarımla belirlenir. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Kaydedin
sys_audit içindeki assigned_to alanı değişikliklerini izleyin.
Olay türü
inferred
|
|||
|
Harici tedarikçi sürece dahil oldu
|
Hizmet talebinin veya talebe bağlı görevlerden birinin yerine getirilmek üzere harici bir üçüncü taraf tedarikçiye devredilmesini gösterir. Tedarikçiye özel bir gruba atama yapılmasından veya talepteki bir işaretten çıkarımla belirlenebilir. | ||
|
Neden önemli?
Bu etkinlik, tedarikçi performansını ve bunun talebin genel yaşam döngüsüne etkisini analiz etmeyi sağlar. 'Harici tedarikçi katılım döngüsü' Dashboardu için önemlidir.
Nereden alınır?
Bu durum genellikle çıkarımla belirlenir. assignment_group alanının tedarikçinin grubuna ayarlanmasına veya sc_req_item ya da sc_task kaydındaki belirli bir işaret alanının ayarlanmasına dayanabilir.
Kaydedin
assignment_group alanının bilinen bir tedarikçi grubuna değiştiğini belirleyin.
Olay türü
inferred
|
|||
|
Kullanıcı bilgi sağladı
|
Bu etkinlik, talep sahibinin gerekli bilgileri sağladığı noktayı gösterir. Talep 'Awaiting User Info' durumundan 'Work in Progress' gibi etkin bir duruma geçtiğinde çıkarımla belirlenir. | ||
|
Neden önemli?
'Kullanıcıdan bilgi istendi' etkinliğiyle birlikte ele alındığı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 durum alanının 'awaiting information' durumundan etkin bir duruma değişmesinden çıkarımla belirlenir. Bu değişiklik çoğunlukla kullanıcının yorum eklemesiyle veya e-postayı yanıtlamasıyla tetiklenir.
Kaydedin
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
|
Hizmet talebinin bir yöneticiden veya başka bir yetkili onaylayıcıdan onay almak üzere gönderildiği noktayı gösterir. Bu durum genellikle talebin durumu 'Pending Approval' veya benzer bir değere değiştiğinde çıkarımla belirlenir. | ||
|
Neden önemli?
Onayları izlemek, onay sürecindeki darboğazları belirlemeye ve taleplerin yerine getirme süreci 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 bekleme değerine değişmesinden veya sysapproval_approver tablosunda ilgili bir kaydın oluşturulmasından çıkarımla belirlenir. Değişiklikler sys_audit tablosuna kaydedilir.
Kaydedin
sc_req_item.state alanının 'Pending Approval' değerine değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep gruba atandı
|
Hizmet talebinin belirli bir yerine getirme ekibine veya grubuna atandığını gösterir. Bu olay, talep öğesindeki veya ilişkili görevlerdeki atama grubu alanındaki değişiklik tespit edilerek çıkarımla belirlenir. | ||
|
Neden önemli?
Grup atamalarını izlemek, ekipler arasındaki iş yükü dağılımını analiz etmeye ve talep doğru görevlilere yönlendirilmeden önceki gecikmeleri belirlemeye yardımcı olur.
Nereden alınır?
sc_req_item veya sc_task tablosundaki assignment_group alanının değişmesinden çıkarımla belirlenir. Değişiklik geçmişi sys_audit tablosuna kaydedilir.
Kaydedin
sys_audit içindeki assignment_group alanı değişikliklerini izleyin.
Olay türü
inferred
|
|||
|
Talep iptal edildi
|
Kullanıcı veya temsilci tarafından tamamlanmadan önce iptal edilen talepler için son durumu gösterir. Talep durumu 'Cancelled' veya 'Closed Cancelled' olarak ayarlandığında kaydedilir. | ||
|
Neden önemli?
Bu, başarısızlıkla sonuçlanan önemli bir bitiş olayıdır. Taleplerin neden iptal edildiğini analiz etmek; kullanıcı ihtiyaçları, süreç verimsizlikleri veya değişen iş öncelikleri hakkında bilgi sağlayabilir.
Nereden alınır?
sc_req_item durum alanının 'Closed Cancelled' gibi nihai bir iptal durumuna güncellenmesinden çıkarımla belirlenir. Değişiklik sys_audit tablosuna kaydedilir.
Kaydedin
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 resmen reddedilmesini gösterir. Kapanışa giden alternatif bir yoldur ve onaylayıcı talebi 'rejected' olarak işaretlediğinde kaydedilir. | ||
|
Neden önemli?
Retleri izlemek, geçersiz veya yanlış yönlendirilmiş talepleri ve talep gönderme sürecindeki sorunları belirlemeye yardımcı olur. Ayrıca analizde önemli bir istisna yolunu gösterir.
Nereden alınır?
İlgili sysapproval_approver kaydının durum alanının 'rejected' değerine değişmesinden çıkarımla belirlenir. Bu işlem genellikle üst sc_req_item kaydını kapalı ve tamamlanmamış duruma getirir.
Kaydedin
sysapproval_approver.state alanının 'rejected' olduğu zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep yeniden açıldı
|
Daha önce çözüldü olarak işaretlenen bir talebin yeniden açık duruma alınmasını kaydeder. Durumun 'Resolved' değerinden 'Work in Progress' veya benzeri bir değere değişmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
Bu, yeniden çalışmanın doğrudan bir ölçüsüdür ve 'İlk seferde çözüm oranı' KPI’ını hesaplamak 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ü veya kapalı durumdan açık ya da devam ediyor durumuna değişmesinden çıkarımla belirlenir. Bu değişiklik sys_audit tablosuna kaydedilir.
Kaydedin
sys_audit içinde durumun 'Resolved' değerinden 'Work in Progress' değerine değiştiğini tespit edin.
Olay türü
inferred
|
|||
|
Yerine getirme görevi oluşturuldu
|
Hizmet talebini yerine getirmek için gereken belirli bir iş öğesinin veya görevin oluşturulmasını gösterir. Catalog Task tablosunda yeni bir kayıt oluşturulduğunda açık bir olay olarak kaydedilir. | ||
|
Neden önemli?
Karmaşık taleplerde, görevlerin tek tek oluşturulma ve tamamlanma süreçlerini analiz etmek, yerine getirme sürecini ve gecikmelerin nerede yaşandığını daha ayrıntılı görmeyi sağlar.
Nereden alınır?
sc_req_item kaydına bağlı sc_task tablosundaki bir kaydın oluşturulma zaman damgasından (sys_created_on alanı) alınan açık bir olaydır.
Kaydedin
sc_task kayıtlarındaki sys_created_on zaman damgasını kullanın.
Olay türü
explicit
|
|||
Veri çıkarma kılavuzları
Başlamaya hazır mısınız?
Bu Templatei kullanarak Process Mining çalışmalarınızı başlatın ve hizmet talebi yönetiminizde verimliliği artırın. Talepleri daha hızlı çözmek ve müşteri memnuniyetini yükseltmek için iş akışlarınızı bugün iyileştirmeye başlayın.
Hizmet talebi yönetimini dönüştürün: şimdi harekete geçin
Hizmet taleplerinde %70 otomasyon oranına ulaşın ve çözüm süresini kısaltın.
Kredi kartı gerekmez. Kurulum dakikalar içinde tamamlanır.