Hizmet Talebi Yönetimi Veri Template'inuz
Hizmet Talebi Yönetimi Veri Template'inuz
- Detaylı analiz için önerilen özellikler
- Süreç keşfi için izlenecek temel aktiviteler
- Kaynak sisteminizden veri çekme konusunda rehberlik.
Hizmet Talep Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite Adı
ActivityName
|
Servis talebi süreç 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 Hizmet 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 büyük önem taşır.
Neden Önemli?dir?
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 sunar.
Nereden Alınır??
Genellikle Ivanti Service Management içindeki durum değişiklikleri, günlük girişleri veya denetim logu olay açıklamalarından türetilir.
Örnekler:::::::
Hizmet Talebi OluşturulduTalep OnaylandıBT Hizmet Talebi Yönetimi ÇözüldüBT Hizmet Talebi Yönetimi Kapatıldı
|
|||
|
Hizmet Talebi Kimliği
ServiceRequestID
|
Her hizmet 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 sunar.
Neden Önemli?dir?
Bu, tüm ilgili aktiviteleri tek bir süreç örneğine bağlayan temel vaka (case) tanımlayıcısıdır ve uçtan uca süreç analizine sunar.
Nereden Alınır??
Bu, Servis Talep iş nesnesinin birincil anahtarıdır ve genellikle ServiceReq tablosunda ServiceReqNumber olarak bulunur.
Örnekler:::::::
SR-001, 2, 3, 45SR-001, 2, 3, 46SR-001, 2, 3, 47
|
|||
|
Olay Zamanı
EventTime
|
Belirli bir faaliyetin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Neden Önemli?dir?
Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve performans analizi için anahtar olan tüm süreye dayalı metrikleri hesaplamak için gereklidir.
Nereden Alınır??
Denetim kayıtlarında, günlük girişlerinde (örn. Journal.CreatedDateTime) veya BT Hizmet Talebi Yönetimi 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
|
|||
|
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 Management'dan geldiğini gösterecektir. Bu, verilerin birden fazla sistemden birleştirilebileceği ortamlarda önemlidir ve net veri izlenebilirliği ve bağlam sunar.
Neden Önemli?dir?
Veri kökeni hakkında önemli bilgiler sunar, 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 Management
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Kaynak sistemden en son veri yenilemesinin zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu öznitelik, verilerin Ivanti Service Management'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ı sunar.
Neden Önemli?dir?
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 büyük önem taşır.
Nereden Alınır??
Bu değer,
Ö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 büyük önem taşır. SLA uyumu ve temsilci iş yükü ile ilgili panelleri doğrudan destekler.
Neden Önemli?dir?
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ı sunar. Temsilciler arasındaki yeniden atamaları takip etmek, 'Talep Başına Ortalama Yeniden Atama' gibi KPI'ları hesaplamak ve süreç verimsizliklerini anlamak için temel rol oynar.
Neden Önemli?dir?
Bireysel iş yükü, performans ve yeniden atama modellerinin analizini sunar; 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 BrownDiana Prince
|
|||
|
BT Hizmet Talebi Yönetimi 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 önemli 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 sunar. Bu farklılıkları anlamak, süreç iyileştirmelerini uyarlamaya ve kaynakları daha etkili bir şekilde tahsis etmeye yardımcı olur.
Neden Önemli?dir?
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 Management dokümantasyonuna başvurun.
Örnekler:::::::
Yeni Donanım TalebiYazılım ErişimiHesap DeğişikliğiBilgi Sorgulama
|
|||
|
Çö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ı (zaman damgası)nı işaretleyen vaka düzeyinde bir özniteliktir. Bu zaman damgası (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?dir?
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ı (zaman damgası) alanı.
Örnekler:::::::
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Olay Bitiş Zamanı
EventEndTime
|
Bir aktivitenin tamamlandığını gösteren zaman damgası (zaman damgası)dır. | ||
|
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 büyük önem taşır.
Neden Önemli?dir?
Bireysel etkinlik sürelerinin hesaplanmasını sunar, bu da süreç darboğazlarını ve uzun süren görevleri belirlemek için büyük önem taşır.
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 büyük önem taşır. 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?dir?
Önceliklendirme stratejisinin etkinliğini değerlendirmek ve yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı çözülmesini güçlüak için büyük önem taşır.
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?dir?
Talebin herhangi bir zamandaki durumunun anlık görüntüsünü sunar, bu da belirli durumlarda geçirilen süreyi hesaplamak ve süreç duraklamalarını belirlemek için gereklidir.
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ı (zaman damgası)dır. | ||
|
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?dir?
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ı' kontrol paneli'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?dir?
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 büyük önem taşır.
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 gereklidir.
Neden Önemli?dir?
Verimsiz devir ve yönlendirme sorunlarını ölçülmesini sağlar. 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?dir?
Çözümlerin niteliğine dair stratejik bilgiler sunar, 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
|
Hizmet 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 stratejik bilgiler sağlayabilir.
Neden Önemli?dir?
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-ServiceE-postaTelefonDoğrudan Giriş
|
|||
|
Talep Eden 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 sunar. Ö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?dir?
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, Hizmet 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' kontrol paneli'u için gereklidir, çünkü farklı tedarikçilerin performansını ölçmeye ve karşılaştırmaya sunar. 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?dir?
Üçüncü taraf performansının ve genel hizmet talebi çözüm süreleri üzerindeki etkilerinin analizini sunar, 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 Hizmet 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ışanşma Oranı' KPI'ını doğrudan destekler.
Neden Önemli?dir?
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 değeri. | ||
|
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ışanşma Oranı' KPI'ının hesaplanmasını basitleştirir ve 'Yeniden Çalışanşma ve Yeniden Atama Akışları' gibi kontrol paneli'larda verimsiz süreç örneklerini filtrelemeye yardımcı olur.
Neden Önemli?dir?
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
|
|||
Hizmet Talep Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
BT Hizmet Talebi Yönetimi Çö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?dir?
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ı (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
|
|||
|
BT Hizmet Talebi Yönetimi 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 süreç döngüsünün nihai sonucunu temsil eder. | ||
|
Neden Önemli?dir?
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ı (zaman damgası)ndan çıkarılır.
Yakala
Denetim geçmişinden 'Durum' alanının 'Kapalı' olarak güncellenmesinin tespit edilmesi.
Event tipi
inferred
|
|||
|
Hizmet Talebi Oluşturuldu
|
Bu aktivite, yeni bir talebin resmi olarak gönderildiği ve Ivanti'ye kaydedildiği servis talebi süreç döngüsünün başlangıcını işaret eder. Bu olay, Hizmet Talebi iş nesnesinde yeni bir kayıt oluşturulduğunda ve benzersiz bir Servis Talep ID'si üretildiğinde yakalanır. | ||
|
Neden Önemli?dir?
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 büyük önem taşır.
Nereden Alınır??
Bu, Hizmet Talebi kaydının oluşturulma zaman damgası (zaman damgası)ndan (örneğin, ServiceReq iş nesnesindeki CreatedDateTime alanı) yakalanır.
Yakala
ServiceReq tablosundaki kayıt oluşturma olayı, oluşturulma zaman damgası (zaman damgası)yla tanımlanır.
Event tipi
explicit
|
|||
|
Talep Ekibe Atandı
|
Servis talebi, işlenmek üzere belirli bir destek ekibine atanır. Bu, Hizmet Talebi kaydındaki 'Sahip Ekibi' alanının doldurulması veya değişmesi gözlemlenerek kaydedilir. | ||
|
Neden Önemli?dir?
Bu olay, ekip düzeyindeki performansı, iş yükü dağılımını ve ekipler arası devir sürelerini analiz etmek için büyük önem taşır. Süreçte hangi ekiplerin darboğaz olduğunu belirlemeye yardımcı olur.
Nereden Alınır??
Hizmet 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?dir?
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ü kontrol paneli'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ı (zaman damgası)dır.
Event tipi
inferred
|
|||
|
BT Hizmet Talebi Yönetimi 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?dir?
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
|
|||
|
BT Hizmet Talebi Yönetimi 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?dir?
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ışanş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
|
|||
|
Dış 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?dir?
Bu aktivite, tedarikçi performansını ve bunun genel döngü süresi üzerindeki etkisini ölçmek için gereklidir. Tedarikçi kaynaklı gecikmelerin analizine sunar ve Harici Tedarikçi Aktivite Süresi kontrol paneli'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 İ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?dir?
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
|
|||
|
Kullanıcı Tarafından Sağlanan Bilgi
|
Talep sahibi gerekli bilgiyi güçlüış 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?dir?
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??
BT Hizmet Talebi Yönetiminin '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 İstendi
|
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?dir?
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 temel rol oynar.
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?dir?
Öncelik değişikliklerini takip etmek, Önceliklendirme Etkinliği Genel Bakışı için büyük önem taşır. 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 Hizmet 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
|
|||
|
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?dir?
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?dir?
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 sunar.
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
|
|||