Hizmet Talebi Yönetimi Veri Şablonunuz

Ivanti Service Manager
Hizmet Talebi Yönetimi Veri Şablonunuz

Hizmet Talebi Yönetimi Veri Şablonunuz

Bu Template, hizmet talebi yönetiminizi etkili biçimde Process Mining ile analiz etmek için gereken temel verileri toplamanıza yardımcı olur. Toplanması gereken önemli öznitelikleri ve izlenecek temel etkinlikleri açıklar, ayrıca bu bilgileri sisteminizden nasıl çıkaracağınıza ilişkin pratik yönlendirmeler sunar. Analiziniz için güvenilir bir Event Log oluşturmak üzere bu kaynaktan yararlanın.
  • Ayrıntılı analiz için önerilen öznitelikler
  • Süreç keşfi için izlenecek temel etkinlikler
  • Kaynak sisteminizden veri çıkarma yönlendirmesi
Event Loglarına yeni misiniz? Öğrenin Process Mining Event Logu oluşturmayı öğrenin.

Hizmet Talebi Yönetimi Öznitelikleri

Hizmet talebi yönetimi sürecinizi kapsamlı biçimde analiz etmek için Event Logunuza eklemeniz önerilen veri alanları aşağıdadır.
5 Gerekli 9 Önerilen 7 İsteğe bağlı
Ad Açıklama
Faaliyet Adı
ActivityName
Hizmet 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, 'Request Submitted for Approval' veya 'Service Request Resolved' gibi hizmet talebi sürecindeki belirli bir adımı veya durum değişikliğini tanımlar. Faaliyetlerin sırasını ve sıklığını analiz etmek, süreç akışını anlamak, darboğazları belirlemek ve standart prosedürden sapmaları ortaya çıkarmak için temeldir.

Neden önemli?

Süreç haritasındaki adımları tanımlar ve yeniden işleme, darboğazlar ile sapmalar dahil olmak üzere süreç akışının görselleştirilmesini ve analiz edilmesini sağlar.

Nereden alınır?

Genellikle Ivanti Service Manager içindeki durum değişikliklerinden, günlük girdilerinden veya denetim günlüğü olay açıklamalarından elde edilir.

Örnekler
Hizmet Talebi OluşturulduTalep OnaylandıHizmet Talebi ÇözüldüHizmet Talebi Kapatıldı
Hizmet Talebi Kimliği
ServiceRequestID
Her hizmet talebi için benzersiz tanımlayıcı.
Açıklama

Hizmet Talebi Kimliği, bir kullanıcı veya sistem tarafından gönderilen her bir hizmet talebini benzersiz şekilde tanımlar. İlk kayıttan nihai kapatmaya kadar sonraki tüm olayları birbirine bağlayan merkezi bir iz görevi görür. Böylece her hizmet talebinin uçtan uca yolculuğu analiz edilebilir.

Neden önemli?

Bu, ilgili tüm faaliyetleri tek bir süreç örneğinde birleştiren ve uçtan uca süreç analizini mümkün kılan temel vaka tanımlayıcısıdır.

Nereden alınır?

Bu, Service Request iş nesnesinin birincil anahtarıdır ve çoğu zaman ServiceReq tablosunda ServiceReqNumber olarak bulunur.

Örnekler
SR-0012345SR-0012346SR-0012347
Olay Zamanı
EventTime
Belirli bir faaliyet veya olayın gerçekleştiği zamanı gösteren zaman damgası.
Açıklama

Başlangıç zamanı olarak da bilinen Olay Zamanı, bir faaliyetin sistemde kaydedildiği kesin tarih ve saattir. Bu zaman damgası, olayların doğru sıraya konulması için önemlidir ve çevrim süreleri, bekleme süreleri ve faaliyet süreleri gibi zamana dayalı tüm Process Mining analizlerinin temelini oluşturur.

Neden önemli?

Bu zaman damgası, olayları kronolojik olarak sıralamak ve performans analizi için önemli olan süreye dayalı tüm metrikleri hesaplamak açısından gereklidir.

Nereden alınır?

Denetim günlüklerinde, günlük girdilerinde (örneğin Journal.CreatedDateTime) veya Hizmet Talebiyle 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
Kaynak Sistem
SourceSystem
Verilerin çıkarıldığı sistem.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını tanımlar. Bu görünümde değer sabit olur ve tüm verilerin Ivanti Service Manager'dan geldiğini gösterir. Verilerin birden fazla sistemden birleştirilebildiği ortamlarda veri kökeninin ve bağlamının net olmasını sağladığı için önemlidir.

Neden önemli?

Verilerin kökeni hakkında önemli bağlam sağlar. Özellikle birden fazla sistemin bulunduğu ortamlarda analizlerin doğru kaynak sisteme atfedilmesini sağlar.

Nereden alınır?

Bu, genellikle veri çıkarma sürecinde Veri Setinin kaynağını belirtmek için eklenen statik bir değerdir.

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

Bu öznitelik, verilerin Ivanti Service Manager'dan en son çıkarıldığı tarih ve saati gösterir. Analiz edilen verilerin kapsadığı dönemi ve bir sonraki güncellemenin ne zaman beklenebileceğini anlamanızı sağlayarak verilerin güncelliği hakkında bağlam sunar.

Neden önemli?

Verilerin güncelliği hakkında bilgi verir. Bu, mevcut en güncel süreç performansı bilgilerine dayanarak karar almak için önemlidir.

Nereden alınır?

Bu değer oluşturulur ve veri çıkarma sırasında veri setine zaman damgasıyla eklenir.

Örnekler
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
Atanan Ekip
AssignedTeam
Hizmet talebini şu anda ele almakla görevlendirilen destek ekibi veya grup.
Açıklama

Bu öznitelik, belirli bir anda hizmet talebine işlem yapan sorumlu ekibi belirler. Ekipler arasındaki devir teslimleri, her ekiple geçirilen süreyi ve farklı ekiplerin ele aldığı talep hacmini analiz etmek; iş yükü dağılımını anlamak, darboğazları belirlemek ve ekip performansını değerlendirmek için önemlidir. SLA uyumu ve temsilci iş yüküyle ilgili Dashboardları doğrudan destekler.

Neden önemli?

Sorumlulukları ve devirleri izleyerek ekipler arası gecikmeleri, iş yükü dengesini ve süreçte darboğaz oluşturan ekipleri analiz etmenize yardımcı olur.

Nereden alınır?

Bu bilgi genellikle Service Request nesnesindeki 'OwnerTeam' benzeri bir alanda veya ilgili atama kayıtlarında saklanır.

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

Atanan Temsilci, hizmet talebi üzerinde çalışmaktan sorumlu kişidir. Bu öznitelik, bireysel düzeyde analiz yapmanızı sağlar ve performans yönetimi, iş yükü dengesi ile eğitim ihtiyaçlarını belirlemek için kullanışlıdır. Temsilciler arasındaki yeniden atamaları izlemek, 'Talep Başına Ortalama Yeniden Atama' gibi KPI'ları hesaplamak ve süreçteki verimsizlikleri anlamak için önemlidir.

Neden önemli?

Bireysel iş yükünü, performansı ve yeniden atama örüntülerini analiz etmenizi sağlar. Bu veriler eğitim, beceri setleri veya ilk yönlendirmeyle ilgili sorunlara işaret edebilir.

Nereden alınır?

Genellikle Service Request nesnesindeki 'Owner' benzeri bir alanda bulunur. Her yeniden atamada değişebilir ve Event Log içinde izlenmelidir.

Örnekler
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
Çözüm Zaman Damgası
ResolutionDateTime
Hizmet talebinin resmi olarak çözüldüğü tarih ve saat.
Açıklama

Bu vaka düzeyindeki öznitelik, talep resmi olarak kapatılmadan önce hizmetin sunulduğu veya sorunun giderildiği son zaman damgasını gösterir. Bu zaman damgası, hizmet talebinin uçtan uca çevrim süresini hesaplamak için temel bitiş noktasıdır. Genel süreç verimliliğini ve SLA uyumluluğunu ölçmek için önemli bir bileşendir.

Neden önemli?

Ana süreç çevrim süresinin hesaplanacağı bitiş noktasını tanımlar ve hizmet sunumu verimliliği için önemli bir performans göstergesidir.

Nereden alınır?

Service Request nesnesindeki belirli bir zaman damgası alanıdır ve genellikle 'ResolvedDateTime' veya benzer bir adla bulunur.

Örnekler
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
Hizmet Talebi Durumu
ServiceRequestStatus
Olay gerçekleştiği sırada hizmet talebinin durumu.
Açıklama

Bu öznitelik, hizmet talebinin 'Kaydedildi', 'Devam Ediyor', 'Beklemede', 'Çözüldü' veya 'Kapatıldı' gibi durumunu gösterir. Durum değişiklikleri genellikle süreç günlüğündeki etkinlikleri tanımlar. Her durumda geçirilen süreyi analiz etmek, örneğin taleplerin 'Beklemede' durumunda çok uzun kalması gibi darboğazları ortaya çıkarabilir.

Neden önemli?

Herhangi bir anda talebin durumunu gösteren bir anlık görünüm sunar. Bu bilgi, belirli durumlarda geçirilen süreyi hesaplamak ve süreçteki tıkanmaları belirlemek için gereklidir.

Nereden alınır?

Service Request nesnesindeki standart bir alandır ve genellikle 'Status' olarak adlandırılır.

Örnekler
KaydedildiAktifMüşteriden yanıt bekleniyorYerine getirildiKapatıldı
Hizmet Talebi Türü
ServiceRequestType
Hizmet talebinin sınıflandırması veya kategorisi.
Açıklama

Bu öznitelik, hizmet talebini örneğin 'Donanım Talebi', 'Yazılım Kurulumu' veya 'Parola Sıfırlama' olarak kategorilere ayırır. Ekiplerin farklı hizmet türlerinde süreç performansını, çevrim sürelerini ve SLA uyumluluğunu karşılaştırmasına imkan veren önemli bir analiz boyutudur. Bu farklılıkları anlamak, süreç iyileştirmelerini ihtiyaca göre şekillendirmenize ve kaynakları daha verimli dağıtmanıza yardımcı olur.

Neden önemli?

Süreci talep türüne göre segmentlere ayırmak, hedefli analiz yapmanızı sağlar. Böylece belirli talep türlerinin gecikmeye, yeniden çalışmaya veya SLA ihlallerine daha yatkın olup olmadığını görebilirsiniz.

Nereden alınır?

Muhtemelen Service Request iş nesnesindeki bir alandır ve genellikle 'Service' veya 'Category' olarak adlandırılır. 'SvcReqTmplLink_Category' gibi belirli alan adları için Ivanti Service Manager belgelerine başvurun.

Örnekler
Yeni donanım talebiYazılım erişimiHesap değişikliğiBilgi talebi
Olay Bitiş Zamanı
EventEndTime
Bir etkinliğin tamamlandığı zamanı gösteren zaman damgası.
Açıklama

Olay Bitiş Zamanı, bir etkinliğin tamamlandığını gösterir. Olay Zamanı (başlangıç) ile Olay Bitiş Zamanı arasındaki süre, ilgili etkinliğin işlem süresini ifade eder. Bu bilgi, süreçte en fazla zaman alan adımları belirlemek, verimsizlikleri ve iyileştirme alanlarını ortaya çıkarmak için büyük önem taşır.

Neden önemli?

Her bir etkinliğin süresini hesaplamanızı sağlar. Bu, süreç darboğazlarını ve uzun süren görevleri belirlemek için gereklidir.

Nereden alınır?

Ayrı bir alan olarak bulunmayabilir. Çoğu zaman aynı vaka içindeki bir sonraki etkinliğin başlangıç zamanıdır.

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

Öncelik, bir hizmet talebinin aciliyetini gösterir ve genellikle 'Düşük', 'Orta', 'Yüksek' veya 'Kritik' gibi seviyelerden oluşur. Bu öznitelik, sürecin yüksek öncelikli talepleri gerçekten öne alıp almadığını değerlendirmek için temel bir göstergedir. Analizde genellikle farklı öncelik seviyelerindeki çevrim süreleri ve SLA uyumluluğu karşılaştırılarak önceliklendirme kurallarının beklendiği gibi çalışıp çalışmadığı kontrol edilir.

Neden önemli?

Önceliklendirme stratejisinin ne kadar etkili olduğunu değerlendirmek ve yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı çözüldüğünden emin olmak için önemlidir.

Nereden alınır?

Service Request nesnesindeki standart bir alandır ve genellikle 'Priority' olarak adlandırılır.

Örnekler
1 - Kritik2 - Yüksek3 - Orta4 - Düşük
SLA Durumu
SLAStatus
Hizmet talebinin SLA son tarihi içinde çözülüp çözülmediğini gösterir.
Açıklama

Bu, her hizmet talebini çözüm süresinin SLA son tarihiyle karşılaştırılmasına göre "Met" veya "Breached" olarak işaretleyen türetilmiş bir özniteliktir. SLA Adherence Performance Dashboardunun ve Service Level Agreement Adherence Rate KPI’ının temelini oluşturur. Mantık, her vaka için ResolutionDateTime ile SLADeadline alanlarını karşılaştırır.

Neden önemli?

Performansı hizmet taahhütlerine göre doğrudan ölçer. Bu, hizmet kalitesini değerlendirmek ve kullanıcı güvenini korumak için önemlidir.

Nereden alınır?

'ResolutionDateTime' ile 'SLADeadline' karşılaştırılarak hesaplanır. ResolutionDateTime <= SLADeadline ise durum 'Karşılandı', aksi halde 'İhlal Edildi' olur.

Örnekler
Karşılandıİhlal edildi
SLA Son Tarihi
SLADeadline
Hizmet talebinin çözülmesinin beklendiği son zaman damgası.
Açıklama

SLA Son Tarihi, bir hizmet talebinin Service Level Agreement koşulları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 zamanının bu son tarihle karşılaştırılması, SLA uyumluluğunun ölçülmesini sağlar.

Neden önemli?

Gerçek performansın ölçüldüğü referans noktasıdır. SLA uyumluluk oranlarını hesaplamayı ve risk altındaki talepleri belirlemeyi doğrudan destekler.

Nereden alınır?

Bu değer genellikle Ivanti içinde hesaplanan bir alandır ve 'ResolutionTargetDateTime' gibi Service Level Agreement veya Offering ile ilgili alanlarda saklanır.

Örnekler
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
Atama Sayısı
AssignmentCount
Bir hizmet talebinin atandığı veya yeniden atandığı toplam sayı.
Açıklama

Bu hesaplanan metrik, her hizmet talebi için atamayla ilgili etkinliklerin, örneğin 'Ekibe Atandı' ve 'Temsilciye Atandı' etkinliklerinin sayısını hesaplar. Genellikle 'ticket ping-pong' olarak adlandırılan yüksek yeniden atama sayısı, yönlendirmedeki verimsizliklere, ilk temas çözümünün yetersizliğine veya ekip sorumluluklarının net olmamasına işaret eder. Bu öznitelik, 'Talep Başına Ortalama Yeniden Atama' KPI'ı için gereklidir.

Neden önemli?

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

Nereden alınır?

Veri hazırlama sırasında her benzersiz ServiceRequestID için atamayla ilgili etkinliklerin gerçekleşme sayısı hesaplanarak elde edilir.

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

Çözüm Kategorisi, bir hizmet talebinin nasıl çözüldüğünü yapılandırılmış biçimde sınıflandırır. Bu sınıflandırma genellikle kök neden analizi ve eğilim raporlaması için kullanılan hiyerarşik bir yapıdadır, örneğin Kategori ve Alt Kategori. Tekrarlanan sorunları veya yaygın karşılama işlemlerini ortaya çıkararak hizmetleri iyileştirmenize ya da bilgi bankası makaleleri oluşturmanıza yardımcı olabilir.

Neden önemli?

Çözümlerin niteliği hakkında içgörü sağlar; yaygın sorunları, hizmet iyileştirme fırsatlarını ve otomasyona uygun adayları belirlemenize yardımcı olur.

Nereden alınır?

Genellikle çözüm sırasında doldurulan 'ResolutionCategory' gibi sınıflandırma alanlarında veya özel bir kapatma kodu alanında saklanır.

Örnekler
Kullanıcı eğitimi gerekliYazılım dağıtıldıDonanım onarıldıErişim verildi
Kanal
Channel
Hizmet talebinin gönderildiği yöntem veya kanal.
Açıklama

Kanal, hizmet talebinin nasıl oluşturulduğunu gösterir. Örneğin talep Self-Service Portal, e-posta veya telefon üzerinden gönderilmiş ya da başka bir sistem tarafından otomatik olarak oluşturulmuş olabilir. Talep hacimlerini ve çözüm sürelerini kanala göre analiz etmek, hangi kanalların daha verimli olduğunu ve hangilerinde süreç iyileştirmesi veya kullanıcı eğitimi gerektiğini gösterebilir.

Neden önemli?

Kullanıcı davranışını ve kanal verimliliğini anlamanıza yardımcı olur. Bu bilgiler, hizmet sunumu stratejisi ve otomasyon fırsatlarıyla ilgili kararları destekler.

Nereden alınır?

Bu bilgi genellikle Service Request nesnesindeki 'Source' veya 'CreatedBy' türünde bir alanda saklanır.

Örnekler
Self servisE-postaTelefonDoğrudan giriş
Talep Eden Departman
RequestorDepartment
Hizmet talebini gönderen kullanıcının bağlı olduğu iş departmanı.
Açıklama

Bu öznitelik, 'Satış', 'Finans' veya 'İnsan Kaynakları' gibi hizmet talebini başlatan çalışanın ya da sistemin departmanını gösterir. Kurumun farklı bölümlerindeki hizmet kalitesini ve talep yoğunluğunu analiz etmenizi sağlar. Örneğin belirli departmanların daha uzun çözüm süreleri yaşayıp yaşamadığını veya daha fazla talep gönderip göndermediğini belirlemenize yardımcı olur.

Neden önemli?

Hizmet tüketimini ve kalitesini iş birimine göre analiz etmenizi sağlar. Böylece departmana özgü sorunları veya eğilimleri belirleyebilirsiniz.

Nereden alınır?

Bu bilgi genellikle talep sahibinin Service Request ile ilişkilendirilmiş kullanıcı profilinden alınır. Alan, Profile.Employee nesnesinde 'Department' olarak adlandırılabilir.

Örnekler
FinansSatışPazarlamaBilgi Teknolojileri
Tedarikçi Adı
VendorName
Talebin çözümüne dahil olan harici tedarikçinin adı.
Açıklama

Bu öznitelik, bir hizmet talebine yardımcı olmak veya talebi tamamlamak üzere görevlendirilen üçüncü taraf tedarikçiyi belirler. Farklı tedarikçilerin performansını ölçmeyi ve karşılaştırmayı sağladığı için External Vendor Activity Duration Dashboardu açısından önemlidir. Bu bilgiyi izlemek, 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ı ve bu performansın genel hizmet talebi çözüm sürelerine etkisini analiz etmenizi sağlar. Tedarikçi yönetimini destekler.

Nereden alınır?

Hizmet talebiyle ilişkilendirilmiş bir görev nesnesindeki alan olabilir. Tedarikçi atanmışsa Service Request nesnesinde de özel bir alan olarak bulunabilir.

Örnekler
Dell DesteğiOracle DanışmanlığıMicrosoft Premiernull
Yeniden Açılma Sayısı
ReopenCount
Çözüldükten sonra yeniden açılan bir hizmet talebinin yeniden açılma sayısı.
Açıklama

Bu öznitelik, bir hizmet talebi 'Çözüldü' veya 'Kapatıldı' durumundan 'Aktif' durumuna her döndüğünde artan bir sayaçtır. Yüksek yeniden açılma sayısı, ilk seferde çözüm kalitesinin düşük olduğuna, çözümlerin eksik kaldığına veya sorunların tekrarlandığına işaret eder. 'Hizmet Talebi Yeniden Çalışma Oranı' KPI'ını doğrudan destekler.

Neden önemli?

Yeniden çalışmayı doğrudan ölçer ve çözüm kalitesinin önemli bir göstergesidir. Yüksek değerler, ilk çözümün etkili olmadığını gösterir.

Nereden alınır?

Genellikle Service Request nesnesindeki bir sayaç alanıdır. Durum uygun şekilde değiştiğinde bir iş kuralı tarafından artırılır ve 'ReopenCounter' olarak adlandırılabilir.

Örnekler
0123
Yeniden Çalışma Var mı
IsRework
Hizmet talebinde yeniden çalışma etkinlikleri bulunup bulunmadığını gösteren boolean işareti.
Açıklama

Bu hesaplanan işaret, bir hizmet talebinin çözümden sonra yeniden açılması veya belirli etkinliklerin bir döngü içinde tekrarlanması gibi yeniden çalışma belirtileri göstermesi durumunda true olarak ayarlanır. Service Request Rework Rate KPI’ının hesaplanmasını kolaylaştırır ve Rework and Reassignment Flows gibi Dashboardlarda verimsiz süreç örneklerinin filtrelenmesine yardımcı olur.

Neden önemli?

Ek ve planlanmamış çaba gerektiren taleplerin hacmini kolayca belirleyip ölçmenizi sağlar. Böylece kalite ve verimlilik sorunlarını görünür kılar.

Nereden alınır?

Verilerden türetilir. Mantık, 'ReopenCount' özniteliğinin sıfırdan büyük olmasına veya 'Temsilciye Atandı' gibi belirli etkinlik dizilerinin birden fazla kez gerçekleştiğinin algılanmasına dayanabilir.

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

Hizmet Talebi Yönetimi Aktiviteleri

Doğru süreç keşfi ve analiz için Event Logunuzda kaydetmeniz gereken temel süreç adımları ve kilometre taşları aşağıdadır.
5 Önerilen 9 İsteğe bağlı
Aktivite Açıklama
Hizmet Talebi Çözüldü
Hizmet talebi çözülmüş kabul edilir ve çözüm kullanıcıya sunulmuştur. Bu, 'Resolved' durumuna geçişle kaydedilen temel bir kilometre taşıdır ve çoğu zaman SLA sayacını durdurur.
Neden önemli?

Bu, çözüm süresini ve SLA uyumluluğunu ölçmek için önemli bir bitiş noktasıdır. Oluşturma ile bu faaliyet arasında geçen süre, süreç performansının temel KPI'larından biridir.

Nereden alınır?

Hizmet Talebi kaydındaki 'Status' alanının ilgili zaman damgasıyla birlikte 'Resolved' olarak değiştirilmesinden anlaşılır.

Yakalayın

Denetim geçmişinden 'Status' alanının 'Resolved' olarak güncellendiğinin tespit edilmesi.

Olay türü inferred
Hizmet Talebi Kapatıldı
Hizmet talebi resmi olarak kapatılmıştır ve başka işlem yapılamaz. Bu durum çoğu zaman talebin 'Resolved' durumunda belirli bir süre kalmasından sonra otomatik olarak gerçekleşir ve yaşam döngüsünün nihai sonucunu gösterir.
Neden önemli?

Bu faaliyet sürecin kesin bitişidir. 'Resolved' ile 'Closed' arasında geçen süre, onay veya otomatik sistem işlemlerindeki gecikmeleri gösterebilir.

Nereden alınır?

Hizmet Talebi kaydındaki 'Status' alanının ilgili zaman damgasıyla birlikte 'Closed' olarak değiştirilmesinden anlaşılır.

Yakalayın

Denetim geçmişinden 'Status' alanının 'Closed' olarak güncellendiğinin tespit edilmesi.

Olay türü inferred
Hizmet Talebi Oluşturuldu
Bu faaliyet, yeni bir talebin resmi olarak gönderilip Ivanti'ye kaydedilmesiyle hizmet talebi yaşam döngüsünün başlangıcını gösterir. Service Request iş nesnesinde yeni bir kayıt oluşturulduğunda ve benzersiz bir Hizmet Talebi Kimliği üretildiğinde bu olay kaydedilir.
Neden önemli?

Bu, sürecin birincil başlangıç olayıdır. Bu noktadan çözüme kadar geçen süreyi analiz etmek, toplam çevrim süresini ve süreç verimliliğini ölçmenin temelidir.

Nereden alınır?

Bu bilgi, Hizmet Talebi kaydının oluşturulma zaman damgasından alınır. Örneğin ServiceReq iş nesnesindeki CreatedDateTime alanı.

Yakalayın

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

Olay türü explicit
Talep Ekibe Atandı
Hizmet talebi, işlenmesi için belirli bir destek ekibine atanır. Bu durum, Hizmet Talebi kaydındaki 'OwnerTeam' alanının doldurulması veya değiştirilmesi izlenerek 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 önemlidir. Süreçte hangi ekiplerin darboğaz oluşturduğunu belirlemeye yardımcı olur.

Nereden alınır?

Hizmet Talebi denetim geçmişinde veya günlüğünde 'OwnerTeam' alanındaki değişiklikler izlenerek kaydedilir.

Yakalayın

Genellikle denetim izinde kaydedilen 'OwnerTeam' alanı güncelleme olayı.

Olay türü explicit
Talep Temsilciye Atandı
Belirli bir temsilci hizmet talebinin sorumluluğunu alır. Bu faaliyet, kişisel temsilciyi belirleyen 'Owner' alanının ilk kez doldurulması veya güncellenmesiyle anlaşılır.
Neden önemli?

Bu etkinlik, ilk bekleme veya kuyruk süresinin sona erdiğini gösterir. Bu etkinlikten önce geçen süreyi ölçmek, kaynak dağılımı sorunlarını belirlemeye yardımcı olur ve Agent Workload Dashboardunu destekler.

Nereden alınır?

Hizmet Talebi kaydındaki 'Owner' alanının doldurulması veya değiştirilmesinden, denetim geçmişinde görüldüğü şekilde anlaşılır.

Yakalayın

Oluşturma veya ekip atamasından sonra 'Owner' alanının bir temsilci adıyla ilk kez doldurulduğu zaman damgası.

Olay türü inferred
Bilgi Kullanıcı Tarafından Sağlandı
Talep sahibi gerekli bilgileri sağlamıştır ve temsilcinin çalışmaya devam etmesine imkan verir. Talep 'Waiting for Customer' durumundan etkin bir duruma geçtiğinde bu olay kaydedilir.
Neden önemli?

Bu olay, bilgi taleplerinin döngüsünü tamamlar. Bilginin istenmesiyle alınması arasında geçen süre, süreç gecikmelerinin ve yeniden işleme döngülerinin önemli bir bölümünü oluşturur.

Nereden alınır?

Hizmet Talebi kaydındaki 'Status' alanının 'Waiting for Customer' durumundan 'Active' veya 'In Progress' gibi etkin bir duruma değişmesiyle anlaşılır.

Yakalayın

'waiting on user' durumundan etkin bir duruma geçişin tespit edilmesi.

Olay türü inferred
Harici Tedarikçi Sürece Dahil Oldu
Hizmet talebinin karşılanması harici bir tedarikçiye veya üçüncü tarafa devredilmiştir. Bu durum genellikle 'Waiting for 3rd Party' veya benzer bir duruma geçişle kaydedilir.
Neden önemli?

Bu etkinlik, tedarikçi performansını ve bunun genel çevrim süresine etkisini ölçmek için önemlidir. Tedarikçi kaynaklı gecikmelerin analiz edilmesini sağlar ve External Vendor Activity Duration Dashboardunu destekler.

Nereden alınır?

Hizmet Talebi kaydındaki durumun 'Waiting for 3rd Party' veya 'Pending Vendor' gibi bir duruma değiştirilmesinden anlaşılır.

Yakalayın

'Status' alanının belirlenmiş bir 'waiting on vendor' durumuna değiştirilmesiyle tespit edilir.

Olay türü inferred
Hizmet Talebi İptal Edildi
Hizmet talebi, çözümden önce kullanıcı veya temsilci tarafından iptal edilmiştir. Bu, 'Cancelled' veya 'Withdrawn' durumuna geçişle kaydedilen alternatif bir bitiş durumudur.
Neden önemli?

Bu durum, standart dışı bir süreç sonlandırmasını gösterir. Taleplerin neden iptal edildiğini analiz etmek, talep sürecindeki sorunları veya değişen kullanıcı ihtiyaçlarını ortaya çıkarabilir.

Nereden alınır?

Hizmet Talebi kaydındaki 'Status' alanının 'Cancelled' olarak değiştirilmesinden anlaşılır.

Yakalayın

Denetim geçmişinden 'Status' alanının 'Cancelled' olarak güncellendiğinin tespit edilmesi.

Olay türü inferred
Hizmet Talebi Karşılandı
Hizmet talebini karşılamak için gereken tüm görevler temsilci veya sistem tarafından tamamlanmıştır. Bu durum, çoğu zaman son 'Resolved' durumundan önce gelen 'Fulfilled' durumuna geçişle kaydedilir.
Neden önemli?

Bu kilometre taşı, teknik veya prosedürel çalışmanın tamamlandığını gösterir. Son onay ve kapatma öncesindeki aktif işlem süresini ölçmek için önemli bir noktadır.

Nereden alınır?

Hizmet Talebi kaydındaki 'Status' alanının 'Fulfilled' olarak değiştirilmesinden anlaşılır.

Yakalayın

Kayıt geçmişinden tespit edilen, 'Status' alanının 'Fulfilled' olarak değiştirilmesi.

Olay türü inferred
Hizmet Talebi Yeniden Açıldı
Daha önce çözülmüş bir hizmet talebi, sorun devam ettiği veya çözüm yetersiz kaldığı için yeniden etkinleştirilmiştir. Durum 'Resolved' durumundan 'Active' veya 'Assigned' gibi etkin bir duruma geçtiğinde bu olay kaydedilir.
Neden önemli?

Bu faaliyet, yeniden işlemenin ve ilk seferde çözüm kalitesinin düşük olduğunun doğrudan göstergesidir. Yeniden açma olaylarını analiz etmek, süreç zayıflıklarını belirlemeye ve Hizmet Talebi Yeniden İşleme Oranı KPI'ını iyileştirmeye yardımcı olur.

Nereden alınır?

Denetim geçmişinde 'Status' alanının 'Resolved' veya 'Closed' durumundan etkin bir duruma değişmesiyle anlaşılır.

Yakalayın

Terminal bir durumdan ('Resolved', 'Closed') açık bir duruma ('Active', 'Assigned') geçiş.

Olay türü inferred
Kullanıcıdan Bilgi İstendi
Atanan temsilcinin talebi karşılamaya devam edebilmesi için talep sahibinden daha fazla bilgiye ihtiyacı vardır. Bu durum, talep durumu 'Waiting for Customer' gibi bir duruma güncellendiğinde kaydedilir.
Neden önemli?

Bu faaliyet, başlangıç bilgilerinin eksik olmasından kaynaklanan gecikmeleri gösterir. Sıklığını ve süresini izlemek, Bilgi Talebi Etki Analizi için ve süreç iyileştirme alanlarını belirlemek açısından önemlidir.

Nereden alınır?

Hizmet Talebi kaydındaki durumun 'Waiting for Customer' veya 'Pending' gibi bir duruma değiştirilmesinden anlaşılır.

Yakalayın

'Status' alanının belirlenmiş bir 'waiting on user' durumuna değiştirilmesiyle tespit edilir.

Olay türü inferred
Öncelik Değiştirildi
Hizmet talebinin önceliği, ilk oluşturulmasından sonra güncellenmiştir. Bu olay, alan düzeyindeki değişiklikleri izleyen denetim günlüğünden veya geçmişten alınır.
Neden önemli?

Öncelik değişikliklerini izlemek, Önceliklendirme Etkinliği Genel Görünümü için önemlidir. Eskalasyonların doğru yönetilip yönetilmediğini ve ilk önceliklendirmenin doğru olup olmadığını belirlemeye yardımcı olur.

Nereden alınır?

Bu, Hizmet Talebi kaydının denetim geçmişinden alınan açık bir olaydır. Geçmiş, 'Priority' alanındaki değişiklikleri kaydeder.

Yakalayın

Sistemin denetim izinde kaydedilen 'Priority' alanı güncelleme olayı.

Olay türü explicit
Talep Onaya Gönderildi
Hizmet talebi, karşılanabilmesi için gerekli onaylara gönderilmiştir. Bu durum genellikle talep durumu "Submitted" veya "Pending Approval" olarak değiştiğinde ve çoğu zaman bir onay iş akışı başlatıldığında anlaşılır.
Neden önemli?

Bu faaliyeti izlemek, onay aşamasındaki gecikmeleri belirlemeye yardımcı olur. Buradaki uzun beklemeler önemli bir darboğaz oluşturarak toplam çözüm sürelerini ve kullanıcı memnuniyetini etkileyebilir.

Nereden alınır?

Hizmet Talebi kaydındaki durum değişikliğinden, büyük olasılıkla 'Submitted' veya 'Waiting for Approval' gibi bir duruma geçişten anlaşılır. Bu bilgi FRS_Approval veya FRS_ApprovalVoteTracking iş nesnelerinden de alınabilir.

Yakalayın

Hizmet Talebi kaydındaki 'Status' alanının onay bekleyen bir duruma değiştirilmesi.

Olay türü inferred
Talep Onaylandı
Hizmet talebi gerekli tüm onayları almıştır ve artık 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 faaliyet önemli bir kilometre taşını gösterir. Onay aşamasının sona erdiğini ve karşılama aşamasının başladığını belirtir. Ayrıca onay sürecinin verimliliğinin ölçülmesini sağlar.

Nereden alınır?

'Waiting for Approval' durumundan 'Approved' veya 'Fulfilled' durumuna geçişten anlaşılır. Bu, FRS_Approval iş nesnesinde açıkça kaydedilmiş bir olay olarak da bulunabilir.

Yakalayın

Hizmet Talebi kaydındaki 'Status' alanının bir onay durumundan etkin bir duruma değiştirilmesi.

Olay türü inferred
Önerilen İsteğe bağlı

Veri çıkarma rehberleri

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

Başlamaya hazır mısınız?

Bu ayrıntılı veri şablonuyla hizmet talebi yönetimi sürecinizin tüm potansiyelinden yararlanın. Operasyonlarınızı bugün iyileştirmeye başlayın.

Hizmet talebi yönetiminizi bugün optimize etmeye başlayın

Yavaş talep karşılamaya son verin, kullanıcı memnuniyetsizliğini azaltın ve %70 otomasyon oranına ulaşın.

Ücretsiz denemenizi başlatın

Kredi kartı gerekmez, kurulumu dakikalar içinde tamamlayın.