Hizmet Talebi Yönetimi Veri Template'inuz
Hizmet Talebi Yönetimi Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- BMC Helix ITSM için veri çekim rehberliği
Hizmet Talep Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Hizmet talebi süreç döngüsünde belirli bir zamanda meydana gelen belirli bir olay veya görevin adı. | ||
|
Açıklama
Bu nitelik, hizmet talebi sürecindeki 'Talep İnceleniyor', 'Tamamlama Devam Ediyor' veya 'BT Hizmet Talebi Yönetimi Çözüldü' gibi belirli bir adımı veya durum değişikliğini tanımlar. Her aktivite, bir hizmet talebinin uçtan uca yolculuğunda tek bir olayı temsil eder. Aktivitelerin sırasını ve sıklığını analiz etmek, süreç madenciliğinin çekirdeğidir. Süreç haritalarının keşfedilmesine, darboğazların belirlenmesine ve süreç varyantlarının analizine sunar. Hangi aktivitelerin, hangi sırayla ve ne sıklıkla gerçekleştiğini anlamak, süreç optimizasyonu için büyük önem taşır.
Neden Önemli?dir?
Nereden Alınır??
Bu, genellikle 'SRM:Request' formundaki 'Durum' ve 'Durum Nedeni' alanlarındaki değişikliklerden veya ilgili tamamlama uygulama günlüklerinden (örn. Olay, İş Emri) türetilir.
Örnekler:::::::
Talep Onay BekliyorYerine Getirme Devam EdiyorBT Hizmet Talebi Yönetimi ÇözüldüBT Hizmet Talebi Yönetimi Kapatıldı
|
|||
|
Başlangıç Zamanı
EventStartTime
|
Belirli bir aktivite veya olayın ne zaman başladığını gösteren zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu nitelik, bir aktivitenin başladığı tam tarih ve saati kaydeder. Günlükteki her olayın, ilk gönderimden nihai kapanışa kadar, sürecin kronolojik sırasını oluşturmak için bir başlangıç zamanına sahip olması gerekir. Bu zaman damgası (zaman damgası), tüm zaman tabanlı süreç madenciliği analizleri için büyük önem taşır. Döngü sürelerini, aktivitelerin sürelerini, adımlar arasındaki bekleme sürelerini hesaplamak ve SLA uyumluluğunu kontrol etmek için kullanılır. Darboğazların keşfedilmesini ve süreç performansının zaman içindeki analizini sunar.
Neden Önemli?dir?
Başlangıç zamanı, süreç sürelerini hesaplamak, gecikmeleri belirlemek ve süreç zaman çizelgesini anlamak için gerekli olan olayların kronolojik sırasını sunar.
Nereden Alınır??
Bu, 'SRM:Request' formuyla ilişkili denetim günlüklerindeki veya durum geçmişi tablolarındaki zaman damgası (zaman damgası) alanlarına, örneğin ilk olay için 'Gönderim Tarihi'ne karşılık gelir.
Örnekler:::::::
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Hizmet Talebi Kimliği
ServiceRequestId
|
Her hizmet talebi için benzersiz tanımlayıcı, tüm süreç döngüsünü takip etmek için birincil anahtar görevi görür. | ||
|
Açıklama
Hizmet Talep Kimliği, bir kullanıcı veya sistem tarafından gönderilen her bir hizmet talebini benzersiz bir şekilde tanımlar. İlk kayıttan nihai kapanışa kadar tüm sonraki olayları birbirine bağlayan merkezi bir bağ görevi görerek, her bir hizmet talebinin yolculuğunun eksiksiz, uçtan uca analizini sunar. Process Miningnde, bu Kimlik her bir vaka için aktivite dizisini yeniden yapılandırmak için gereklidir. Bu, aracın 'Talep Gönderildi', 'Talep Atandı' ve 'BT Hizmet Talebi Yönetimi Kapandı' gibi ilgili tüm olayları tek bir süreç örneğinde gruplandırmasına sunar ve tüm süreç analizinin temelini oluşturur.
Neden Önemli?dir?
Bu, temel vaka tanımlayıcıdır. Olmadan, bir hizmet talebinin tüm sürecini takip etmek imkansızdır, bu da süreç keşfi ve analizini olanaksız kılar.
Nereden Alınır??
Bu, genellikle BMC Helix ITSM'deki 'SRM:Request' formundaki 'InstanceId' veya 'Talep Numarası' alanıdır.
Örnekler:::::::
SR000010572931SR000010572932SR000010572933
|
|||
|
Kaynak Sistem
SourceSystem
|
Verinin çıkarıldığı sistemi tanımlar. | ||
|
Açıklama
Bu nitelik, süreç verilerinin kaynağını belirtir. Bu görünüm için, hizmet talepleriyle ilgili tüm olayların bu sistemden geldiğini belirtmek üzere statik olarak 'BMC Helix ITSM' olarak ayarlanacaktır. Birden fazla entegre sisteme sahip ortamlarda, bu alan veri soyunu anlamak ve verileri kaynağına göre bölümlendirmek için büyük önem taşır. Özellikle farklı platformlardan veri birleştirirken netlik ve izlenebilirlik sunar.
Neden Önemli?dir?
Nereden Alınır??
Bu, veri çıkarımı ve dönüştürme süreci sırasında eklenen statik bir değerdir, BMC Helix ITSM'nin kendisinde bir alan değildir.
Örnekler:::::::
BMC Helix ITSM
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
Bu süreç için verilerin kaynak sistemden son yenilenme zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bu nitelik, BMC Helix ITSM'den en son veri çıkarımının tarih ve saatini gösterir. Kullanıcılara analiz ettikleri verilerin güncelliği hakkında bilgi vererek, analizin kapsadığı zaman diliminden haberdar olmalarını sunar. Bu, herhangi bir süreç madenciliği kontrol paneli'u veya analizi için kritik bir meta veri niteliğidir. Kullanıcıların stratejik bilgilerin gerçek zamanlıya yakın verilere mi yoksa geçmiş bir anlık görüntüye mi dayandığını anlamalarına sunar, bu da çıkarılan sonuçların geçerliliğini ve alaka düzeyini etkiler.
Neden Önemli?dir?
Kullanıcıları
Nereden Alınır??
Bu zaman damgası (zaman damgası), veri çıkarma ve yükleme süreci sırasında oluşturulur ve eklenir.
Örnekler:::::::
2024-05-21T08:00:00Z
|
|||
|
Atanan Ekip
AssignedTeam
|
Hizmet talebine şu anda atanmış destek grubu veya ekibi. | ||
|
Açıklama
Bu nitelik, talebin ele alınmasından sorumlu işlevsel grubu tanımlar; örneğin, 'Yardım Masası', 'Ağ Ekibi' veya 'Veritabanı Yönetimi'. Bu alandaki bir değişiklik, ekipler arasında sorumluluk transferini işaret eder. Atanan ekibe dayalı analiz, ekip düzeyindeki darboğazları belirlemeye, ekipler arası el değiştirmeleri analiz etmeye ve farklı destek gruplarının verimliliğini değerlendirmeye yardımcı olur. İşin kuruluş içinde nasıl yönlendirildiğine dair kalıpları ortaya koyarak Talep Yeniden İşleme ve Yeniden Atama ile Ön Değerlendirme Verimliliği panelleri için temel rol oynar.
Neden Önemli?dir?
Farklı fonksiyonel gruplar arasındaki süreç akışının analizini sunar, yönlendirme verimsizliklerini belirlemeye ve ekip düzeyinde performansı ölçmeye yardımcı olur.
Nereden Alınır??
Bu, hizmet talebiyle ilişkili tamamlama kaydındaki (örn. İş Emri, Olay) 'Atanan Grup' alanına karşılık gelir.
Örnekler:::::::
Servis MasasıAltyapı DesteğiUygulama Destek Seviyesi 2
|
|||
|
Atanan Temsilci
AssignedAgent
|
Hizmet talebi üzerinde şu anda çalışmakla görevli olan bireysel kullanıcı. | ||
|
Açıklama
Bu nitelik, belirli bir zamanda talepten sorumlu özel BT temsilcisini veya destek personelini tanımlar. Tek bir talebin süreç döngüsü boyunca bu alandaki değişiklikler, bir el değiştirme veya yeniden atamayı gösterir. Bu nitelik, temsilci performansı ve iş yükü analizi için büyük önem taşır. Her temsilcinin kaç talep işlediğini, ortalama çözüm süresini ve yeniden atama sıklığını takip etmeye sunar. Bu veri, kaynak yönetimi ve eğitim fırsatlarının belirlenmesini destekler.
Neden Önemli?dir?
Atanan temsilciyi takip etmek, el değiştirmeleri analiz etmek, bireysel performansı ölçmek ve destek ekibi genelindeki iş yükü dağılımını anlamak için gereklidir.
Nereden Alınır??
Bu, hizmet talebiyle ilişkili tamamlama kaydındaki (örn. İş Emri, Olay) 'Atanan Kişi' veya 'Atanan' alanına karşılık gelir.
Örnekler:::::::
`Bob Smith`Alice Johnson`Charlie Brown
|
|||
|
Bitiş Zamanı
EventEndTime
|
Belirli bir faaliyetin veya olayın ne zaman tamamlandığını gösteren zaman damgası (zaman damgası)dır. | ||
|
Açıklama
Bitiş Zamanı, bir aktivitenin sonucunu işaret eder. ITSM sistemlerindeki birçok aktivite anlık durum değişiklikleri olsa da, bazılarının ölçülebilir bir süresi vardır. Bitiş Zamanı'na sahip olmak, bu tür aktivitelerin süresinin hassas bir şekilde hesaplanmasını sunar. Analizde, Bitiş Zamanı, bireysel aktiviteler için işlem süresini hesaplamak amacıyla Başlangıç Zamanı ile birlikte kullanılır. Bu, süreçte sadece aralarındaki bekleme süresi değil, hangi belirli görevlerin en çok zamanı tükettiğini belirlemeye yardımcı olur.
Neden Önemli?dir?
Nereden Alınır??
Bu türetilebilir. Bir aktivitenin Bitiş Zamanı, genellikle aynı vaka için bir sonraki sıralı aktivitenin Başlangıç Zamanıdır. Son aktivite için ise çözüm veya kapanış zaman damgası (zaman damgası) olacaktır.
Örnekler:::::::
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
|
|||
|
Öncelik
Priority
|
Hizmet talebine atanan öncelik düzeyi, iş üzerindeki etkisini ve aciliyetini gösterir. | ||
|
Açıklama
Öncelik, taleplerin ele alınması gereken sırayı ve hızı belirler. Yaygın değerler arasında 'Critical', 'High', 'Medium' ve 'Low' bulunur. Bu atama genellikle talebin iş üzerindeki etkisi ile aciliyetinin birleşimine dayanır. Önceliğe göre analiz yapmak, yüksek öncelikli taleplerin düşük öncelikli olanlardan daha hızlı işlenip işlenmediğini değerlendirmek için büyük önem taşır. Çözüm süresi ve SLA uyumluluğu için
Neden Önemli?dir?
Sürecin işi doğru şekilde önceliklendirip farklı iş etkisi seviyelerine sahip talepler için beklenen hizmet seviyelerini karşılayıp karşılamadığını değerlendirmeye yardımcı olur.
Nereden Alınır??
Bu, 'SRM:Request' formundaki 'Öncelik' alanıdır.
Örnekler:::::::
KritikYüksekOrtaDüşük
|
|||
|
Servis Tipi
ServiceType
|
Kullanıcının talep ettiği hizmetin kategorisi veya türü. | ||
|
Açıklama
Hizmet Türü, talebin doğasını sınıflandırır; örneğin, 'Yeni Yazılım Talep Et', 'Şifre Sıfırla' veya 'Yeni Çalışanşanı İşe Al'. Süreç verilerini filtrelemek ve segmentlere ayırmak için temel bir boyuttur. Süreç analizinde, bu nitelik farklı talep türlerinin performansını karşılaştırmak için kullanılır. 'Hangi hizmet türleri en uzun sürede çözülür?' veya 'Hangi hizmet türlerinde en çok tekrar iş vardır?' gibi soruları yanıtlamaya yardımcı olur. Bu, Çözüm Süresi ve SLA Uyumluluğu Dashboard'ları için büyük önem taşır.
Neden Önemli?dir?
Hizmet taleplerinin, süreç akışlarını karşılaştırmak, türe özgü sorunları belirlemek ve optimizasyon çabalarını etkili bir şekilde uyarlamak için bölümlendirilmesini sunar.
Nereden Alınır??
Bu veri, genellikle 'SRM:Request' formundaki 'Başlık' veya bir kategorizasyon alanında bulunur ve katalogdaki seçilen hizmetten türetilir.
Örnekler:::::::
Yeni Donanım TalebiYazılım Erişim TalebiVPN Erişim Kurulumu
|
|||
|
Talep Durumu
RequestStatus
|
Olay anındaki hizmet talebinin durumu, örneğin 'Devam Ediyor', 'Beklemede' veya 'Kapalı'. | ||
|
Açıklama
Bu nitelik, hizmet talebinin süreç döngüsünün farklı noktalarındaki durumunu yakalar. Durum, her aktivite için bağlam sunar ve genellikle 'Aktivite' niteliğinin kendisinin türetilirği kaynaktır. Duruma göre analiz yapmak, taleplerin 'Müşteri Beklemede' veya 'Onay Bekliyor' gibi belirli durumlarda ne kadar zaman geçirdiğini anlamaya yardımcı olur. Bu, dış bağımlılıklar veya iç kuyruklar nedeniyle oluşan darboğazları ve gecikmeleri belirlemek için gereklidir. Darboğaz Tanımlama kontrol paneli'unu doğrudan destekler.
Neden Önemli?dir?
Talebin durumunun bir anlık görüntüsünü sunar, bekleme durumlarında harcanan süre ile aktif durumlar arasındaki sürenin analizini sunar, bu da darboğazları belirlemenin anahtarıdır.
Nereden Alınır??
Bu, 'SRM:Request' formundaki 'Durum' alanıdır. Tarihsel değerler denetim günlüğünde bulunabilir.
Örnekler:::::::
PlanlamaDevam EdiyorBeklemedeÇözüldüKapalı
|
|||
|
Başvuru Kanalı
SubmissionChannel
|
Hizmet talebinin gönderildiği yöntem veya kanal. | ||
|
Açıklama
Bu nitelik, hizmet talebinin nasıl başlatıldığını kaydeder; örneğin, self-servis portalı, e-posta, servis masasına telefon araması veya otomatik sistem uyarısı aracılığıyla. Farklı kanallar, farklı süreç varyantlarına ve çözüm sürelerine yol açabilir. Süreci gönderim kanalına göre analiz etmek, belirli alım yöntemleriyle ilişkili verimsizlikleri veya en iyi uygulamaları ortaya çıkarabilir. Örneğin, self-servis portalı aracılığıyla gönderilen talepler, daha iyi başlangıç veri kalitesi nedeniyle daha hızlı çözülebilirken, e-postadan gelenler daha fazla manuel ön değerlendirme gerektirebilir.
Neden Önemli?dir?
Giriş yönteminin süreç verimliliğini,
Nereden Alınır??
Bu, genellikle 'SRM:Request' formundaki veya ilgili tamamlama biletlerindeki 'Müşteri Türü' veya 'Bildirilen Kaynak' gibi alanlardan çıkarılabilir.
Örnekler:::::::
Self-Service PortalE-postaTelefonSistem Tarafından Oluşturuldu
|
|||
|
Çözüm Kategorisi
ResolutionCategory
|
Talebi çözmek için sağlanan çözümün sınıflandırması. | ||
|
Açıklama
Bu nitelik, bir talebin nasıl çözüldüğüne dair yapılandırılmış bir kategorizasyon sunar; örneğin, 'Yazılım Düzeltmesi', 'Kullanıcı Eğitimi' veya 'Veri Düzeltmesi'. Çözümün doğasını tanımlamak için basit bir kapanış kodunun ötesine geçer. Bu, Çözüm Kategorisi Doğruluğu kontrol paneli'u için gereklidir; burada tutarlılığı kontrol etmek için ilk hizmet türüyle karşılaştırılabilir. Çözüm kategorilerini analiz etmek, sorunlardaki eğilimleri belirlemeye ve proaktif problem yönetimini bilgilendirmeye yardımcı olur, örneğin birçok talebin kullanıcı eğitimi ile çözülüp çözülmediği.
Neden Önemli?dir?
Çözümlerin niteliğine dair stratejik bilgiler sunar, tekrarlayan sorunlardaki eğilimleri ve proaktif problem yönetimi veya kullanıcı eğitimi fırsatlarını belirlemeye yardımcı olur.
Nereden Alınır??
Bu bilgi, tamamlama biletindeki operasyonel ve ürün kategorizasyon alanlarının bir parçasıdır ve genellikle 'Çözüm Kategorisi' olarak etiketlenir.
Örnekler:::::::
Hesap YönetimiDonanım ArızasıYazılım GüncellemesiBilgi Sağlandı
|
|||
|
Devir Sayısı
HandoffCount
|
Bir hizmet talebinin farklı temsilciler veya ekipler arasında yeniden atandığı toplam sayı. | ||
|
Açıklama
Bu hesaplanmış metrik, tek bir hizmet talebi için 'AssignedAgent' veya 'AssignedTeam' alanının kaç kez değiştiğini sayar. Yüksek bir el değiştirme sayısı, süreç parçalanmasını, ilk çağrıda çözüm eksikliğini veya verimsiz yönlendirmeyi gösterebilir. Bu nitelik, Talep Başına Ortalama Temsilci El Değişimi KPI'ının temelini oluşturur ve Talep Yeniden İşleme ve Yeniden Atama kontrol paneli'unda kullanılır. Yüksek el değiştirme sayılarına sahip vakaları analiz etmek, ön değerlendirmeyi iyileştirme, daha iyi eğitim güçlüa veya çözüm sürecini kolaylaştırma fırsatlarını ortaya çıkararak gecikmeleri azaltmaya ve müşteri memnuniyetini artırmaya yardımcı olabilir.
Neden Önemli?dir?
Süreç parçalanmasını ve iletişim yükünü ölçer. Yüksek
Nereden Alınır??
Bu, her benzersiz Hizmet Talep Kimliği için 'AssignedAgent' veya 'AssignedTeam' niteliğindeki farklı değerlerin sayılmasıyla türetilen hesaplanmış bir metriktir.
Örnekler:::::::
0135
|
|||
|
Kapanış Kodu
CloseCode
|
Hizmet talebinin kapanışının nihai sonucunu veya nedenini belirten bir kod. | ||
|
Açıklama
Kapanış Kodu, bir hizmet talebinin çözümünü sınıflandırmak için standartlaştırılmış bir yol sunar. Örnekler::::::: arasında 'Servis Masası Tarafından Çözüldü', 'Kullanıcı Tarafından İptal Edildi' veya 'Tekrar Eden Talep' yer alır. Kapanış kodlarını analiz etmek, taleplerin yaygın sonuçlarını anlamaya yardımcı olur. Kullanıcılar tarafından iptal edilen yüksek sayıdaki talepler (uzun bir süreci işaret edebilir) veya birçok tekrar eden talep (bir sistem veya iletişim sorununa işaret edebilir) gibi sorunları vurgulayabilir. Bu nitelik, Çözüm Kategorisi Doğruluğu Dashboard'unu destekler.
Neden Önemli?dir?
Talep sonuçları hakkında yapılandırılmış
Nereden Alınır??
Bu bilgi, genellikle hizmet talebiyle ilişkili tamamlama biletindeki 'Çözüm' veya 'Kapanış Kodu' alanında bulunur.
Örnekler:::::::
BaşarılıKullanıcı Tarafından İptal EdildiArtık Gerekli DeğilOtomatik Çözüm
|
|||
|
SLA Hedef Tarihi
SlaTargetDate
|
Hizmet talebinin, Hizmet Seviyesi Anlaşması'na (SLA) göre çözülmesi beklenen tarih ve saat. | ||
|
Açıklama
SLA Hedef Tarihi, hizmet talebini tamamlamak için son tarihi temsil eden hesaplanmış bir zaman damgası (zaman damgası)dır. Genellikle talebin önceliği ve türü gibi faktörleri dikkate alan hizmet anlaşması kuralları tarafından belirlenir. Bu nitelik, SLA Uyumluluğuna Genel Bakış kontrol paneli'u için büyük önem taşır. Gerçek çözüm süresinin ölçüldüğü bir kıyaslama noktası görevi görür. Son çözüm aktivitesinin 'EventEndTime' değerini bu hedef tarihle karşılaştırarak, hizmet taahhüdünün karşılanıp karşılanmadığını belirleyebiliriz.
Neden Önemli?dir?
Bu, hizmet performansını taahhütlere karşı ölçmek için birincil kıyaslama noktasıdır, bu da onu SLA uyumluluğu izleme ve raporlama için elzem kılar.
Nereden Alınır??
Bu tarih, Hizmet Seviyesi Yönetimi (SLM) modülü tarafından hesaplanır ve saklanır ve hizmet talebiyle bağlantılı ilgili SLM formlarında bulunabilir.
Örnekler:::::::
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
|
|||
|
SLA İhlal Edildi mi?
IsSlaBreached
|
Hizmet talebinin SLA hedef tarihinden sonra çözülüp çözülmediğini gösteren bir `boolean flag`. | ||
|
Açıklama
Bu hesaplanmış bayrak, hizmet talebinin nihai çözüm zaman damgası (zaman damgası) 'SLA Hedef Tarihi'nden daha sonra ise doğru olarak ayarlanır. Bu, talep bazında SLA performansı için basit, ikili bir sonuç sunar. Bu nitelik, SLA Uyumluluğuna Genel Bakış kontrol paneli'u ve SLA Uyum Oranı KPI'ı için gereklidir. Genel uyumluluk oranlarını hesaplamak için kolay bir toplama sunar ve ihlal edilen talepler ile uyumlu olanların süreç özelliklerini analiz etmek için filtrelemeyi etkinleştirerek, SLA hatalarının temel nedenlerini belirlemeye yardımcı olur.
Neden Önemli?dir?
Bir zaman damgası (zaman damgası) karşılaştırmasını basit bir
Nereden Alınır??
Bu hesaplanmış bir alandır. Mantık şöyledir: EĞER 'Çözüm Zaman Damgası' > 'SlaTargetDate' İSE DOĞRU DEĞİLSE YANLIŞ.
Örnekler:::::::
truefalse
|
|||
|
Talep Eden Departman
RequestorDepartment
|
Talebi gönderen kullanıcının iş departmanı veya birimi. | ||
|
Açıklama
Bu nitelik, hizmeti talep eden kişinin organizasyonel departmanını tanımlar; örneğin, 'Finans', 'İnsan Kaynakları' veya 'BT'. Bu bilgi genellikle sistemdeki kullanıcının profilinden alınır. Süreç analizini departmana göre segmentlere ayırmak, departmana özel ihtiyaçları, talep modellerini ve hedeflenmiş eğitim veya hizmet iyileştirmeleri için potansiyel alanları belirlemeye sunar. 'Finans departmanı talepleri için daha uzun bekleme süreleri yaşıyor mu?' gibi soruları yanıtlamaya yardımcı olabilir.
Neden Önemli?dir?
İş birimine göre hizmet tüketimi ve süreç performansı analizini sunar, bu da departmana özgü sorunları veya eğilimleri vurgulayabilir.
Nereden Alınır??
Bu bilgi, genellikle 'SRM:Request' formundaki 'Talep Edilen' kullanıcıyla ilişkili kullanıcının profilinden alınır.
Örnekler:::::::
FinansSatışİnsan KaynaklarıBilgi Teknolojileri
|
|||
|
Yeniden İşleme mi?
IsRework
|
Bir hizmet talebinin, önceki bir aşamaya geri dönmek gibi, yeniden işleme tabi tutulup tutulmadığını gösteren bir `boolean flag`. | ||
|
Açıklama
Bu bayrak, süreç akışında bir döngü veya tekrar iş yaşamış hizmet taleplerini tanımlar. Örneğin, 'Tamamlama Devam Ediyor' durumundan 'Talep İnceleniyor' durumuna geri dönen bir talep tekrar iş olarak kabul edilir. Kesin tanım iş sürecinin mantığına bağlıdır. Bu nitelik, Talep Yeniden İşleme ve Yeniden Atama Analizi kontrol paneli'unu ve Talep Tekrar İş Oranı KPI'ını doğrudan destekler. Tekrar işlerin sıklığını nicelleştirmeye ve yanlış ilk değerlendirme veya eksik bilgi gibi yaygın nedenleri analiz etmeye olanak tanıyarak süreç verimsizliklerine yol açar.
Neden Önemli?dir?
'İdeal yoldan' sapan
Nereden Alınır??
Bu, event logndeki aktivite dizisinden türetilen hesaplanmış bir niteliktir. Süreç akışındaki geri hareketleri tespit etmek için mantık gereklidir.
Örnekler:::::::
truefalse
|
|||
|
Yükseltildi mi
IsEscalated
|
Hizmet talebinin eskalasyona uğrayıp uğramadığını gösteren bir `boolean flag`. | ||
|
Açıklama
Bu bayrak, bir hizmet talebi işlevsel veya hiyerarşik bir iletmeye tabi tutulduysa doğru olarak ayarlanır. Bir iletme genellikle bir talep beklendiği gibi ilerlemediğinde, bir SLA'yı ihlal etmek üzere olduğunda veya onay veya eylem için daha yüksek bir otorite gerektirdiğinde meydana gelir. Bu nitelik, Talep İletme Verimliliği Analizi kontrol paneli'u için temel rol oynar. İletilen taleplerin süreç yollarını filtrelemeye ve analiz etmeye olanak tanıyarak, neyin onları tetiklediğini, iletme sonrası ne kadar sürede çözüldüğünü ve iletme sürecinin ne kadar etkili olduğunu anlamaya yardımcı olur.
Neden Önemli?dir?
Eskalasyon gerektiren taleplerin alt kümesini izole etmeye ve analiz etmeye sunar, standart süreçteki zayıflıkları veya karmaşık sorunların tetikleyicilerini belirlemeye yardımcı olur.
Nereden Alınır??
Bu genellikle tek bir alan değildir. Denetim günlüğünde belirli iletme ile ilgili aktiviteleri veya bir iletme protokolünü takip eden öncelik veya atama değişikliklerini kontrol ederek türetilir.
Örnekler:::::::
truefalse
|
|||
Hizmet Talep Yönetimi Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
BT Hizmet Talebi Yönetimi Çözüldü
|
Hizmet talebinin tamamlanması bitmiştir ve çözüm talep sahibine iletilmiştir. Talep, son onayı beklemektedir veya belirli bir süre sonra otomatik olarak kapanacaktır. | ||
|
Neden Önemli?dir?
Hizmet sunum döngüsünün sonunu işaret eden kritik bir kilometre taşıdır. Çözüm süresini ve SLA uyumluluğunu ölçmek için birincil uç noktadır.
Nereden Alınır??
SRM:Request formundaki durumun 'Resolved' veya 'Completed' olarak değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Çözüldü' veya 'Tamamlandı' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
BT Hizmet Talebi Yönetimi Gönderildi
|
Bu aktivite, bir kullanıcı tarafından yeni bir hizmet talebinin oluşturulmasını ve gönderilmesini işaret eder. Genellikle 'Gönderildi' başlangıç durumuyla SRM:Request formunda yeni bir giriş oluşturulduğunda yakalanır. | ||
|
Neden Önemli?dir?
Bu, her hizmet talebi vakası için başlangıç noktasıdır, toplam süreç döngüsü süresini ölçmek ve talep alım hacimlerini analiz etmek için büyük önem taşır.
Nereden Alınır??
Bu olay, SRM:Request formundaki bir kaydın oluşturulma zaman damgası (zaman damgası) ve başlangıç durumundan (örn. 'Gönderildi') çıkarılır.
Yakala
Durumu 'Gönderildi' olduğunda SRM:Request formundaki yeni bir BT Hizmet Talebi Yönetimi ID'si için oluşturma zaman damgası (zaman damgası)'ini belirleyin.
Event tipi
inferred
|
|||
|
BT Hizmet Talebi Yönetimi İptal Edildi
|
Hizmet talebi, tamamlama tamamlanmadan önce ya talep sahibi ya da servis masası tarafından geri çekilmiştir. Bu, talep için son bir durumdur. | ||
|
Neden Önemli?dir?
İptallerin takibi, kullanıcıların yanlış talepler göndermesi veya hizmetlere artık ihtiyaç duyulmaması gibi kalıpları belirlemeye yardımcı olur ve bu da hizmet kataloğu iyileştirmelerini bilgilendirebilir.
Nereden Alınır??
SRM:Request formundaki durumun 'Canceled' olarak değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'İptal Edildi' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
BT Hizmet Talebi Yönetimi Kapatıldı
|
Hizmet talebi resmi olarak kapatılır ve salt okunur, arşivlenmiş bir duruma taşınır. Bu, çözümden ve herhangi bir onay süresinin geçmesinden sonra gerçekleşir. | ||
|
Neden Önemli?dir?
Bu aktivite, sürecin kesin sonunu temsil eder. 'Çözüldü' ve 'Kapandı' arasındaki süre, kapanış prosedüründeki verimsizlikleri vurgulayabilir.
Nereden Alınır??
SRM:Request formundaki son durum değişikliğinin 'Closed' olarak değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Kapalı' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep Atandı
|
Hizmet talebi, işi tamamlamakla sorumlu belirli bir tamamlama temsilcisine veya ekibine atanmıştır. Bu, ön değerlendirme aşamasının sonunu işaret eder. | ||
|
Neden Önemli?dir?
Bu kilometre taşı, ön değerlendirme süresini ölçmek ve temsilci iş yükünü analiz etmek için büyük önem taşır. Sık yeniden atamalar, yönlendirme sorunlarını veya beceri eksikliklerini gösterebilir.
Nereden Alınır??
Bu olay, SRM:Request veya ilgili tamamlama uygulama formlarındaki (örn. WOI:WorkOrder) 'Atanan Grup' veya 'Atanan Kişi' alanlarının denetim günlüğünden açıkça yakalanabilir.
Yakala
Denetim günlüğünden, 'Atanan Kişi' alanına ilk kez boş olmayan bir değerin ayarlandığını gösteren zaman damgası (zaman damgası)dır.
Event tipi
explicit
|
|||
|
Yerine Getirme Devam Ediyor
|
Atanan temsilci veya ekip, hizmet talebini yerine getirmek için aktif olarak çalışmaya başladı. Bu, talebin bir kuyruktan aktif bir çalışma durumuna geçtiğini gösterir. | ||
|
Neden Önemli?dir?
Değer katan yerine getirme işinin başlangıcını işaret eder. Bu aşamada harcanan süreyi analiz etmek, kaynak verimliliğini ve yerine getirme karmaşıklığını anlamaya yardımcı olur.
Nereden Alınır??
SRM:Request formundaki durumun 'In Progress' olarak değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Devam Ediyor' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Çözüm Kullanıcı Tarafından Onaylandı
|
Talep sahibi, hizmetin tatmin edici bir şekilde teslim edildiğini ve talebin çözüldüğünü aktif olarak onayladı. Bu durum genellikle talebin nihai kapanışını tetikler. | ||
|
Neden Önemli?dir?
Müşteri memnuniyetinin net bir göstergesini sunar ve hizmet etkileşimini resmi olarak sonlandırır. Süreç çözümünü müşteri kabulünden ayırır.
Nereden Alınır??
Bu olay, bir kullanıcı portal veya e-posta aracılığıyla onayladığında SRM:Request iş günlüklerinde veya aktivite notlarında yakalanabilir. Her zaman ayrı bir durum değildir.
Yakala
Kullanıcı onayını veya anket tamamlandığını gösteren belirli girişler için iş günlüklerini (SRM:WorkInfo) tarayın.
Event tipi
explicit
|
|||
|
Çözüm Uygulandı
|
Hizmet talebini yerine getirmek için gereken teknik çalışma temsilci tarafından tamamlandı. Talep, resmi olarak çözülmeden önce kullanıcı ile onay için hazır. | ||
|
Neden Önemli?dir?
Bu aktivite, teknik tamamlamayı resmi çözülmeden ayırarak, işin tamamlanması ile kullanıcı onayı arasındaki gecikmeleri belirlemeye yardımcı olur.
Nereden Alınır??
Bu, ana SRM:Request 'Çözüldü' olarak işaretlenmeden önce bir arka uç tamamlama biletindeki (örn. İş Emri durumu 'Tamamlandı' olarak) bir durum değişikliğinden çıkarılabilir.
Yakala
SRM:Request'e bağlı bir arka uç biletinin (İş Emri, Olay vb.) tamamlandı olarak işaretlendiği zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Kullanıcıdan Bilgi İstendi
|
Tamamlama temsilcisi, işleme devam etmek için talep sahibinden ek bilgiye ihtiyaç duyar. Talep genellikle 'Beklemede' durumuna alınır. | ||
|
Neden Önemli?dir?
Bu aktivite, 'Harici Bilgi Bekleme Süresi'ni hesaplamak ve taleplerin eksik bilgi nedeniyle ne sıklıkla durduğunu belirlemek için büyük önem taşır.
Nereden Alınır??
SRM:Request formundaki durumun 'Pending' olarak, 'Customer Hold' veya 'Awaiting Information' gibi bir durum nedeni ile değişmesinden çıkarılmıştır.
Yakala
Belirli bir durum nedeni ile birlikte 'Beklemede' durumuna geçişin zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep Devam Etti
|
Hizmet talebi, genellikle kullanıcı tarafından gerekli bilgiler sağlandıktan sonra bekleme veya askıda kalma durumundan çıkarılmıştır. Talep üzerindeki çalışma tamamlama temsilcisi tarafından yeniden başlatılır. | ||
|
Neden Önemli?dir?
Bir bekleme süresinin sonunu işaret eder, harici bekleme sürelerinin ve bunların SLA uyumluluğu üzerindeki etkisinin kesin olarak ölçülmesine sunar.
Nereden Alınır??
SRM:Request durumunun 'Pending' konumundan tekrar 'In Progress' konumuna değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Beklemede' durumundan 'Devam Ediyor' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep İnceleniyor
|
Hizmet talebi, servis masası tarafından doğası, önceliği ve uygun tamamlama ekibini belirlemek üzere ilk inceleme ve ön değerlendirmeden geçmektedir. Bu durum genellikle talep kaydındaki bir durum değişikliği ile temsil edilir. | ||
|
Neden Önemli?dir?
Bu aktiviteyi takip etmek, ön değerlendirme verimliliğini ölçmeye ve gönderim ile atama arasındaki gecikmeleri belirlemeye yardımcı olur, bu da 'Ortalama Ön Değerlendirme Süresi' KPI'ı için büyük önem taşır.
Nereden Alınır??
SRM:Request formundaki durumun 'In Review' veya 'Planning' gibi bir değere değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'İnceleniyor' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep Onay Bekliyor
|
Hizmet talebi, belirlenmiş bir onaylayıcıya veya onay grubuna sunulmuş olup, tamamlama başlamadan önce bir karar beklemektedir. Bu, maliyet veya erişim hakları içeren talepler için yaygın bir adımdır. | ||
|
Neden Önemli?dir?
Bu aktivite, onay ile ilgili gecikmeleri izole eder, onay döngüsü sürelerinin analizine ve onay zincirindeki darboğazların belirlenmesine sunar.
Nereden Alınır??
SRM:Request formundaki durumun 'Waiting Approval' gibi bir değere değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Onay Bekliyor' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep Onaylandı
|
Hizmet talebi, gerekli tarafça resmi olarak onaylanmış olup, tamamlama sürecinin ilerlemesine izin vermektedir. Bu olay genellikle 'Onay Bekliyor' durumunu takip eder. | ||
|
Neden Önemli?dir?
Onay alt sürecinin sonunu işaret eder ve onayların ne kadar sürdüğünü ve genel çözüm süresi üzerindeki etkilerini izlemek için önemli bir kilometre taşıdır.
Nereden Alınır??
SRM:Request formundaki durumun 'Waiting Approval'dan, 'Planning' veya 'In Progress' gibi sonraki bir duruma geçişi üzerinden tespit edilir. Onay kararının kendisi ise ilgili onay formlarında kayıtlıdır.
Yakala
Olumlu bir onay kararından sonra 'Onay Bekliyor' durumundan çıkış durum değişikliğinin zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||
|
Talep Reddedildi
|
Hizmet talebi, bir onay aşamasında reddedildi. Bu, tamamlama başlamadan önce süreci durduran son bir durumdur. | ||
|
Neden Önemli?dir?
Reddedilen talepleri analiz etmek, talep gerekçeleri, uygunluk kriterleri veya onay politikalarıyla ilgili sorunları ortaya çıkarabilir.
Nereden Alınır??
SRM:Request formundaki durumun 'Rejected' olarak değişmesinden çıkarılmıştır.
Yakala
SRM:Request 'Durum' alanının 'Reddedildi' durumuna değiştiği güncelleme olayının zaman damgası (zaman damgası)dır.
Event tipi
inferred
|
|||