Hizmet Talep Yönetimi Veri Şablonunuz
Hizmet Talep Yönetimi Veri Şablonunuz
- Kapsamlı analiz için önerilen özellikler
- Süreç keşfi için izlenecek temel faaliyetler
- Jira Service Management için veri çıkarma rehberliği
Hizmet Talep Yönetimi Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
ActivityName
|
Hizmet talebi yaşam döngüsü içinde meydana gelen belirli olayın veya görevin adı. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebi için belirli bir zamanda gerçekleşen özel eylemi veya durum geçişini tanımlar. Örnekler arasında 'Talep Oluşturuldu', 'Talep Atandı', 'Çözüm Uygulandı' ve 'Talep Kapandı' yer alır. Bu etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining'in temelini oluşturur. Süreç haritalarının görselleştirilmesine, darboğazların belirlenmesine ve standart iş akışından sapmaların tespit edilmesine olanak tanır; bu da süreç verimliliği ve uyumluluğunu anlamak için kritiktir.
Neden önemli
Süreçteki adımları tanımlar, süreç haritasının görselleştirilmesini ve iş akışı kalıplarının ve sapmalarının analizini sağlar.
Nereden alınır
Genellikle bir Jira talebinin 'status' (durum) geçiş geçmişinden türetilir. Talebin değişiklik günlüğündeki durum alanı için her giriş bir etkinliği temsil eder.
Örnekler
Talep Tasnif EdildiBilgi Talep EdildiÇözüm UygulandıHizmet Talebi Kapatıldı
|
|||
|
Başlangıç Zamanı
EventTime
|
Belirli bir aktivite veya olayın gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Başlangıç Zamanı veya olay zaman damgası, bir etkinliğin tam olarak ne zaman gerçekleştiğini kaydeder. Tüm süreç için zamansal bağlam sağladığı için herhangi bir Process Mining analizi için kritik bir bileşendir. Bu zaman damgası, olayları sıralı olarak düzenlemek, etkinlikler arasındaki süreyi hesaplamak, toplam olay döngü sürelerini ölçmek ve SLA'lar gibi zamana dayalı hedeflere karşı süreç performansını analiz etmek için kullanılır. Doğru zaman damgaları olmadan süreç akışını anlamak, gecikmeleri belirlemek veya verimliliği ölçmek imkansızdır.
Neden önemli
Bu zaman damgası, olayları sıralamak, süreleri ve döngü sürelerini hesaplamak ve süreç darboğazlarını belirlemek için esastır.
Nereden alınır
Bu, Jira talep değişiklik günlüğündeki her durum geçişiyle ilişkili zaman damgasıdır. Talep oluşturma zamanı 'created' (oluşturuldu) alanıdır.
Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
Servis Talebi Kimliği
ServiceRequestId
|
Her hizmet talebi için benzersiz tanımlayıcı, tüm ilgili olaylar için birincil anahtar görevi görür. | ||
|
Açıklama
Jira'da genellikle Talep Anahtarı olarak adlandırılan Hizmet Talep Kimliği, bir kullanıcı veya sistem tarafından gönderilen her bir hizmet talebini benzersiz şekilde tanımlar. İlk kayıttan nihai kapanışa kadar tüm sonraki olayları birbirine bağlayan merkezi bir bağlantı görevi görerek, her hizmet talebinin yolculuğunun eksiksiz, baştan sona analizine olanak tanır. Process Mining'de bu kimlik, olay korelasyonu için esastır. Her etkinliğin, durum değişikliğinin ve zaman damgasının ait olduğu belirli taleple doğru şekilde ilişkilendirilmesini sağlayarak analiz için tutarlı bir süreç örneği oluşturur.
Neden önemli
Bu Kimlik, tüm ilgili etkinlikleri tek bir baştan sona süreç akışına bağlayan temel olay tanımlayıcısıdır ve süreç analizini mümkün kılar.
Nereden alınır
Bu, Jira Service Management'taki bir talep için 'key' (anahtar) alanıdır.
Örnekler
SR-2023-001IT-45892HELP-105
|
|||
|
Kaynak Sistem
SourceSystem
|
Hizmet talep verilerinin çıkarıldığı sistem. | ||
|
Açıklama
Bu öznitelik, verinin kaynağını tanımlar; bu durumda Jira Service Management'tır. Tek bir kaynaktan veri analiz ederken önemsiz gibi görünse de, birden fazla sistemden süreç verilerini birleştirirken kritik hale gelir. Analiz için veri kökenini izlemeye ve veri kalitesini sağlamaya yardımcı olur. Ayrıca, farklı yazılım platformlarına yayılabilecek veya bunlarla etkileşime girebilecek süreçleri filtrelemeye ve karşılaştırmaya da olanak tanır.
Neden önemli
Verinin kaynağını belirler, bu da veri yönetişimi ve birden çok kurumsal sistemden gelen süreç verilerini birleştirirken kritik öneme sahiptir.
Nereden alınır
Bu genellikle veri çıkarma ve dönüştürme süreci sırasında veri setinin kaynağını etiketlemek için eklenen statik bir değerdir.
Örnekler
Jira Service ManagementJiraSM
|
|||
|
Son Veri Güncellemesi
LastDataUpdate
|
`veri`nin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Jira Service Management'tan en son veri çekiminin tarihini ve saatini kaydeder. Analizin güncelliği ve Dashboard'lar ile KPI'larda yer alan veriler için kritik bir bağlam sağlar. Herhangi bir analizde, verinin güncelliğini bilmek bilinçli kararlar almak için esastır. Bu zaman damgası, kullanıcıların gerçek zamanlı bilgilere mi yoksa geçmiş bir zamandan alınan bir anlık görüntüye mi baktıklarını anlamalarına yardımcı olur; bu da bulguların alaka düzeyini etkiler.
Neden önemli
Verilerin güncelliğini gösterir, analizlerin güncel bilgilere dayandığından emin olunmasını sağlar.
Nereden alınır
Bu, veri çekme aracı veya betiği tarafından çalışmasının sonunda oluşturulan ve depolanan bir metaveri alanıdır.
Örnekler
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Atanan Kişi
Assignee
|
Hizmet talebi üzerinde çalışmak üzere mevcut durumda atanan kullanıcı veya temsilci. | ||
|
Açıklama
Atanan Kişi, hizmet talebinin bir sonraki eyleminden veya çözümünden sorumlu kişidir. Bu özniteliğin değeri, farklı temsilciler veya ekipler arasında devredildikçe talebin yaşam döngüsü boyunca birden çok kez değişebilir. Bu öznitelik, iş yükü analizi, performans ölçümü ve kaynak yönetimi için kritiktir. Süreci temsilciye göre filtrelemeye, bireyler arasındaki çözüm sürelerini karşılaştırmaya ve darboğazlara neden olan potansiyel eğitim ihtiyaçlarını veya iş yükü dengesizliklerini belirlemeye olanak tanır.
Neden önemli
Bu öznitelik, temsilci iş yükünü analiz etmek, bireysel performansı ölçmek ve kaynak tahsisini anlamak için hayati öneme sahiptir.
Nereden alınır
Bu, bir Jira talebindeki 'assignee' (atanan) alanına karşılık gelir.
Örnekler
Alice JohnsonBob WilliamsAtanmamış
|
|||
|
SLA Son Tarihi
SlaDueDate
|
SLA'sına göre hizmet talebinin çözülmesi gereken hedef tarih ve saat. | ||
|
Açıklama
SLA Son Tarihi, bir talebi çözmek için son tarihi temsil eden hesaplanmış bir zaman damgasıdır. Bu, talebin önceliği, tipi ve Jira Service Management'ta yapılandırılmış belirli Hizmet Seviyesi Anlaşması (SLA) politikaları tarafından belirlenir. Bu öznitelik, 'Hizmet Talep SLA Performansı' Dashboard'u ve 'SLA Uyumluluk Oranı' KPI'ı için temeldir. Gerçek çözüm süresini bu son tarihle karşılaştırarak, sistem her talebin zamanında tamamlanıp tamamlanmadığını, geciktiğini veya SLA'sını ihlal etme riski taşıyıp taşımadığını belirleyebilir.
Neden önemli
Bu, performansı ölçmek için bir kriterdir. SLA uyumluluğunun hesaplanmasını doğrudan destekler ve işin önceliklendirilmesine yardımcı olur.
Nereden alınır
SLA bilgileri Jira Service Management tarafından yönetilir ve API aracılığıyla erişilebilir olup, genellikle dinamik olarak güncellenen özel alanlarda saklanır.
Örnekler
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
Talep Durumu
RequestStatus
|
Hizmet talebinin yaşam döngüsündeki mevcut durumu. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebinin 'Açık', 'Devam Ediyor', 'Müşteri Bekleniyor' veya 'Çözüldü' gibi mevcut durumunu temsil eder. Talebin herhangi bir zamanda nerede olduğuna dair bir anlık görüntü sağlar. Etkinlik günlüğü geçmiş akışı sağlarken, mevcut durum açık iş yüklerini analiz etmek ve takılı kalan öğeleri belirlemek için faydalıdır. Örneğin, analiz, 'Tedarikçi Bekleniyor' durumunda olağanüstü uzun süre kalmış taleplere odaklanarak harici bağımlılıkları ve gecikmeleri vurgulayabilir.
Neden önemli
Her vakanın güncel bir anlık görüntüsünü sunar, devam eden işlerin analizini ve durmuş veya eskiyen taleplerin belirlenmesini sağlar.
Nereden alınır
Bu, bir Jira talebindeki 'status' (durum) alanıdır.
Örnekler
AçıkDevam EdiyorMüşteri BekleniyorÇözüldü
|
|||
|
Talep Önceliği
RequestPriority
|
Düşük, Orta, Yüksek veya Kritik gibi hizmet talebine atanan öncelik seviyesi. | ||
|
Açıklama
Talep Önceliği, bir hizmet talebinin aciliyetini ve iş üzerindeki etkisini belirtir. Bu sınıflandırma, taleplerin ele alınma sırasını belirler ve genellikle hedef çözüm sürelerini ve SLA'ları dikte eder. Süreç analizinde öncelik, segmentasyon için temel bir boyuttur. Farklı öncelik seviyelerindeki döngü sürelerini ve SLA uyumluluğunu karşılaştırmaya olanak tanıyarak, yüksek öncelikli taleplerin gerçekten daha hızlı işlendiğini ve hedeflerine ulaştığını sağlar. Bu, önceliklendirme sisteminin etkinliğini doğrulamaya yardımcı olur.
Neden önemli
Yüksek öncelikli taleplerin daha hızlı ele alınmasını ve daha katı hizmet seviyelerini karşılamasını sağlamak için analizin segmentlere ayrılmasına olanak tanır.
Nereden alınır
Bu, bir Jira talebindeki 'priority' (öncelik) alanına karşılık gelir.
Örnekler
En YüksekYüksekOrtaDüşük
|
|||
|
Talep Tipi
RequestType
|
'Erişim Talebi' veya 'Donanım Sorunu' gibi hizmet talebinin sınıflandırması. | ||
|
Açıklama
Talep Tipi, hizmet talebini niteliğine göre kategorize eder. Farklı talep türlerinin genellikle farklı çözüm süreçleri, SLA'ları ve kaynak gereksinimleri olduğundan, bu analiz için temel bir boyuttur. Süreç analizini Talep Tipi'ne göre segmente ederek, kuruluşlar belirli iş akışlarına özel iyileştirmeler yapabilir. Örneğin, bir 'Parola Sıfırlama' talebinin darboğazı, bir 'Yeni Sunucu Sağlama' talebininkinden çok farklı olacaktır. Bu öznitelik, 'Kategoriye Göre Çözüm Kalitesi' gibi ilgili Dashboard'lar oluşturmak için anahtardır.
Neden önemli
Bu öznitelik, farklı hizmet talebi kategorilerindeki süreçleri, iş yüklerini ve performansı karşılaştırmak için esastır.
Nereden alınır
Bu genellikle Jira'daki 'issuetype' (talep türü) alanına veya Jira Service Management'taki özel bir 'Request Type' (Talep Tipi) alanına karşılık gelir.
Örnekler
Yeni hesap talep etBT yardımı alınYeni bir çalışanı işe alma
|
|||
|
Atanan Ekip
AssignedTeam
|
Hizmet talebini ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Bu öznitelik, bir talebe atanan ekibi belirtir; bu genellikle bireysel atanandan daha üst düzey bir gruplamadır. Birinci Seviye Destek ekibini Ağ Operasyonları ekibiyle karşılaştırmak gibi ekip düzeyinde performansı analiz etmek için faydalıdır. Bu boyut, 'Temsilci İş Yükü ve Çözüm Metrikleri' gibi Dashboard'lar için çok önemlidir. Ekip düzeyinde performans metriklerini toplulaştırmaya olanak tanıyarak adil karşılaştırmaları kolaylaştırır ve farklı ekiplerin genel hizmet sunum sürecine nasıl katkıda bulunduğunu anlamayı sağlar.
Neden önemli
Sadece bireysel temsilci bazında değil, ekip veya departman düzeyinde performans analizi ve iş yükü dengeleme imkanı sunar.
Nereden alınır
Bu, Jira'da özel bir alan (örneğin, 'Ekip') olabilir veya atanan kişinin kullanıcı profil özniteliklerinden türetilebilir.
Örnekler
BT Desteği - Kademe 1Altyapı EkibiUygulama Desteği
|
|||
|
Bildiren
Reporter
|
Hizmet talebini başlangıçta oluşturan veya bildiren kullanıcı. | ||
|
Açıklama
Talep Eden, genellikle son kullanıcı veya müşteri olan, hizmet talebini gönderen kişidir. Bu öznitelik, süreci başlatan paydaşı tanımlar. Analizde, Talep Eden farklı kullanıcı, departman veya müşteri segmentlerinden gelen talep modellerini anlamak için kullanılabilir. 'Hangi departmanlar en çok talep gönderiyor?' veya 'Belirli kullanıcılar tekrar tekrar aynı sorunlarla mı karşılaşıyor?' gibi soruları yanıtlamaya yardımcı olur. Bu bilgi, proaktif sorun yönetimi ve kullanıcı eğitimini geliştirmek için değerlidir.
Neden önemli
Talep sahibini belirler, kullanıcısına, departmanına veya müşterisine göre talep hacimlerinin ve türlerinin analizini mümkün kılar.
Nereden alınır
Bu, bir Jira talebindeki 'reporter' (talep eden) alanına karşılık gelir.
Örnekler
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Çözüm
Resolution
|
Çözümlenmiş bir hizmet talebinin nihai sonucu veya kararı. | ||
|
Açıklama
Çözüm alanı, bir hizmet talebinin neden kapatıldığını belirtir. Yaygın değerler arasında 'Tamamlandı', 'Yapılmayacak', 'Tekrar Eden' veya 'Yeniden Oluşturulamaz' bulunur. Yalnızca 'Çözüldü' veya 'Kapalı' durumunun ötesinde kapanış ayrıntıları sağlar. Çözümleri analiz etmek, sonuçların kalitesini ve niteliğini anlamaya yardımcı olur. Örneğin, yüksek sayıda 'Tekrar Eden' çözüm, talep gönderme sürecinde bir soruna işaret edebilirken, hangi çözümlerin yeniden açılan taleplere yol açtığını izlemek etkisiz çözümleri vurgulayabilir.
Neden önemli
Bir talebin sonucuna ilişkin bağlam sağlar, çözüm kalitesini analiz etmeye ve taleplerin neden kapatıldığına dair eğilimleri belirlemeye yardımcı olur.
Nereden alınır
Bu, bir Jira talebindeki 'resolution' (çözüm) alanına karşılık gelir; bu alan genellikle talep bir 'tamamlandı' durum kategorisine geçtiğinde ayarlanır.
Örnekler
TamamlandıYapılmayacakYinelenenÇözüldü
|
|||
|
Kanal
Channel
|
E-posta, Portal veya API gibi hizmet talebini oluşturmak için kullanılan gönderim yöntemi. | ||
|
Açıklama
Kanal özniteliği, bir hizmet talebinin sisteme nasıl girdiğini belirtir. Jira Service Management'taki yaygın kanallar arasında müşteri portalı, e-posta veya bir temsilci tarafından doğrudan oluşturma yer alır. Süreci kanala göre analiz etmek, kullanıcı davranışını anlamak ve hizmet sunumunu optimize etmek için önemlidir. Belirli kanallardan gelen taleplerin çözülmesinin daha uzun sürüp sürmediğini veya daha fazla açıklama gerektirip gerektirmediğini ortaya çıkarabilir; bu da portalda daha iyi formlara veya iyileştirilmiş e-posta ayrıştırma kurallarına ihtiyaç duyulduğunu gösterebilir. Bu, 'Hizmet Talebi İşlem Hacmi Trendleri' Dashboard'unu destekler.
Neden önemli
Başvuru kanalının çözüm sürelerini, talep netliğini veya genel süreç verimliliğini etkileyip etkilemediğini analiz etmeye yardımcı olur.
Nereden alınır
Bu bilgi, Jira Service Management'ta 'Request channel type' (Talep kanalı tipi) alanı aracılığıyla mevcuttur. Belirli API erişimi gerektirebilir veya özel bir alanda saklanabilir.
Örnekler
portalemailapi
|
|||
|
Önceliklendirme-Atama Süresi
TriageToAssignmentTime
|
Bir talebin önceliklendirildiği an ile bir temsilciye atandığı an arasındaki süre. | ||
|
Açıklama
Bu, bir hizmet talebinin başlangıç işleme ve yönlendirme aşamasının verimliliğini ölçen hesaplanmış bir süre metriğidir. 'Talep Atandı' etkinliği ile 'Talep Önceliklendirildi' etkinliği arasındaki zaman farkı olarak hesaplanır. Bu metrik, 'Ortalama Önceliklendirme-Atama Süresi' KPI'ının ve 'Önceliklendirme ve Atama Verimliliği' Dashboard'unun temelidir. Buradaki uzun bir süre, hizmet masasının alım sürecinde, örneğin önceliklendirme için yetersiz personel veya atama için doğru ekibi belirlemede gecikmeler gibi bir darboğazı gösterebilir.
Neden önemli
Talep işleme sürecinin kritik ilk adımlarının verimliliğini ölçer, iş başlamadan önceki gecikmeleri vurgular.
Nereden alınır
Veri dönüştürme sırasında, 'Talep Önceliklendirildi' olayının zaman damgası, 'Talep Atandı' olayının zaman damgasından çıkarılarak hesaplanır.
Örnekler
3009001800
|
|||
|
Organization
Organization
|
Talep eden kişinin ait olduğu müşteri kuruluşu veya dahili departman. | ||
|
Açıklama
Bu öznitelik, talep edenleri kuruluşlar veya departmanlar halinde gruplandırır. Jira Service Management, temsilcilerin birden fazla müşteri veya dahili ekipten gelen talepleri yönetmesine olanak tanıyan yerleşik bir 'Kuruluşlar' özelliğine sahiptir. Kuruluşa göre analiz yapmak değerli iş bağlamı sağlar. Hangi müşterilerin veya departmanların en çok destek kaynağını tükettiğini, belirli grupların tekrar eden sorunlar yaşayıp yaşamadığını ve farklı iş birimleri arasında SLA'ların tutarlı bir şekilde karşılanıp karşılanmadığını belirlemeye yardımcı olabilir.
Neden önemli
Müşteri veya dahili departmana göre hizmet talebi ve performans analizini kolaylaştırarak önemli iş içgörüleri sağlar.
Nereden alınır
Bu veri, Jira Service Management'taki hizmet talebiyle ilişkili 'Organizations' (Kuruluşlar) alanından gelir.
Örnekler
Acme CorporationFinans Departmanı`Global Tech Inc.`
|
|||
|
SLA Durumu
SlaState
|
Hizmet talebinin tanımlanmış SLA'sını karşılayıp karşılamadığını, ihlal edip etmediğini veya içinde olup olmadığını gösterir. | ||
|
Açıklama
SLA Durumu, her bir hizmet talebini SLA son tarihine göre performansına göre kategorize eden hesaplanmış bir özniteliktir. Olası değerler arasında 'Karşılandı', 'İhlal Edildi' veya 'Devam Ediyor' bulunur. Çözüm zaman damgasının 'SlaDueDate' ile karşılaştırılmasıyla belirlenir. Bu, 'Hizmet Talep SLA Performansı' Dashboard'u için temel özniteliktir ve 'SLA Uyumluluk Oranı' KPI'ını hesaplamak için kullanılır. Raporlama, sözleşme yönetimi ve hizmet kalitesini sürdürmek için kritik olan hizmet seviyesi uyumluluğunun net ve hızlı bir görünümünü sağlar.
Neden önemli
Hizmet kalitesinin ve sözleşme uyumluluğunun kritik bir ölçütü olan SLA performansının net ve anında bir göstergesini sağlar.
Nereden alınır
Veri dönüştürme sırasında hesaplanır. Çözüm süresi 'SlaDueDate'dan önceyse durum 'Karşılandı'; aksi takdirde 'İhlal Edildi'dir.
Örnekler
Karşılandıİhlal EdildiDevam Ediyor
|
|||
|
Tedarikçi Etkileşim Süresi
VendorEngagementDuration
|
Bir hizmet talebinin harici bir tedarikçiyi bekleyerek geçirdiği toplam süre. | ||
|
Açıklama
Bu, bir hizmet talebinin harici bir tedarikçiyle olduğunu gösteren bir durumda geçirdiği toplam süreyi özetleyen hesaplanmış bir metriktir. 'Tedarikçi Etkileşimi Başladı' ve 'Tedarikçi Etkileşimi Sona Erdi' etkinlikleri arasındaki süreyi bularak ve tek bir vakada birden çok kez meydana gelmeleri durumunda bu süreleri toplayarak hesaplanır. Bu öznitelik, 'Harici Tedarikçi Etkileşimi Gecikmeleri' Dashboard'u ve 'Ortalama Harici Tedarikçi Süresi' KPI'ı için esastır. Üçüncü taraf bağımlılıklarından kaynaklanan gecikmeleri nicel olarak belirlemeye yardımcı olur; bu da tedarikçi ilişkilerini yönetmek ve gerçekçi müşteri beklentileri belirlemek için kritiktir.
Neden önemli
Harici bağımlılıkların neden olduğu gecikmeleri izole eder ve nicelendirir, tedarikçi performansını yönetmeye ve tahminleri iyileştirmeye yönelik veriler sağlar.
Nereden alınır
Veri dönüştürme sırasında, 'Tedarikçi Etkileşimi Başladı' ve 'Tedarikçi Etkileşimi Sona Erdi' olayları arasındaki zaman ölçülerek hesaplanır.
Örnekler
172800604800259200
|
|||
|
Vaka Cycle Time
CaseCycleTime
|
Bir hizmet talebinin oluşturulmasından nihai kapanışına kadar geçen toplam süre. | ||
|
Açıklama
Vaka Döngü Süresi, bir hizmet talebinin yaşam döngüsünün toplam süresini ölçen hesaplanmış bir metriktir. Tipik olarak 'Hizmet Talebi Kapandı' zaman damgası ile 'Hizmet Talebi Oluşturuldu' zaman damgası arasındaki fark olarak hesaplanır. Bu, süreç madenciliğindeki en önemli KPI'lardan biridir ve 'Ortalama Hizmet Talebi Döngü Süresi' KPI'ını ve 'Hizmet Talebi Uçtan Uca Döngü Süresi' kontrol panelini doğrudan destekler. Genel süreç verimliliğinin ve müşteri bekleme süresinin üst düzey bir ölçümünü sağlar.
Neden önemli
Bu, genel süreç verimliliğini ve uçtan uca müşteri deneyimini ölçmek için birincil bir KPI'dır.
Nereden alınır
Veri dönüştürme sırasında, her vaka için oluşturulma zaman damgası, son kapanış zaman damgasından çıkarılarak hesaplanır.
Örnekler
864003600007200
|
|||
|
Yeniden Açıldı mı?
IsReopened
|
Bir hizmet talebinin çözümlendikten sonra yeniden açılıp açılmadığını gösteren bir boolean bayrağı. | ||
|
Açıklama
Bu hesaplanmış öznitelik, bir talebin iş akışı 'Yeniden Açılan Talep' etkinliğini içeriyorsa doğru olarak ayarlanan bir doğru/yanlış bayrağıdır. Her bir vaka için etkinlik dizisini analiz ederek elde edilir. Bu bayrak, 'Hizmet Talebi Yeniden Açılma Oranı' KPI'ını hesaplamak ve 'Yeniden Açılan Hizmet Talebi Hacmi' Dashboard'unu desteklemek için esastır. Yüksek bir yeniden açılma oranı, zayıf ilk çözüm kalitesinin güçlü bir göstergesidir ve yeniden çalışmaya ve müşteri memnuniyetinin azalmasına yol açar. Bu bayrakla hangi talep veya çözüm türlerinin ilişkili olduğunu analiz etmek, iyileştirme alanlarını belirleyebilir.
Neden önemli
Süreç etkinliğinin ve müşteri memnuniyetinin temel göstergeleri olan yeniden işleme ve ilk seferde çözüm kalitesini doğrudan ölçer.
Nereden alınır
Veri dönüştürme sırasında, bir vaka için aktivite dizisinin 'Çözüldü' geçişinden sonra 'Yeniden Açıldı' geçişi içerip içermediği kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Hizmet Talep Yönetimi Etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm Önerildi
|
Birçok hizmet masası iş akışında, bu, talep sahibine onay için bir çözümün sunulduğu ayrı bir adımdır. Bu, sorunun durumu 'Müşteri Onayı Bekleniyor' veya 'Onay Bekleniyor' gibi bir duruma değiştiğinde çıkarılır. | ||
|
Neden önemli
Bu etkinlik, bir çözüm sağlandıktan sonra müşteri geri bildirimi bekleyerek geçen süreyi izole eder ve bunu dahili çalışma süresinden ayırmaya yardımcı olur.
Nereden alınır
Sorun geçmişinden, durumun çözümün müşteri onayı beklediğini gösteren bir duruma değiştiği zaman damgasında yakalanır.
Yakala
'Müşteri Onayı Bekleniyor' veya eşdeğer bir durum değişikliğinin zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Hizmet Talebi Çözüldü
|
Talebin tamamlandığı ve çözümün kaydedildiği resmi zaman noktasını işaretler. Jira, bir sorun ilk kez 'Tamamlandı' kategorisindeki bir duruma girdiğinde 'Çözüm Tarihi' alanını doldurur. | ||
|
Neden önemli
Bu, süreç için birincil bitiş kilometre taşıdır; çözüm süresini ve SLA uyumluluğunu hesaplamak için kritiktir. Aktif çalışmanın sonunu işaret eder.
Nereden alınır
Bu açık bir olaydır. Zaman damgası, Jira talebinin 'Resolution Date' (Çözüm Tarihi) alanındaki değerdir; bu alan, 'Tamamlandı' kategori durumuna ilk geçişte ayarlanır.
Yakala
Jira talebindeki 'resolutiondate' (çözüm tarihi) alanını kullanın. Bu alan otomatik olarak doldurulur.
Event tipi
explicit
|
|||
|
Hizmet Talebi Kapatıldı
|
Müşteri hizmet talebinin nihai, idari kapanışını temsil eder. Çoğunlukla 'Çözüldü' durumunda belirli bir süre kaldıktan sonra otomatik olarak gerçekleşir. Bu, Jira'daki talebin yaşam döngüsünün son noktasıdır. | ||
|
Neden önemli
Bu, sürecin kesin bitiş olayıdır. 'Çözüldü' ve 'Kapalı' arasındaki süre, idari yükü veya otomatik kapanış politikalarını anlamak için analiz edilebilir.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, 'Kapalı' veya eşdeğer bir son duruma son durum değişikliğine karşılık gelir.
Yakala
'Kapalı' durumuna son durum değişikliğinin zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Servis Talebi Oluşturuldu
|
Bu etkinlik, bir kullanıcının bir portal, e-posta veya başka bir kanal aracılığıyla resmi olarak bir talep göndermesiyle hizmet talebi yaşam döngüsünün başlangıcını işaretler. Bu olay, 'Hizmet Talebi' türünde yeni bir talep oluşturulduğunda Jira'da açıkça yakalanır ve oluşturma zaman damgasını kaydeder. | ||
|
Neden önemli
Bu, süreç için birincil başlangıç olayıdır. Genel döngü süresini hesaplamak ve talep hacmini ve geliş modellerini anlamak için esastır.
Nereden alınır
Bu, talep geçmişi tablosunda yakalanan açık bir olaydır. Etkinlik zaman damgası, Jira talebindeki 'created' (oluşturuldu) alanıdır.
Yakala
Talep oluşturma zaman damgasını 'issues' (talepler) tablosundan veya geçmişinden kullanın.
Event tipi
explicit
|
|||
|
Talep Atandı
|
Bu etkinlik, bir hizmet talebinin çözümlenmek üzere belirli bir temsilciye veya ekibe atanmasıyla gerçekleşir. Jira, 'Atanan Kişi' alanındaki değişiklikleri açıkça izleyerek, atamanın ne zaman yapıldığına dair net bir zaman damgası sağlar. | ||
|
Neden önemli
Bu, Önceliklendirme-Atama süresini ve temsilci iş yükü dağılımını ölçmek için önemli bir kilometre taşıdır. Kuyruğa girmeden aktif işlemeye geçişi işaret eder.
Nereden alınır
Sorun geçmişinden, 'Atanan Kişi' alanının ilk kez ayarlandığı veya atanmamış durumdan değiştirildiği örnek aranarak yakalanır.
Yakala
Talep geçmişindeki ilk 'Assignee' (atanan) alan değişikliğinin zaman damgasını kullanın.
Event tipi
explicit
|
|||
|
Bilgi Sağlandı
|
Talep sahibinin gerekli bilgileri sağlayarak yanıt vermesiyle, temsilcinin çalışmaya devam etmesine olanak tanıdığında meydana gelir. Bu, sorunun 'Müşteri bekleniyor' durumundan çıktığında çıkarılır, genellikle talep sahibinin bir yorum eklemesiyle tetiklenir. | ||
|
Neden önemli
Bu etkinlik, müşteriyle talep-yanıt döngüsünü tamamlar. Bilgi talep etme ve alma arasındaki süre, süreç bekleme süresinin temel bir bileşenidir.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, sorunun durumu 'Müşteri bekleniyor'dan tekrar 'Devam Ediyor' durumuna değiştiğinde karşılık gelir.
Yakala
'durum' alanının bir 'bekleme' durumundan tekrar 'aktif' bir duruma geçtiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Bilgi Talep Edildi
|
Bir temsilcinin çözüme devam etmek için talep sahibinden daha fazla bilgi istediği noktayı işaretler. Bu genellikle sorunun 'Müşteri bekleniyor' veya 'Giriş Bekleniyor' gibi bir duruma geçişiyle çıkarılır. | ||
|
Neden önemli
Sık veya uzun 'Bilgi İstendi' döngüleri, belirsiz başlangıç başvurularını veya verimsiz iletişimi gösterebilir, bu da önemli bir gecikme kaynağını temsil eder.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, sorunun durumu 'Müşteri bekleniyor' veya eşdeğer bir duruma değiştiğinde karşılık gelir.
Yakala
'durum' alanının sürecin müşteriyi beklediğini gösteren bir değere değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Çözüm Onaylandı
|
Talep sahibinin önerilen çözümü resmi olarak kabul etmesiyle meydana gelir, genellikle 'Çözüldü' durumuna otomatik bir geçişi tetikler. Bu olay, tipik olarak bu durum değişikliğinden çıkarılır. | ||
|
Neden önemli
Bu kilometre taşı, çözümün etkinliğini doğrular ve SLA saatini durdurmak için tetikleyicidir. Müşterilerin düzeltmeleri onaylaması için geçen süreyi ölçmeye yardımcı olur.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, sorunun durumu 'Müşteri Onayı Bekleniyor'dan 'Çözüldü' veya 'Kapalı'ya değiştiğinde karşılık gelir.
Yakala
'Müşteri Onayı Bekleniyor' durumundan 'Çözüldü' veya 'Kapalı' durumuna geçişin zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Çözüm Uygulandı
|
Temsilcinin hizmet talebini ele almak için gerekli eylemleri gerçekleştirdiğini veya bir çözüm geliştirdiğini gösterir. Bu genellikle 'İnceleme Bekleniyor' veya doğrudan 'Çözüldü' durumuna geçişten çıkarılır. | ||
|
Neden önemli
Bu kilometre taşı, temel çözüm çalışmasının tamamlandığını işaret eder. Bu etkinliğe kadar geçen süre, genellikle sürecin birincil katma değerli kısmını temsil eder.
Nereden alınır
Sorun geçmişinden, 'Çözüldü', 'Kabul Bekleniyor' veya benzer bir kapanış öncesi durumuna geçişin zaman damgasına karşılık gelir.
Yakala
'durum' alanının işin tamamlandığını gösteren bir değere değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Talep Tasnif Edildi
|
Bir hizmet talebinin başlangıç değerlendirmesini ifade eder; burada önceliği, kategorisi ve etkisi belirlenir. Bu etkinlik, genellikle 'Yeni'den 'Devam Ediyor'a geçiş veya özel bir 'Önceliklendirilmiş' durumu gibi bir durum değişikliğinden çıkarılır. | ||
|
Neden önemli
Önceliklendirme süresini analiz etmek, ilk talep işleme sürecinin verimliliğini değerlendirmeye yardımcı olur. Buradaki gecikmeler, genel çözüm sürelerini ve SLA uyumluluğunu önemli ölçüde etkileyebilir.
Nereden alınır
Sorun geçmişinden, başlangıçtaki 'Yeni' veya 'Açık' durumundan 'Devam Ediyor' gibi aktif bir duruma ilk durum değişikliğinin zaman damgası belirlenerek çıkarılır.
Yakala
Projenin iş akışına göre 'Yeni' veya eşdeğer bir ilk durumdan ilk durum değişikliğini belirleyin.
Event tipi
inferred
|
|||
|
Talep Yeniden Açıldı
|
Bu etkinlik, daha önce çözülmüş bir hizmet talebinin aktif bir duruma geri döndüğü durumları yakalar. Çözülmüş veya kapalı bir durumdan açık veya devam eden bir duruma geri dönüş durum değişikliği ile çıkarılır. | ||
|
Neden önemli
Yeniden açılan talepleri izlemek, çözüm kalitesini ve İlk Seferde Çözüm Oranını ölçmek için kritiktir. Yüksek bir yeniden açılma oranı, etkisiz çözümleri veya tekrar eden sorunları gösterir.
Nereden alınır
Sorun geçmişinden, 'Çözüldü' veya 'Kapalı' kategori durumundan 'Açık' veya 'Devam Ediyor' kategori durumuna bir durum geçişi belirlenerek çıkarılır.
Yakala
Bir 'Tamamlandı' durum kategorisinden 'Yapılacak' veya 'Devam Ediyor' durum kategorisine bir durum değişikliği arayın.
Event tipi
inferred
|
|||
|
Tedarikçi Etkileşimi Başladı
|
Bu etkinlik, hizmet talebinin harici bir tedarikçiye veya üçüncü tarafa iletildiğini veya onlardan eylem gerektirdiğini gösterir. Bu durum, talebin 'Tedarikçi Bekleniyor' veya 'Üçüncü Taraf İle' gibi bir duruma geçişinden anlaşılır. | ||
|
Neden önemli
Tedarikçi etkileşimini izlemek, dahili hizmet masasının doğrudan kontrolü dışındaki harici bağımlılıkları ve gecikmeleri belirlemek için çok önemlidir.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, sorunun durumu belirlenmiş bir 'tedarikçi' durumuna değiştiğinde karşılık gelir.
Yakala
'durum' alanının 'Tedarikçiden Bekleniyor' gibi bir değere değiştiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||
|
Tedarikçi Etkileşimi Sona Erdi
|
Harici tedarikçinin eylemini tamamladığı ve hizmet talebinin dahili ekibe geri döndüğü anı temsil eder. Bu durum, talebin 'Tedarikçi Bekleniyor' durumundan çıktığında anlaşılır. | ||
|
Neden önemli
Tedarikçi etkileşiminin süresini ölçmek, tedarikçi performansını yönetmeye ve dış tarafların genel çözüm süreleri üzerindeki etkisini anlamaya yardımcı olur.
Nereden alınır
Sorun geçmişinden çıkarılır. Zaman damgası, sorunun durumu bir 'tedarikçi' durumundan tekrar 'Devam Ediyor' durumuna değiştiğinde karşılık gelir.
Yakala
'durum' alanının bir 'tedarikçi' durumundan tekrar 'aktif' bir duruma geçtiği zaman damgasını belirleyin.
Event tipi
inferred
|
|||