Hizmet Talep Yönetimi Veri Şablonunuz
BMC Helix ITSMHizmet Talep Yönetimi Veri Şablonunuz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- BMC Helix ITSM için `data` çekim rehberliği
Hizmet Talep Yönetimi Nitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Hizmet talebi yaşam döngüsünde belirli bir zamanda meydana gelen özel event veya görevin adı. | ||
|
Açıklama
Bu nitelik, hizmet talebi sürecindeki 'Talep İnceleniyor', 'Tamamlama Devam Ediyor' veya 'Hizmet Talebi Çö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 olanak tanır. Hangi aktivitelerin, hangi sırayla ve ne sıklıkla gerçekleştiğini anlamak, süreç optimizasyonu için çok önemlidir.
Neden önemli
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 EdiyorHizmet Talebi ÇözüldüHizmet Talebi Kapatıldı
|
|||
|
Başlangıç Zamanı
EventStartTime
|
Belirli bir aktivite veya event'in ne zaman başladığını gösteren timestamp. | ||
|
Açıklama
Bu nitelik, bir aktivitenin başladığı kesin 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ı, tüm zaman tabanlı süreç madenciliği analizleri için kritiktir. 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 sağlar.
Neden önemli
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ı sağlar.
Nereden alınır
Bu, 'SRM:Request' formuyla ilişkili denetim günlüklerindeki veya durum geçmişi tablolarındaki 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
|
|||
|
Servis Talebi Kimliği
ServiceRequestId
|
Her hizmet talebi için benzersiz tanımlayıcı, tüm yaşam 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 iplik görevi görerek, her bir hizmet talebinin yolculuğunun eksiksiz, uçtan uca analizini sağlar. Süreç madenciliğinde, bu Kimlik her bir vaka için aktivite dizisini yeniden yapılandırmak için esastır. Bu, aracın 'Talep Gönderildi', 'Talep Atandı' ve 'Hizmet Talebi Kapandı' gibi ilgili tüm olayları tek bir süreç örneğinde gruplandırmasına olanak tanır ve tüm süreç analizinin temelini oluşturur.
Neden önemli
Bu, temel vaka tanımlayıcıdır. Olmadan, bir hizmet talebinin uçtan uca yolculuğunu 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 çok önemlidir. Özellikle farklı platformlardan veri birleştirirken netlik ve izlenebilirlik sağlar.
Neden önemli
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ı. | ||
|
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 bağlam sağlayarak, analizin kapsadığı zaman diliminden haberdar olmalarını sağlar. Bu, herhangi bir süreç madenciliği dashboard'u veya analizi için kritik bir meta veri niteliğidir. Kullanıcıların içgörülerin gerçek zamanlıya yakın verilere mi yoksa geçmiş bir anlık görüntüye mi dayandığını anlamalarına olanak tanır, bu da çıkarılan sonuçların geçerliliğini ve alaka düzeyini etkiler.
Neden önemli
Kullanıcıları
Nereden alınır
Bu 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 Tekrar İşleri ve Yeniden Atama ile Ön Değerlendirme Verimliliği dashboard'ları için anahtardır.
Neden önemli
Farklı fonksiyonel gruplar arasındaki süreç akışının analizini sağlar, 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 yaşam 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 çok önemlidir. Her temsilcinin kaç talep işlediğini, ortalama çözüm süresini ve yeniden atama sıklığını takip etmeye olanak tanır. Bu veri, kaynak yönetimi ve eğitim fırsatlarının belirlenmesini destekler.
Neden önemli
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 elzemdir.
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ş Saati
EventEndTime
|
Belirli bir faaliyetin veya olayın ne zaman tamamlandığını gösteren zaman damgası. | ||
|
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ı sağlar. 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
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ı olacaktır.
Örnekler
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
|
|||
|
Hizmet Türü
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ı İş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 kritiktir.
Neden önemli
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 sağlar.
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
|
|||
|
Ö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 çok önemlidir. Çözüm süresi ve SLA uyumluluğu için
Neden önemli
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
|
|||
|
Talep Durumu
RequestStatus
|
Olay anındaki hizmet talebinin durumu, örneğin 'Devam Ediyor', 'Beklemede' veya 'Kapalı'. | ||
|
Açıklama
Bu nitelik, hizmet talebinin yaşam döngüsünün farklı noktalarındaki durumunu yakalar. Durum, her aktivite için bağlam sağlar ve genellikle 'Aktivite' niteliğinin kendisinin türetildiğ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 elzemdir. Darboğaz Tanımlama dashboard'unu doğrudan destekler.
Neden önemli
Talebin durumunun bir anlık görüntüsünü sağlar, bekleme durumlarında harcanan süre ile aktif durumlar arasındaki sürenin analizini mümkün kılar, bu da
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
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 sağlar; ö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 dashboard'u için elzemdir; 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
Çözümlerin niteliğine dair içgörüler 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 Tekrar İşleri ve Yeniden Atama dashboard'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 sağlama 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
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
|
|||
|
Döngü Süresi
CycleTime
|
Hizmet talebinin oluşturulmasından nihai çözümüne kadar geçen toplam süre. | ||
|
Açıklama
Uçtan uca süre olarak da bilinen Döngü Süresi, bir hizmet talebinin toplam yaşam süresini ölçer. İlk Bu,
Neden önemli
Bu, süreç verimliliğinin birincil bir ölçüsüdür. Döngü süresini anlamak ve azaltmak, genellikle süreç iyileştirme girişimlerinin temel bir hedefidir.
Nereden alınır
Bu hesaplanmış bir metriktir. Her benzersiz Hizmet Talep Kimliği için 'Gönderim Tarihi'nin 'Kapanış Tarihi' veya 'Çözülme Tarihi'nden çıkarılmasıyla türetilir.
Örnekler
2 gün 4 saat8 saat 30 dakika15 gün
|
|||
|
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
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ı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ış dashboard'u için temeldir. 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
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ı 'SLA Hedef Tarihi'nden daha sonra ise doğru olarak ayarlanır. Bu, talep bazında SLA performansı için basit, ikili bir sonuç sağlar. Bu nitelik, SLA Uyumluluğuna Genel Bakış dashboard'u ve SLA Uyum Oranı KPI'ı için elzemdir. Genel uyumluluk oranlarını hesaplamak için kolay bir toplama sağlar 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
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 olanak tanır. 'Finans departmanı talepleri için daha uzun bekleme süreleri yaşıyor mu?' gibi soruları yanıtlamaya yardımcı olabilir.
Neden önemli
İş birimine göre hizmet tüketimi ve süreç performansı analizini sağlar, 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 Tekrar İşleri ve Yeniden Atama Analizi dashboard'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
'İdeal yoldan' sapan
Nereden alınır
Bu, olay günlüğündeki 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 dashboard'u için anahtardır. İ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
Eskalasyon gerektiren taleplerin alt kümesini izole etmeye ve analiz etmeye olanak tanır, 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 | ||
|---|---|---|---|
|
Hizmet Talebi Çö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
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ı.
Event tipi
inferred
|
|||
|
Hizmet Talebi 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
Bu, her hizmet talebi vakası için başlangıç noktasıdır, toplam yaşam döngüsü süresini ölçmek ve talep alım hacimlerini analiz etmek için elzemdir.
Nereden alınır
Bu olay, SRM:Request formundaki bir kaydın oluşturulma zaman damgası ve başlangıç durumundan (örn. 'Gönderildi') çıkarılır.
Yakala
Durumu 'Gönderildi' olduğunda SRM:Request formundaki yeni bir Hizmet Talebi ID'si için oluşturma
Event tipi
inferred
|
|||
|
Hizmet Talebi İ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
İ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ı.
Event tipi
inferred
|
|||
|
Hizmet Talebi 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
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ı.
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
Bu kilometre taşı, ön değerlendirme süresini ölçmek ve temsilci iş yükünü analiz etmek için kritiktir. 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ı.
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
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ı.
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
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
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ı.
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
Bu aktivite, 'Harici Bilgi Bekleme Süresi'ni hesaplamak ve taleplerin eksik bilgi nedeniyle ne sıklıkla durduğunu belirlemek için çok önemlidir.
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ı.
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
Bir bekleme süresinin sonunu işaret eder, harici bekleme sürelerinin ve bunların SLA uyumluluğu üzerindeki etkisinin kesin olarak ölçülmesine olanak tanır.
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ı.
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
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 kritiktir.
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ı.
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
Bu aktivite, onay ile ilgili gecikmeleri izole eder, onay döngüsü sürelerinin analizine ve onay zincirindeki darboğazların belirlenmesine olanak tanır.
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ı.
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
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ı.
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
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ı.
Event tipi
inferred
|
|||