Servis Talep Yönetimi Veri Şablonunuz

Ivanti Service Manager
Servis Talep Yönetimi Veri Şablonunuz

Servis Talep Yönetimi Veri Şablonunuz

Bu şablon, servis talebi yönetiminizin etkili Process Mining analizi için gereken temel verileri toplamak üzere kapsamlı bir rehber sunar. Toplanacak kritik öznitelikleri, izlenecek ana aktiviteleri ana hatlarıyla belirtir ve bu bilgileri sisteminizden çıkarmak için pratik rehberlik içerir. Analiziniz için sağlam bir event log oluşturmak üzere bu kaynağı kullanın.
  • Kapsamlı analiz için önerilen özellikler
  • Süreç keşfi için izlenecek temel faaliyetler
  • Kaynak sisteminizden veri çekme konusunda rehberlik
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Servis Talep Yönetimi Öznitelikleri

Bunlar, servis talebi yönetimi sürecinizin kapsamlı bir analizi için event log'unuza dahil etmeniz önerilen veri alanlarıdır.
5 Gerekli 10 Önerilen 7 İsteğe Bağlı
Ad Açıklama
Faaliyet Adı
ActivityName
Servis talebi yaşam döngüsünün belirli bir noktasında gerçekleşen olayın veya görevin adı.
Açıklama

Bu öznitelik, servis talebi süreci içindeki belirli bir adımı veya durum değişikliğini, örneğin 'Onay İçin Gönderilen Talep' veya 'Çözülen Servis Talebi' gibi tanımlar. Aktivitelerin sırasını ve sıklığını analiz etmek, süreç akışını anlamak, darboğazları belirlemek ve standart prosedürden sapmaları keşfetmek için temeldir.

Neden önemli

Süreç haritasındaki adımları tanımlar, yeniden işleme, darboğazları ve sapmaları belirleme dahil olmak üzere süreç akışının görselleştirilmesine ve analizine olanak tanır.

Nereden alınır

Genellikle Ivanti Service Manager içindeki durum değişiklikleri, günlük girişleri veya denetim logu olay açıklamalarından türetilir.

Örnekler
Servis Talebi OluşturulduTalep OnaylandıHizmet Talebi ÇözüldüHizmet Talebi Kapatıldı
Olay Zamanı
EventTime
Belirli bir faaliyetin veya event'in ne zaman gerçekleştiğini gösteren zaman damgasıdır.
Açıklama

Olay Zamanı, aynı zamanda başlangıç zamanı olarak da bilinir, bir etkinliğin sisteme kaydedildiği kesin tarih ve saattir. Bu zaman damgası, olayları doğru sıralamak için kritik öneme sahiptir ve döngü süreleri, bekleme süreleri ve etkinlik süreleri gibi tüm zaman tabanlı süreç madenciliği analizlerinin temelini oluşturur.

Neden önemli

Bu zaman damgası, olayları kronolojik olarak sıralamak ve performans analizi için anahtar olan tüm süreye dayalı metrikleri hesaplamak için esastır.

Nereden alınır

Denetim kayıtlarında, günlük girişlerinde (örn. Journal.CreatedDateTime) veya Hizmet Talebi ile ilişkili durum değişikliği kayıtlarında bulunur.

Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Servis Talebi Kimliği
ServiceRequestID
Her servis talebi için benzersiz tanımlayıcı.
Açıklama

Servis Talep ID'si, bir kullanıcı veya sistem tarafından gönderilen her bir servis talebini benzersiz şekilde tanımlar. İlk kayıttan nihai kapanışa kadar tüm sonraki olayları birbirine bağlayan merkezi bir işlev görür ve her servis talebinin yolculuğunun eksiksiz, uçtan uca analizine olanak tanır.

Neden önemli

Bu, tüm ilgili aktiviteleri tek bir süreç örneğine bağlayan temel vaka tanımlayıcısıdır ve uçtan uca süreç analizine olanak tanır.

Nereden alınır

Bu, Servis Talep iş nesnesinin birincil anahtarıdır ve genellikle ServiceReq tablosunda ServiceReqNumber olarak bulunur.

Örnekler
SR-0012345SR-0012346SR-0012347
Kaynak Sistem
SourceSystem
Verilerin çekildiği sistem.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını tanımlar. Bu görünüm için değer sabit olacak ve tüm verilerin Ivanti Service Manager'dan geldiğini gösterecektir. Bu, verilerin birden fazla sistemden birleştirilebileceği ortamlarda önemlidir ve net veri soy ağacı ve bağlam sağlar.

Neden önemli

Veri kökeni hakkında kritik bağlam sağlar, analizlerin özellikle çok sistemli ortamlarda belirli kaynak sisteme doğru şekilde atfedilmesini garanti eder.

Nereden alınır

Bu, genellikle veri çıkarma süreci sırasında veri setinin kaynağını etiketlemek için eklenen sabit (statik) bir değerdir.

Örnekler
Ivanti Service Manager
Son Veri Güncellemesi
LastDataUpdate
Kaynak sistemden en son veri yenilemesinin zaman damgası.
Açıklama

Bu öznitelik, verilerin Ivanti Service Manager'dan en son ne zaman çıkarıldığını gösteren tarih ve saati belirtir. Analiz edilen verinin güncelliği hakkında bağlam sağlayarak, kullanıcıların analizin kapsadığı zaman diliminden ve bir sonraki güncellemenin ne zaman bekleneceğinden haberdar olmalarını sağlar.

Neden önemli

Kullanıcıları verilerin güncelliği hakkında bilgilendirir; bu da mevcut en güncel süreç performansı bilgilerine dayanarak karar vermek için kritik öneme sahiptir.

Nereden alınır

Bu değer, data çıkarma anında oluşturulur ve dataset'e damgalanır.

Örnekler
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
Atanan Ekip
AssignedTeam
Servis talebini şu anda işlemek üzere atanan destek ekibi veya grubu.
Açıklama

Bu öznitelik, belirli bir zamanda servis talebini işlemekten sorumlu ekibi tanımlar. Ekipler arasındaki devirleri, her bir ekiple geçirilen süreyi ve farklı ekipler tarafından işlenen talep hacmini analiz etmek, iş yükü dağılımını anlamak, darboğazları belirlemek ve ekip performansını değerlendirmek için kritik öneme sahiptir. SLA uyumu ve temsilci iş yükü ile ilgili dashboard'ları doğrudan destekler.

Neden önemli

Sorumluluğu ve devirleri takip ederek, ekipler arası gecikmeleri, iş yükü dengesini ve süreçte hangi ekiplerin darboğaz olduğunu analiz etmeye yardımcı olur.

Nereden alınır

Bu bilgi genellikle Servis Talep nesnesindeki 'Sahip Ekibi' gibi bir alanda veya ilgili atama kayıtlarında saklanır.

Örnekler
BT Servis MasasıAğ OperasyonlarıİK DesteğiTesis Yönetimi
Atanan Temsilci
AssignedAgent
Servis talebine atanan bireysel kullanıcı veya temsilci.
Açıklama

Atanan Temsilci, servis talebi üzerinde çalışmaktan sorumlu belirli kişidir. Bu öznitelik, performans yönetimi, iş yükü dengeleme ve eğitim fırsatlarını belirleme açısından faydalı olan bireysel düzeyde analiz yapılmasını sağlar. Temsilciler arasındaki yeniden atamaları takip etmek, 'Talep Başına Ortalama Yeniden Atama' gibi KPI'ları hesaplamak ve süreç verimsizliklerini anlamak için anahtardır.

Neden önemli

Bireysel iş yükü, performans ve yeniden atama modellerinin analizini sağlar; bu da eğitim, beceri setleri veya ilk yönlendirme ile ilgili sorunları gösterebilir.

Nereden alınır

Genellikle Servis Talep nesnesindeki 'Sahip' gibi bir alanda bulunur. Bu, her yeniden atama ile değişebilir ve event logunda takip edilmelidir.

Örnekler
Alice JohnsonBob Williams`Charlie Brown`Diana Prince
Çözüm Zaman Damgası
ResolutionDateTime
Servis talebinin resmi olarak çözüldüğü tarih ve saat.
Açıklama

Bu, hizmetin teslim edildiği veya sorunun giderildiği, talebin resmi olarak kapatılmasından önceki son zaman damgasını işaretleyen vaka düzeyinde bir özniteliktir. Bu zaman damgası, bir servis talebinin uçtan uca döngü süresini hesaplamak için birincil bitiş noktasıdır. Genel süreç verimliliğini ve SLA uyumunu ölçmek için kritik bir bileşendir.

Neden önemli

Hizmet sunumu verimliliği için temel performans göstergesi olan ana süreç döngü süresi hesaplamasının bitiş noktasını tanımlar.

Nereden alınır

Hizmet Talep nesnesi üzerinde, genellikle 'ÇözümlenmeTarihiSaati' veya benzeri adlandırılan belirli bir zaman damgası alanı.

Örnekler
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
Döngü Süresi
CycleTime
Servis talebinin oluşturulmasından nihai çözümüne kadar geçen toplam süre.
Açıklama

Döngü Süresi, ilk olaydan (Hizmet Talebi Oluşturuldu) çözüm olayına (Hizmet Talebi Çözüldü) kadar geçen süreyi ölçen hesaplanmış bir metriktir. Süreç verimliliği için en önemli temel performans göstergelerinden biridir. Bu metrik, genel performansı izlemek ve zaman içindeki eğilimleri belirlemek için dashboard'larda yaygın olarak kullanılır.

Neden önemli

Bu, uçtan uca süreç verimliliğini ölçmek için birincil bir KPI'dır ve kullanıcı açısından hizmet deneyimini doğrudan yansıtır.

Nereden alınır

Her hizmet talebi için oluşturma zaman damgasının çözüm zaman damgasından çıkarılmasıyla hesaplanır.

Örnekler
25920000060480000086400000
Hizmet Talebi Türü
ServiceRequestType
Servis talebinin sınıflandırması veya kategorisi.
Açıklama

Bu öznitelik, servis talebini örneğin 'Donanım Talebi', 'Yazılım Kurulumu' veya 'Şifre Sıfırlama' gibi kategorize eder. Analiz için kritik bir boyuttur ve ekiplerin farklı hizmet türleri arasında süreç performansını, döngü sürelerini ve SLA uyumunu karşılaştırmasına olanak tanır. Bu farklılıkları anlamak, süreç iyileştirmelerini uyarlamaya ve kaynakları daha etkili bir şekilde tahsis etmeye yardımcı olur.

Neden önemli

Süreci talep türüne göre bölümlendirmek, hedeflenmiş analiz imkanı sunar ve belirli talep türlerinin gecikmelere, yeniden çalışmaya veya SLA ihlallerine daha yatkın olup olmadığını ortaya koyar.

Nereden alınır

Muhtemelen Hizmet Talep iş nesnesi üzerinde 'Hizmet' veya 'Kategori' olarak adlandırılan bir alan. 'SvcReqTmplLink_Category' gibi belirli alan adları için Ivanti Service Manager dokümantasyonuna başvurun.

Örnekler
Yeni Donanım TalebiYazılım ErişimiHesap DeğişikliğiBilgi Sorgulama
Olay Bitiş Zamanı
EventEndTime
Bir aktivitenin tamamlandığını gösteren timestamp.
Açıklama

Event End Time, bir aktivitenin tamamlandığını işaretler. Event Time (başlangıç) ile Event End Time arasındaki süre, o belirli aktivitenin işlem süresini temsil eder. Bu, süreçteki hangi adımların en çok zaman tükettiğini belirlemek, verimsizlikleri ve iyileştirme alanlarını tespit etmek için kritik öneme sahiptir.

Neden önemli

Bireysel etkinlik sürelerinin hesaplanmasını sağlar, bu da süreç darboğazlarını ve uzun süren görevleri belirlemek için hayati öneme sahiptir.

Nereden alınır

Ayrı bir alan olarak bulunmayabilir. Genellikle, aynı vaka için ardışık etkinliğin başlangıç zamanıdır.

Örnekler
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
Öncelik
Priority
Servis talebine atanan öncelik seviyesi.
Açıklama

Öncelik, bir hizmet talebinin aciliyetini belirtir, genellikle 'Düşük', 'Orta', 'Yüksek', 'Kritik' gibi bir ölçekte. Bu nitelik, sürecin yüksek öncelikli talepleri etkin bir şekilde hızlandırıp hızlandırmadığını değerlendirmek için temeldir. Analiz genellikle, önceliklendirme kurallarının amaçlandığı gibi çalıştığından emin olmak için farklı öncelik seviyeleri arasındaki döngü sürelerini ve SLA uyumluluğunu karşılaştırmayı içerir.

Neden önemli

Önceliklendirme stratejisinin etkinliğini değerlendirmek ve yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı çözülmesini sağlamak için kritik öneme sahiptir.

Nereden alınır

Hizmet Talep nesnesi üzerinde, genellikle 'Öncelik' olarak adlandırılan standart bir alan.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
Servis Talep Durumu
ServiceRequestStatus
Olay anındaki servis talebinin durumu.
Açıklama

Bu öznitelik, servis talebinin 'Kaydedildi', 'Devam Ediyor', 'Beklemede', 'Çözüldü' veya 'Kapalı' gibi durumunu yakalar. Durum değişiklikleri genellikle süreç logundaki aktiviteleri tanımlar. Her bir durumda geçirilen süreyi analiz etmek, darboğazları ortaya çıkarabilir; örneğin, talepler 'Beklemede' durumunda çok uzun süre kalırsa.

Neden önemli

Talebin herhangi bir zamandaki durumunun anlık görüntüsünü sağlar, bu da belirli durumlarda geçirilen süreyi hesaplamak ve süreç duraklamalarını belirlemek için esastır.

Nereden alınır

Hizmet Talep nesnesi üzerinde, yaygın olarak 'Durum' olarak adlandırılan standart bir alan.

Örnekler
KaydedildiAktifMüşteri BekleniyorTamamlandıKapalı
SLA Son Teslim Tarihi
SLADeadline
Servis talebinin çözülmesi beklenen zaman damgası.
Açıklama

SLA Süresi, bir servis talebinin Hizmet Seviyesi Anlaşması'nı karşılamak için çözülmesi gereken hesaplanmış tarih ve saattir. Bu hedef genellikle talebin önceliği ve türü gibi faktörlere göre belirlenir. Gerçek çözüm süresini bu süreyle karşılaştırmak, SLA uyumunu ölçmenin temelidir.

Neden önemli

Gerçek performansın ölçüldüğü bir kıyaslama noktasıdır, SLA uyum oranlarının hesaplanmasını ve risk altındaki taleplerin belirlenmesini doğrudan destekler.

Nereden alınır

Bu genellikle Ivanti içinde hesaplanmış bir alan olup, Hizmet Seviyesi Anlaşması veya Teklif ile ilgili alanlarda, örneğin 'ResolutionTargetDateTime' olarak saklanır.

Örnekler
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
SLA Statüsü
SLAStatus
Hizmet talebinin SLA son teslim tarihi içinde çözülüp çözülmediğini belirtir.
Açıklama

Bu, servis talebinin SLA süresine göre çözüm zamanına bağlı olarak her bir servis talebini 'Karşılandı' veya 'İhlal Edildi' olarak işaretleyen türetilmiş bir özniteliktir. 'SLA Uygunluk Performansı' dashboard'unun ve 'Hizmet Seviyesi Anlaşması Uygunluk Oranı' KPI'ının temelini oluşturur. Mantık, her vaka için ResolutionDateTime ile SLADeadline'ı karşılaştırır.

Neden önemli

Hizmet taahhütlerine karşı performansı doğrudan ölçer, bu da hizmet kalitesini değerlendirmek ve kullanıcı güvenini sürdürmek için kritik öneme sahiptir.

Nereden alınır

'ÇözümlenmeTarihiSaati'nin 'SLASonTeslimTarihi' ile karşılaştırılmasıyla hesaplanır. Eğer ÇözümlenmeTarihiSaati <= SLASonTeslimTarihi ise durum 'Karşılandı'; aksi takdirde 'İhlal Edildi'dir.

Örnekler
Karşılandıİhlal Edildi
Atama Sayısı
AssignmentCount
Bir servis talebinin kaç kez atandığı veya yeniden atandığı toplam sayısı.
Açıklama

Bu hesaplanmış metrik, her servis talebi için atama ile ilgili aktivitelerin (örneğin, 'Ekibe Atandı', 'Temsilciye Atandı') sayısını sayar. Genellikle 'bilet pinponu' olarak adlandırılan yüksek yeniden atama sayısı, yönlendirmedeki verimsizlikleri, ilk temasta çözüm eksikliğini veya net olmayan ekip sorumluluklarını gösterir. Bu öznitelik, 'Talep Başına Ortalama Yeniden Atama' KPI'ı için esastır.

Neden önemli

Verimsiz devir ve yönlendirme sorunlarını nicelendirir. Yüksek bir sayı, uzayan çözüm sürelerinin ve kullanıcı memnuniyetsizliğinin güçlü bir göstergesidir.

Nereden alınır

Veri hazırlığı sırasında her benzersiz HizmetTalepID'si için atama ile ilgili faaliyetlerin tekrarlanma sayısını sayarak hesaplanır.

Örnekler
12345
Çözüm Kategorisi
ResolutionCategory
Hizmet talebi için sağlanan çözümün bir sınıflandırması.
Açıklama

Çözüm Kategorisi, bir servis talebinin nihayetinde nasıl çözüldüğünü sınıflandırmak için yapılandırılmış bir yol sunar. Bu genellikle (örneğin, Kategori, Alt Kategori gibi) kök neden analizi ve trend raporlamasına yardımcı olan hiyerarşik bir sınıflandırmadır. Örneğin, tekrar eden sorunları veya yaygın karşılama eylem türlerini vurgulayabilir; bu da hizmetleri iyileştirmek veya bilgi tabanı makaleleri oluşturmak için kullanılabilir.

Neden önemli

Çözümlerin niteliğine dair içgörüler sağlar, yaygın sorunları, hizmet iyileştirme fırsatlarını ve otomasyon adaylarını belirlemeye yardımcı olur.

Nereden alınır

Genellikle çözüm sırasında doldurulan kategorizasyon alanlarında saklanır, örneğin 'ÇözümKategorisi' veya özel bir kapanış kodu alanı.

Örnekler
Kullanıcı Eğitimi GerekliYazılım DağıtıldıDonanım OnarıldıErişim Verildi
Kanal
Channel
Servis talebinin gönderildiği yöntem veya kanal.
Açıklama

Kanal, servis talebinin nasıl oluşturulduğunu gösterir; örneğin, Self-Service Portal, E-posta, Telefon aracılığıyla veya otomatik olarak başka bir sistem tarafından. Kanal bazında talep hacimlerini ve çözüm sürelerini analiz etmek, hangi kanalların en verimli olduğuna ve hangilerinin süreç iyileştirmeleri veya kullanıcı eğitimi gerektirebileceğine dair içgörüler sağlayabilir.

Neden önemli

Kullanıcı davranışlarını ve kanal verimliliğini anlamaya yardımcı olur, bu da hizmet sunumu stratejisi ve otomasyon fırsatları hakkında kararlar alınmasına rehberlik edebilir.

Nereden alınır

Bu genellikle Servis Talep nesnesindeki 'Kaynak' veya 'Oluşturan' türünde bir alanda saklanır.

Örnekler
`Self-Service`E-postaTelefonDoğrudan Giriş
Talep Sahibi Departmanı
RequestorDepartment
Servis talebini gönderen kullanıcının iş departmanı.
Açıklama

Bu öznitelik, servis talebini başlatan çalışanın veya sistemin departmanını, örneğin 'Satış', 'Finans' veya 'İnsan Kaynakları' gibi tanımlar. Organizasyonun farklı bölümleri arasında hizmet kalitesi ve talep analizine olanak tanır. Örneğin, belirli departmanların daha uzun çözüm süreleri yaşadığını veya daha yüksek hacimde talep gönderdiğini belirlemeye yardımcı olabilir.

Neden önemli

Hizmet tüketiminin ve kalitesinin iş birimine göre analiz edilmesini sağlayarak departmana özgü sorunların veya eğilimlerin belirlenmesine yardımcı olur.

Nereden alınır

Bu bilgi genellikle talep sahibinin kullanıcı profilinden, Servis Talebi ile ilişkilendirilmiş olarak alınır. Alan, Profile.Employee nesnesinde 'Departman' olabilir.

Örnekler
FinansSatışPazarlamaBilgi Teknolojileri
Tedarikçi Adı
VendorName
Talebin çözülmesinde yer alan harici tedarikçinin adı.
Açıklama

Bu öznitelik, bir servis talebine yardımcı olmak veya tamamlamak için görevlendirilen üçüncü taraf tedarikçiyi tanımlar. 'Harici Tedarikçi Aktivite Süresi' dashboard'u için esastır, çünkü farklı tedarikçilerin performansını ölçmeye ve karşılaştırmaya olanak tanır. Bunu takip etmek, tedarikçi ilişkilerini yönetmeye ve dış bağımlılıkların neden olduğu darboğazları belirlemeye yardımcı olur.

Neden önemli

Üçüncü taraf performansının ve genel hizmet talebi çözüm süreleri üzerindeki etkilerinin analizini sağlar, tedarikçi yönetimini destekler.

Nereden alınır

Bu, servis talebiyle ilişkili bir görev nesnesindeki bir alan veya bir tedarikçi atandığında Servis Talebinin kendisindeki belirli bir alan olabilir.

Örnekler
Dell DesteğiOracle ConsultingMicrosoft Premiernull
Yeniden Açılma Sayısı
ReopenCount
Çözülmüş bir servis talebinin kaç kez yeniden açıldığı sayısı.
Açıklama

Bu öznitelik, bir servis talebinin 'Çözüldü' veya 'Kapalı' durumundan 'Aktif' duruma geri taşındığı her seferde artan bir sayaçtır. Yüksek yeniden açılma sayısı, zayıf ilk seferde çözüm kalitesinin, eksik çözümlerin veya tekrar eden sorunların güçlü bir göstergesidir. 'Servis Talep Yeniden Çalışma Oranı' KPI'ını doğrudan destekler.

Neden önemli

Yeniden işleme miktarını doğrudan ölçer ve çözüm kalitesinin önemli bir göstergesidir. Yüksek sayılar, ilk düzeltmenin etkili olmadığını gösterir.

Nereden alınır

Bu, genellikle Servis Talep nesnesinde, durum uygun şekilde değiştiğinde bir iş kuralı tarafından artırılan bir sayaç alanıdır. 'Yeniden AçılmaSayacı' olarak adlandırılabilir.

Örnekler
0123
Yeniden İşleme mi?
IsRework
Hizmet talebinin yeniden işleme faaliyetleri içerip içermediğini gösteren bir boolean bayrağı.
Açıklama

Bu hesaplanmış bayrak, bir servis talebinin çözüldükten sonra yeniden açılması veya belirli aktivitelerin bir döngüde tekrarlanması gibi yeniden çalışma belirtileri gösteriyorsa doğru (true) olarak ayarlanır. 'Servis Talep Yeniden Çalışma Oranı' KPI'ının hesaplanmasını basitleştirir ve 'Yeniden Çalışma ve Yeniden Atama Akışları' gibi dashboard'larda verimsiz süreç örneklerini filtrelemeye yardımcı olur.

Neden önemli

Ek, plansız çaba gerektiren taleplerin hacmini kolayca belirlemeye ve ölçmeye yardımcı olarak kalite ve verimlilik sorunlarını vurgular.

Nereden alınır

Verilerden türetilmiştir. Mantık, 'YenidenAçılmaSayısı' niteliğinin sıfırdan büyük olmasına veya birden çok 'Temsilciye Atandı' olayları gibi belirli etkinlik dizilerinin tespit edilmesine dayanabilir.

Örnekler
truefalse
Gerekli Önerilen İsteğe Bağlı

Servis Talep Yönetimi Aktiviteleri

Bunlar, doğru süreç keşfi ve analizi için event log'unuzda yakalanması gereken temel süreç adımları ve dönüm noktalarıdır.
5 Önerilen 9 İsteğe Bağlı
Aktivite Açıklama
Hizmet Talebi Çözüldü
Servis talebi çözülmüş kabul edilir ve çözüm kullanıcıya teslim edilmiştir. Bu, 'Çözüldü' durumuna geçişle kaydedilen birincil bir dönüm noktasıdır ve genellikle bir SLA sayacının durmasını tetikler.
Neden önemli

Bu, çözüm süresini ve SLA uyumunu ölçmek için kritik bir bitiş noktasıdır. Oluşturulmadan bu aktiviteye kadar geçen süre, süreç performansı için temel bir KPI'dır.

Nereden alınır

Hizmet Talep kaydındaki 'Durum' alanının 'Çözüldü' olarak değişmesinden ve ilişkili zaman damgasından çıkarılır.

Yakala

Denetim geçmişinden 'Durum' alanının 'Çözüldü' olarak güncellenmesinin tespit edilmesi.

Event tipi inferred
Hizmet Talebi Kapatıldı
Servis talebi resmi olarak kapatılmıştır ve başka hiçbir işlem yapılamaz. Bu genellikle 'Çözüldü' durumunda belirli bir süre geçtikten sonra otomatik olarak gerçekleşir ve yaşam döngüsünün nihai sonucunu temsil eder.
Neden önemli

Bu aktivite, sürecin kesin sonudur. 'Çözüldü' ve 'Kapalı' arasındaki süre, onay veya otomatik sistem süreçlerindeki gecikmeleri vurgulayabilir.

Nereden alınır

Hizmet Talep kaydındaki 'Durum' alanının 'Kapalı' olarak değişmesinden ve ilişkili zaman damgasından çıkarılır.

Yakala

Denetim geçmişinden 'Durum' alanının 'Kapalı' olarak güncellenmesinin tespit edilmesi.

Event tipi inferred
Servis Talebi Oluşturuldu
Bu aktivite, yeni bir talebin resmi olarak gönderildiği ve Ivanti'ye kaydedildiği servis talebi yaşam döngüsünün başlangıcını işaret eder. Bu olay, Servis Talebi iş nesnesinde yeni bir kayıt oluşturulduğunda ve benzersiz bir Servis Talep ID'si üretildiğinde yakalanır.
Neden önemli

Bu, süreç için birincil başlangıç olayıdır. Bu noktadan çözüme kadar geçen süreyi analiz etmek, genel döngü süresini ve süreç verimliliğini ölçmek için temeldir.

Nereden alınır

Bu, Servis Talebi kaydının oluşturulma zaman damgasından (örneğin, ServiceReq iş nesnesindeki CreatedDateTime alanı) yakalanır.

Yakala

ServiceReq tablosundaki kayıt oluşturma olayı, oluşturulma zaman damgasıyla tanımlanır.

Event tipi explicit
Talep Ekibe Atandı
Servis talebi, işlenmek üzere belirli bir destek ekibine atanır. Bu, Servis Talebi kaydındaki 'Sahip Ekibi' alanının doldurulması veya değişmesi gözlemlenerek kaydedilir.
Neden önemli

Bu olay, ekip düzeyindeki performansı, iş yükü dağılımını ve ekipler arası devir sürelerini analiz etmek için kritik öneme sahiptir. Süreçte hangi ekiplerin darboğaz olduğunu belirlemeye yardımcı olur.

Nereden alınır

Servis Talebinin denetim geçmişindeki veya günlüğündeki 'Sahip Ekibi' alanındaki değişiklikler tarafından takip edilir.

Yakala

'SahipEkibi' alanına yapılan bir güncelleme olayı, genellikle bir denetim kaydında tutulur.

Event tipi explicit
Talep Temsilciye Atandı
Belirli bir temsilci hizmet talebinin sahipliğini alır. Bu etkinlik genellikle, bireysel temsilciyi belirten 'Sahip' alanı ilk kez doldurulduğunda veya güncellendiğinde çıkarılır.
Neden önemli

Bu, başlangıçtaki bekleme veya kuyruk süresinin sonunu işaretler. Bu aktiviteden önceki süreyi ölçmek, kaynak tahsisi sorunlarını belirlemeye ve Temsilci İş Yükü dashboard'unu desteklemeye yardımcı olur.

Nereden alınır

Denetim geçmişinde görüldüğü üzere, Hizmet Talep kaydındaki 'Sahip' alanının doldurulmasından veya değişmesinden çıkarılır.

Yakala

Oluşturulduktan veya ekibe atandıktan sonra 'Sahip' alanının bir temsilcinin adıyla doldurulduğu ilk zaman damgası.

Event tipi inferred
Harici Tedarikçi Devrede
Servis talebi karşılaması harici bir tedarikçiye veya üçüncü tarafa devredilmiştir. Bu durum genellikle '3. Taraf Bekleniyor' veya benzer bir duruma geçişle kaydedilir.
Neden önemli

Bu aktivite, tedarikçi performansını ve bunun genel döngü süresi üzerindeki etkisini ölçmek için esastır. Tedarikçi kaynaklı gecikmelerin analizine olanak tanır ve Harici Tedarikçi Aktivite Süresi dashboard'unu destekler.

Nereden alınır

Hizmet Talep kaydındaki durum değişikliğinden 'Üçüncü Taraf Bekleniyor' veya 'Tedarikçi Bekleniyor' gibi bir duruma çıkarılır.

Yakala

'Durum' alanındaki bir değişikliğin belirlenmiş bir 'tedarikçi bekleniyor' durumuna geçişinin tespit edilmesi.

Event tipi inferred
Hizmet Talebi Karşılandı
Hizmet talebini yerine getirmek için gereken tüm görevler temsilci veya sistem tarafından tamamlandı. Bu, genellikle nihai 'Çözüldü' durumundan önce gelen 'Gerçekleştirildi' durumuna bir durum değişikliğiyle yakalanır.
Neden önemli

Bu dönüm noktası, teknik veya prosedürel çalışmanın tamamlandığını işaretler. Nihai onay ve kapanıştan önceki aktif işlem süresini ölçmek için önemli bir noktadır.

Nereden alınır

Hizmet Talep kaydındaki 'Durum' alanının 'Gerçekleştirildi' olarak değişmesinden çıkarılır.

Yakala

Kaydın geçmişinden tespit edilen 'Durum' alanının 'Gerçekleştirildi' olarak değişmesi.

Event tipi inferred
Hizmet Talebi Yeniden Açıldı
Daha önce çözülmüş bir hizmet talebi, sorunun devam etmesi veya çözümün yetersiz olması nedeniyle yeniden etkinleştirildi. Bu, durumun 'Çözüldü'den 'Aktif' veya 'Atandı' gibi aktif bir duruma geri dönmesiyle yakalanır.
Neden önemli

Bu aktivite, yeniden çalışmanın ve zayıf ilk seferde çözüm kalitesinin doğrudan bir göstergesidir. Yeniden açılma olaylarını analiz etmek, süreç zayıflıklarını belirlemeye ve Servis Talep Yeniden Çalışma Oranı KPI'ını iyileştirmeye yardımcı olur.

Nereden alınır

Denetim geçmişinden, 'Durum' alanı 'Çözüldü' veya 'Kapalı'dan aktif bir duruma değiştiğinde çıkarılır.

Yakala

Terminal bir durumdan ('Çözüldü', 'Kapalı') açık bir duruma ('Aktif', 'Atandı') durum değişikliği.

Event tipi inferred
Kullanıcı Tarafından Sağlanan Bilgi
Talep sahibi gerekli bilgiyi sağlamış ve temsilcinin çalışmaya devam etmesine olanak tanımıştır. Bu durum, talep 'Müşteri Bekleniyor' durumundan çıkarak 'aktif' bir duruma geri döndüğünde kaydedilir.
Neden önemli

Bu olay, bilgi talepleri döngüsünü kapatır. Bilgi talep etme ve alma arasındaki süre, süreç gecikmelerinin ve yeniden çalışma döngülerinin kritik bir bileşenidir.

Nereden alınır

Hizmet Talebinin 'Durum' alanı 'Müşteri Bekleniyor' durumundan 'Aktif' veya 'Devam Ediyor' gibi aktif bir duruma değiştiğinde çıkarılır.

Yakala

Bir 'kullanıcı bekleniyor' durumundan aktif bir duruma durum değişikliğinin tespit edilmesi.

Event tipi inferred
Kullanıcıdan Bilgi Talep Edildi
Atanan temsilcinin, talebin karşılanmasına devam etmek için talep sahibinden daha fazla bilgiye ihtiyacı vardır. Bu durum, talep durumu 'Müşteri Bekleniyor' gibi bir duruma güncellendiğinde kaydedilir.
Neden önemli

Bu aktivite, eksik başlangıç bilgileri nedeniyle oluşan gecikmeleri vurgular. Sıklığını ve süresini takip etmek, Bilgi Talep Etki Analizi ve süreç iyileştirme alanlarını belirlemek için anahtardır.

Nereden alınır

Hizmet Talep kaydındaki durum değişikliğinden 'Müşteri Bekleniyor' veya 'Beklemede' gibi bir duruma çıkarılır.

Yakala

'Durum' alanındaki bir değişikliğin belirlenmiş bir 'kullanıcı bekleniyor' durumuna geçişinin tespit edilmesi.

Event tipi inferred
Öncelik Değiştirildi
Servis talebinin önceliği, ilk oluşturulduktan sonra güncellenmiştir. Bu olay, alan düzeyindeki değişiklikleri izleyen denetim logundan veya geçmişten yakalanır.
Neden önemli

Öncelik değişikliklerini takip etmek, Önceliklendirme Etkinliği Genel Bakışı için hayati öneme sahiptir. Yükseltmelerin doğru yönetilip yönetilmediğini ve ilk önceliklendirmenin doğru olup olmadığını belirlemeye yardımcı olur.

Nereden alınır

Bu, 'Öncelik' alanındaki değişiklikleri kaydeden Servis Talebi kaydının denetim geçmişinden yakalanan açık bir olaydır.

Yakala

Sistemin denetim kaydında kaydedilen 'Öncelik' alanına yapılan bir güncelleme olayı.

Event tipi explicit
Servis Talebi İptal Edildi
Servis talebi, çözümden önce kullanıcı veya bir temsilci tarafından iptal edilmiştir. Bu, 'İptal Edildi' veya 'Geri Çekildi' durumuna geçişle kaydedilen alternatif bir son durumdur.
Neden önemli

Bu, standart dışı bir süreç sonlandırmayı temsil eder. Taleplerin neden iptal edildiğini analiz etmek, talep sürecinin kendisiyle ilgili sorunları veya değişen kullanıcı ihtiyaçlarını ortaya çıkarabilir.

Nereden alınır

Hizmet Talep kaydındaki 'Durum' alanının 'İptal Edildi' olarak değişmesinden çıkarılır.

Yakala

Denetim geçmişinden 'Durum' alanının 'İptal Edildi' olarak güncellenmesinin tespit edilmesi.

Event tipi inferred
Talep Onay İçin Gönderildi
Servis talebi, karşılanmadan önce gerekli onaylar için gönderilmiştir. Bu genellikle talep durumu 'Gönderildi' veya 'Onay Bekleniyor' olarak değiştiğinde anlaşılır ve genellikle bir onay iş akışını tetikler.
Neden önemli

Bu aktiviteyi takip etmek, onay aşamasındaki gecikmeleri belirlemeye yardımcı olur. Buradaki uzun beklemeler, genel çözüm sürelerini ve kullanıcı memnuniyetini etkileyen önemli bir darboğaz olabilir.

Nereden alınır

Hizmet Talep kaydındaki bir durum değişikliğinden, muhtemelen 'Gönderildi' veya 'Onay Bekleniyor' gibi bir duruma çıkarılır. Bu aynı zamanda FRS_Approval veya FRS_ApprovalVoteTracking iş nesnelerinden de alınabilir.

Yakala

Hizmet Talep kaydındaki 'Durum' alanının onaya bekleyen bir duruma geçmesi.

Event tipi inferred
Talep Onaylandı
Servis talebi gerekli tüm onayları almış ve şimdi karşılanma aşamasına geçebilir. Bu olay, onay iş akışı başarıyla tamamlandığında ve talebin durumu değiştiğinde kaydedilir.
Neden önemli

Bu aktivite, onay aşamasının sonunu ve karşılamanın başlangıcını işaret eden önemli bir dönüm noktasıdır. Onay sürecinin kendi verimliliğini ölçmeye olanak tanır.

Nereden alınır

'Onay Bekleniyor' durumundan 'Onaylandı' veya 'Gerçekleştirildi' durumuna bir durum değişikliğinden çıkarılır. Bu, FRS_Approval iş nesnesinde kaydedilmiş açık bir olay da olabilir.

Yakala

Hizmet Talep kaydındaki 'Durum' alanının bir onay durumundan aktif bir duruma geçmesi.

Event tipi inferred
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

Ivanti Service Manager'dan verilerinizi nasıl alırsınız