Hizmet talebi yönetimi veri şablonunuz
Hizmet talebi yönetimi veri şablonunuz
- Ayrıntılı analiz için önerilen öznitelikler
- Süreç keşfi için izlenecek temel etkinlikler
- Jira Service Management için veri çıkarma yönergeleri
Hizmet talebi yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Başlangıç zamanı
EventTime
|
Belirli bir etkinliğin veya olayın gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Başlangıç zamanı veya olay zaman damgası, bir etkinliğin gerçekleştiği kesin anı kaydeder. Tüm sürece zaman bağlamı sağladığı için Process Mining analizlerinin temel bileşenlerinden biridir. Bu zaman damgası, olayları sıraya koymak, etkinlikler arasındaki süreyi hesaplamak, toplam vaka çevrim sürelerini ölçmek ve süreç performansını SLA gibi zamana bağlı hedeflerle karşılaştırmak için kullanılır. Zaman damgaları doğru değilse süreç akışını anlamak, gecikmeleri belirlemek veya verimliliği ölçmek mümkün olmaz.
Neden önemli?
Olayları sıralamak, süreleri ve çevrim zamanlarını hesaplamak, süreç darboğazlarını belirlemek için bu zaman damgası gereklidir.
Nereden alınır?
Jira kaydının değişiklik günlüğündeki her durum geçişine ait zaman damgasıdır. Kaydın oluşturulma zamanı 'created' alanında tutulur.
Örnekler
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
Etkinlik
ActivityName
|
Hizmet talebinin yaşam döngüsü boyunca gerçekleşen belirli olayın veya görevin adıdır. | ||
|
Açıklama
Bu öznitelik, bir hizmet talebi için belirli bir anda gerçekleşen eylemi veya durum geçişini açıklar. Örnekler arasında 'Talep oluşturuldu', 'Talep atandı', 'Çözüm uygulandı' ve 'Talep kapatıldı' yer alır. Bu etkinliklerin sırasını ve sıklığını incelemek, Process Mining çalışmalarının temelini oluşturur. Süreç haritalarını görselleştirmeyi, darboğazları belirlemeyi ve standart iş akışından sapmaları tespit etmeyi sağlar. Bunlar, süreç verimliliğini ve uyumluluğu anlamak açısından önemlidir.
Neden önemli?
Süreç adımlarını tanımlar; süreç haritasını görselleştirmeyi, iş akışı örüntülerini ve sapmaları incelemeyi sağlar.
Nereden alınır?
Genellikle Jira kaydının 'status' geçiş geçmişinden elde edilir. Kaydın durum alanına ait değişiklik günlüğündeki her satır bir etkinliği temsil eder.
Örnekler
Talep ön değerlendirmeden geçtiBilgi istendiÇözüm uygulandıHizmet talebi kapatıldı
|
|||
|
Hizmet talebi kimliği
ServiceRequestId
|
Her hizmet talebine ait benzersiz tanımlayıcıdır ve ilgili tüm olaylar için birincil anahtar görevi görür. | ||
|
Açıklama
Jira’da genellikle Issue Key olarak adlandırılan hizmet talebi kimliği, kullanıcı veya sistem tarafından gönderilen her hizmet talebini benzersiz biçimde tanımlar. İlk kayıttan son kapatmaya kadar sonraki tüm olayları birbirine bağlayan ana referanstır. Böylece her hizmet talebinin baştan sona izlediği yol analiz edilebilir. Process Mining çalışmalarında bu kimlik, vakaları ilişkilendirmek için gereklidir. Her etkinliğin, durum değişikliğinin ve zaman damgasının doğru taleple eşleştirilmesini sağlar ve analiz için tutarlı bir süreç örneği oluşturur.
Neden önemli?
Bu kimlik, ilgili tüm etkinlikleri tek bir uçtan uca süreç akışında birleştiren temel vaka tanımlayıcısıdır ve süreç analizini mümkün kılar.
Nereden alınır?
Jira Service Management’ta bir kaydın 'key' alanıdır.
Örnekler
SR-2023-001IT-45892HELP-105
|
|||
|
Kaynak sistem
SourceSystem
|
Hizmet talebi verilerinin alındığı sistem. | ||
|
Açıklama
Bu öznitelik, verinin kaynağını belirtir. Bu örnekte kaynak Jira Service Management’tır. Tek bir kaynaktan gelen verileri incelerken önemsiz görünebilir, ancak birden fazla sistemden alınan süreç verileri birleştirildiğinde önem kazanır. Analiz sırasında veri kökenini izlemeye ve veri kalitesini korumaya yardımcı olur. Ayrıca farklı yazılım platformlarını kapsayan veya bu platformlarla etkileşen süreçleri filtrelemeyi ve karşılaştırmayı sağlar.
Neden önemli?
Verinin kaynağını belirtir. Veri yönetişimi ve farklı kurumsal sistemlerden gelen süreç verilerini birleştirme açısından önemlidir.
Nereden alınır?
Genellikle veri çıkarma ve dönüştürme sırasında Veri Seti kaynağını belirtmek için eklenen sabit bir değerdir.
Örnekler
Jira Service ManagementJiraSM
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verinin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
|
Açıklama
Bu öznitelik, Jira Service Management’tan en son veri çıkarımının tarih ve saatini kaydeder. Dashboardlarda ve KPI’larda yer alan analizlerin ve verilerin ne kadar güncel olduğunu anlamak için gerekli bağlamı sağlar. Bilgiye dayalı kararlar almak için verinin güncelliğini bilmek önemlidir. Bu zaman damgası, kullanıcıların gerçek zamanlı bilgileri mi yoksa daha önceki bir ana ait anlık görüntüyü mü incelediğini anlamasına yardımcı olur. Bu da bulguların geçerliliğini etkiler.
Neden önemli?
Analizlerin güncel bilgilere dayanmasını sağlayarak verinin ne kadar yeni olduğunu gösterir.
Nereden alınır?
Veri çıkarma aracı veya betiği tarafından çalıştırma tamamlandığında oluşturulan ve kaydedilen bir meta veri alanıdır.
Örnekler
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Atanan kişi
Assignee
|
Hizmet talebi üzerinde çalışmakla şu anda görevlendirilmiş kullanıcı veya temsilci. | ||
|
Açıklama
Atanan kişi, hizmet talebinde bir sonraki adımı atmaktan veya talebi çözmekten sorumludur. Talep farklı temsilcilere ya da ekiplere devredildikçe bu özniteliğin değeri yaşam döngüsü boyunca birkaç kez değişebilir. Bu öznitelik, iş yükü analizinde, performans ölçümünde ve kaynak yönetiminde önem taşır. Süreci temsilciye göre filtrelemeyi, kişilerin çözüm sürelerini karşılaştırmayı ve darboğazlara yol açabilecek eğitim ihtiyaçlarını veya iş yükü dengesizliklerini belirlemeyi sağlar.
Neden önemli?
Temsilcilerin iş yükünü incelemeye, bireysel performansı ölçmeye ve kaynak dağılımını anlamaya yardımcı olur.
Nereden alınır?
Jira kaydındaki 'assignee' alanına karşılık gelir.
Örnekler
Alice JohnsonBob WilliamsAtanmamış
|
|||
|
SLA son tarihi
SlaDueDate
|
SLA’ya göre hizmet talebinin çözülmesi gereken hedef tarih ve saat. | ||
|
Açıklama
SLA son tarihi, bir talebin çözülmesi için belirlenen süreyi gösteren hesaplanmış bir zaman damgasıdır. Talebin önceliğine ve türüne, ayrıca Jira Service Management’ta tanımlanan Hizmet Seviyesi Anlaşması (SLA) politikalarına göre belirlenir. Bu öznitelik, 'Hizmet talebi SLA performansı' Dashboardu ve 'SLA hedefini karşılama oranı' KPI’ı için temel oluşturur. Gerçek çözüm süresi bu son tarihle karşılaştırılarak her talebin zamanında tamamlanıp tamamlanmadığı, gecikip gecikmediği veya SLA ihlali riski taşıyıp taşımadığı belirlenebilir.
Neden önemli?
Performansı ölçmek için referans noktasıdır. SLA uyumluluğunun hesaplanmasına doğrudan katkı sağlar ve işlere öncelik vermeye yardımcı olur.
Nereden alınır?
SLA bilgileri Jira Service Management’ta yönetilir ve API üzerinden alınabilir. Genellikle dinamik olarak güncellenen özel alanlarda tutulur.
Ö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, hizmet talebinin 'Open', 'In Progress', 'Waiting for Customer' veya 'Resolved' gibi mevcut durumunu gösterir. Talebin belirli bir andaki durumunun anlık görüntüsünü sunar. Etkinlik günlüğü geçmiş akışı gösterirken mevcut durum, açık iş yükünü incelemek ve beklemede kalan kayıtları belirlemek için kullanışlıdır. Örneğin, 'Waiting for Vendor' durumunda olağandışı uzun süre kalan talepleri inceleyerek harici bağımlılıkları ve gecikmeleri ortaya çıkarabilirsiniz.
Neden önemli?
Her vakanın mevcut durumunu gösterir; devam eden işleri incelemeyi ve bekleyen ya da uzun süredir açık kalan talepleri belirlemeyi sağlar.
Nereden alınır?
Jira kaydındaki 'status' alanıdır.
Örnekler
AçıkDevam ediyorMüşteriden yanıt bekleniyorÇözüldü
|
|||
|
Talep önceliği
RequestPriority
|
Hizmet talebine atanan öncelik düzeyi. Düşük, Orta, Yüksek veya Kritik olabilir. | ||
|
Açıklama
Talep önceliği, hizmet talebinin aciliyetini ve iş üzerindeki etkisini gösterir. Bu sınıflandırma, taleplerin hangi sırayla ele alınacağını belirler ve çoğu zaman hedef çözüm sürelerini ve SLA’ları etkiler. Süreç analizinde öncelik, verileri gruplara ayırmak için önemli bir boyuttur. Farklı öncelik düzeylerindeki çevrim sürelerini ve SLA uyumluluğunu karşılaştırmayı, yüksek öncelikli taleplerin daha hızlı işlenip hedeflerini karşılayıp karşılamadığını görmeyi sağlar. Böylece önceliklendirme sisteminin ne kadar etkili olduğu değerlendirilebilir.
Neden önemli?
Yüksek öncelikli taleplerin daha hızlı ele alınıp daha sıkı hizmet hedeflerini karşılayıp karşılamadığını incelemek için analizi gruplara ayırmayı sağlar.
Nereden alınır?
Jira kaydındaki 'priority' alanına karşılık gelir.
Örnekler
En yüksekYüksekOrtaDüşük
|
|||
|
Talep türü
RequestType
|
Hizmet talebinin sınıflandırmasıdır. Örneğin, 'Erişim talebi' veya 'Donanım sorunu'. | ||
|
Açıklama
Talep türü, hizmet taleplerini niteliklerine göre sınıflandırır. Farklı talep türlerinin çözüm süreçleri, SLA’ları ve kaynak ihtiyaçları farklı olabildiğinden analiz için temel bir boyuttur. Kuruluşlar, süreç analizini talep türüne göre gruplandırarak iyileştirmeleri belirli iş akışlarına uyarlayabilir. Örneğin, 'Parola sıfırlama' talebindeki darboğaz, 'Yeni sunucu kurulumu' talebindekinden çok farklı olabilir. Bu öznitelik, 'Kategoriye göre çözüm kalitesi' gibi ilgili Dashboardlar oluşturmak için önemlidir.
Neden önemli?
Farklı hizmet talebi kategorilerindeki süreçleri, iş yüklerini ve performansı karşılaştırmaya yardımcı olur.
Nereden alınır?
Genellikle Jira’daki 'issuetype' alanına veya Jira Service Management’taki özel 'Request Type' alanına karşılık gelir.
Örnekler
Yeni hesap talep etBT desteği alYeni çalışanı işe başlat
|
|||
|
Atanan ekip
AssignedTeam
|
Hizmet talebini ele almaktan sorumlu ekip veya grup. | ||
|
Açıklama
Bu öznitelik, talebe atanan ekibi belirtir. Ekip, genellikle tek bir atanan kişiden daha geniş bir grubu kapsar. Örneğin, Birinci Seviye Destek ekibinin performansını Ağ Operasyonları ekibiyle karşılaştırmak için kullanılabilir. 'Vekil iş yükü ve çözüm metrikleri' gibi Dashboardlar için önemli bir boyuttur. Performans metriklerini ekip düzeyinde bir araya getirerek adil karşılaştırmalar yapmayı ve farklı ekiplerin genel hizmet sunumuna katkısını anlamayı sağlar.
Neden önemli?
Performansı ve iş yükü dağılımını tek tek temsilciler yerine ekip veya departman düzeyinde incelemeyi sağlar.
Nereden alınır?
Jira’daki özel bir alan olabilir (ör. 'Team') veya atanan kişinin kullanıcı profili özniteliklerinden elde edilebilir.
Örnekler
BT desteği - 1. seviyeAltyapı ekibiUygulama desteği
|
|||
|
Bildiren kişi
Reporter
|
Hizmet talebini ilk oluşturan veya bildiren kullanıcı. | ||
|
Açıklama
Bildiren kişi, hizmet talebini gönderen ve çoğunlukla son kullanıcı ya da müşteri olan kişidir. Bu öznitelik, süreci başlatan paydaşı belirtir. Analizde bu öznitelik, farklı kullanıcıların, departmanların veya müşteri gruplarının talep örüntülerini anlamak için kullanılabilir. 'En çok talebi hangi departmanlar gönderiyor?' veya 'Belirli kullanıcılar aynı sorunlarla tekrar tekrar karşılaşıyor mu?' gibi soruları yanıtlamaya yardımcı olur. Bu bilgi, sorunları önceden ele almak ve kullanıcı eğitimini iyileştirmek açısından faydalıdır.
Neden önemli?
Talebi başlatan kişiyi belirtir; kullanıcı, departman veya müşteri bazında talep hacmini ve türlerini incelemeyi sağlar.
Nereden alınır?
Jira kaydındaki 'reporter' alanına karşılık gelir.
Örnekler
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Çözüm
Resolution
|
Çözüme ulaşmış bir hizmet talebinin nihai sonucu veya kapanış bilgisi. | ||
|
Açıklama
Resolution alanı, hizmet talebinin neden kapatıldığını belirtir. Yaygın değerler arasında 'Done', 'Won’t Do', 'Duplicate' ve 'Cannot Reproduce' bulunur. Yalnızca 'Resolved' veya 'Closed' durumunu göstermekle kalmaz, kapanışın ayrıntılarını da sunar. Çözüm bilgilerini incelemek, sonuçların niteliğini ve türünü anlamaya yardımcı olur. Örneğin, çok sayıda 'Duplicate' sonucu talep gönderme sürecinde bir sorun olduğuna işaret edebilir. Yeniden açılan taleplere hangi çözümlerin yol açtığını izlemek ise etkisiz çözümleri ortaya çıkarabilir.
Neden önemli?
Talebin sonucu hakkında bağlam sağlar; çözüm kalitesini incelemeye ve taleplerin neden kapatıldığına ilişkin eğilimleri belirlemeye yardımcı olur.
Nereden alınır?
Jira kaydındaki 'resolution' alanına karşılık gelir. Bu alan genellikle kayıt 'done' durum kategorisine geçtiğinde ayarlanır.
Örnekler
TamamlandıYapılmayacakYinelenenDüzeltildi
|
|||
|
Kanal
Channel
|
Hizmet talebini oluşturmak için kullanılan gönderim yöntemi. Örneğin e-posta, portal veya API. | ||
|
Açıklama
Kanal özniteliği, hizmet talebinin sisteme nasıl ulaştığını belirtir. Jira Service Management’ta yaygın kanallar arasında müşteri portalı, e-posta veya bir temsilcinin doğrudan oluşturduğu kayıtlar bulunur. Süreci kanala göre incelemek, kullanıcı davranışını anlamak ve hizmet sunumunu iyileştirmek açısından önemlidir. Bazı kanallardan gelen taleplerin çözümü daha uzun sürüyor veya daha fazla açıklama gerektiriyorsa portal formlarını iyileştirmek ya da e-posta ayrıştırma kurallarını gözden geçirmek gerekebilir. Bu analiz, 'Hizmet talebi iş hacmi eğilimleri' Dashboardunu destekler.
Neden önemli?
Gönderim kanalının çözüm sürelerini, talebin açıklığını veya genel süreç verimliliğini etkileyip etkilemediğini incelemeye yardımcı olur.
Nereden alınır?
Bu bilgiye Jira Service Management’taki 'Request channel type' alanından ulaşılabilir. Özel API erişimi gerekebilir veya bilgi özel bir alanda tutulabilir.
Örnekler
portale-postaapi
|
|||
|
Kuruluş
Organization
|
Talebi bildiren kişinin bağlı olduğu müşteri kuruluşu veya dahili departman. | ||
|
Açıklama
Bu öznitelik, talepleri bildiren kişileri kuruluşlara veya departmanlara göre gruplandırır. Jira Service Management’ta temsilcilerin birden fazla müşteriden veya dahili ekipten gelen talepleri yönetmesini sağlayan yerleşik bir 'Organizations' özelliği bulunur. Kuruluşa göre analiz, iş açısından değerli bir bağlam sunar. Hangi müşterilerin veya departmanların en fazla destek kaynağı kullandığını, belirli grupların tekrar eden sorunlarla karşılaşıp karşılaşmadığını ve farklı iş birimlerinde SLA hedeflerinin tutarlı biçimde karşılanıp karşılanmadığını belirlemeye yardımcı olabilir.
Neden önemli?
Müşteri veya dahili departman bazında hizmet talebini ve performansı incelemeyi kolaylaştırır, iş açısından önemli içgörüler sunar.
Nereden alınır?
Bu veri, Jira Service Management’ta hizmet talebiyle ilişkilendirilmiş 'Organizations' alanından alınır.
Örnekler
Acme CorporationFinans departmanıGlobal Tech Inc.
|
|||
|
SLA durumu
SlaState
|
Hizmet talebinin tanımlı SLA hedefini karşılayıp karşılamadığını, ihlal edip etmediğini veya hâlâ hedef süresi içinde olup olmadığını gösterir. | ||
|
Açıklama
SLA durumu, her hizmet talebini SLA son tarihine göre sınıflandıran hesaplanmış bir özniteliktir. Olası değerler arasında 'Karşılandı', 'İhlal edildi' ve 'Devam ediyor' bulunur. Çözüm zaman damgası 'SlaDueDate' ile karşılaştırılarak belirlenir. Bu öznitelik, 'Hizmet talebi SLA performansı' Dashboardunun temelini oluşturur ve 'SLA hedefini karşılama oranı' KPI’ını hesaplamak için kullanılır. Hizmet düzeyi uyumluluğunu bir bakışta gösterir. Bu bilgi raporlama, sözleşme yönetimi ve hizmet kalitesini koruma açısından önemlidir.
Neden önemli?
SLA performansını açık ve hızlı biçimde gösterir. Bu, hizmet kalitesinin ve sözleşme uyumluluğunun önemli bir ölçüsüdür.
Nereden alınır?
Veri dönüştürme sırasında hesaplanır. Çözüm zamanı 'SlaDueDate' tarihinden önceyse durum 'Karşılandı', değilse 'İhlal edildi' olur.
Örnekler
Karşılandıİhlal edildiDevam ediyor
|
|||
|
Yeniden açıldı mı
IsReopened
|
Hizmet talebinin çözüldükten sonra yeniden açılıp açılmadığını belirten bir boole işareti. | ||
|
Açıklama
Bu hesaplanmış öznitelik, talebin iş akışında 'Talep yeniden açıldı' etkinliği varsa true değerini alan bir doğru/yanlış işaretidir. Her vaka için etkinlik sırası incelenerek elde edilir. Bu işaret, 'Hizmet talebinin yeniden açılma oranı' KPI’ını hesaplamak ve 'Yeniden açılan hizmet taleplerinin hacmi' Dashboardunu oluşturmak için gereklidir. Yeniden açılma oranının yüksek olması, ilk seferde çözüm kalitesinin düşük olduğuna işaret eder. Bu durum yeniden çalışmaya ve müşteri memnuniyetinin düşmesine yol açar. Bu işaretle ilişkili talep türlerini veya çözümleri inceleyerek iyileştirme alanlarını belirleyebilirsiniz.
Neden önemli?
Yeniden çalışmayı ve ilk seferde çözüm kalitesini doğrudan ölçer. Bunlar, süreç etkinliğinin ve müşteri memnuniyetinin temel göstergeleridir.
Nereden alınır?
Veri dönüştürme sırasında, bir vakanın etkinlik sıralamasında 'Resolved' geçişinden sonra 'Reopened' geçişi olup olmadığı kontrol edilerek hesaplanır.
Örnekler
truefalse
|
|||
Hizmet talebi yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm önerildi
|
Birçok hizmet masası iş akışında çözümün talep sahibinin onayına sunulduğu ayrı bir adımdır. Kayıt durumunun "Müşteri onayı bekleniyor" veya "Onay bekleniyor" gibi bir duruma geçmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
Bu etkinlik, çözüm sunulduktan sonra müşteri yanıtı beklerken geçen süreyi ayrı olarak ölçmeye ve bu süreyi kurum içi çalışma süresinden ayırmaya yardımcı olur.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Çözümün müşteri tarafından doğrulanmasının beklendiğini belirten bir duruma geçişin zaman damgası kaydedilir.
Kaydedin
"Müşteri onayı bekleniyor" veya eşdeğer bir duruma geçişin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Hizmet talebi çözüldü
|
Talebin karşılandığı ve çözümün kaydedildiği resmi zamanı belirtir. Jira, bir kayıt ilk kez 'Done' kategorisindeki bir duruma geçtiğinde 'Resolution Date' alanını doldurur. | ||
|
Neden önemli?
Bu, sürecin temel bitiş kilometre taşlarından biridir; çözüm süresini ve SLA uyumluluğunu hesaplamak için önemlidir. Aktif çalışmanın sona erdiğini gösterir.
Nereden alınır?
Bu, açıkça kaydedilen bir olaydır. Zaman damgası, Jira kaydındaki 'Resolution Date' alanının değeridir. Bu alan, kayıt ilk kez 'Done' kategorisindeki bir duruma geçtiğinde ayarlanır.
Kaydedin
Jira kaydındaki 'resolutiondate' alanını kullanın. Bu alan otomatik olarak doldurulur.
Olay türü
explicit
|
|||
|
Hizmet talebi kapatıldı
|
Hizmet talebinin idari açıdan tamamen kapatıldığını gösterir. Bu işlem, talep 'Resolved' durumunda belirli bir süre kaldıktan sonra genellikle otomatik olarak gerçekleşir. Jira’da kaydın yaşam döngüsünün son noktasıdır. | ||
|
Neden önemli?
Bu, sürecin kesin bitiş olayıdır. 'Resolved' ile 'Closed' arasındaki süreyi inceleyerek idari iş yükünü veya otomatik kapatma politikalarını değerlendirebilirsiniz.
Nereden alınır?
Kayıt geçmişinden çıkarılır. Zaman damgası, 'Closed' veya eşdeğer bir son duruma yapılan son geçişi gösterir.
Kaydedin
'Closed' durumuna yapılan son geçişin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Hizmet talebi oluşturuldu
|
Bu etkinlik, kullanıcının portal, e-posta veya başka bir kanal üzerinden resmi olarak talep iletmesiyle hizmet talebinin yaşam döngüsünü başlatır. Jira, "Hizmet Talebi" türünde yeni bir kayıt oluşturulduğunda bu olayı açıkça kaydeder ve oluşturulma zaman damgasını tutar. | ||
|
Neden önemli?
Bu, sürecin temel başlangıç olayıdır. Toplam çevrim süresini hesaplamak, talep hacmini ve geliş örüntülerini anlamak için gereklidir.
Nereden alınır?
Bu olay, kayıt geçmişi tablosunda açıkça tutulur. Etkinliğin zaman damgası, Jira kaydındaki 'created' alanıdır.
Kaydedin
Sorunun oluşturulma zaman damgasını 'issues' tablosundan veya geçmişinden alın.
Olay türü
explicit
|
|||
|
Talep atandı
|
Bir hizmet talebi çözüm için belirli bir temsilciye veya ekibe atandığında bu etkinlik gerçekleşir. Jira, "Assignee" alanındaki değişiklikleri açıkça izleyerek atamanın yapıldığı zaman damgasını kaydeder. | ||
|
Neden önemli?
Bu, ön değerlendirmeden atamaya kadar geçen süreyi ve temsilcilerin iş yükü dağılımını ölçmek için önemli bir kilometre taşıdır. Kuyrukta beklemeden etkin biçimde ele alınmaya geçişi gösterir.
Nereden alınır?
Kayıt geçmişinde "Assignee" alanının ilk kez doldurulduğu veya atanmamış durumdan değiştirildiği an bulunarak saptanır.
Kaydedin
Kayıt geçmişindeki ilk "Assignee" alanı değişikliğinin zaman damgasını kullanın.
Olay türü
explicit
|
|||
|
Bilgi istendi
|
Temsilcinin çözüm sürecini sürdürebilmek için talep sahibinden ek bilgi istediği anı belirtir. Genellikle kaydın "Müşteri bekleniyor" veya "Bilgi bekleniyor" gibi bir duruma geçmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
Sık sık veya uzun süren "Bilgi istendi" döngüleri, ilk başvuruların yeterince açık olmadığını ya da iletişimin verimsiz yürüdüğünü gösterebilir ve önemli bir gecikme kaynağı oluşturur.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, kaydın durumunun "Müşteri bekleniyor" veya eşdeğer bir duruma geçtiği ana karşılık gelir.
Kaydedin
'status' alanının, sürecin müşteriden yanıt beklediğini belirten bir değere değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Bilgi sağlandı
|
Talep sahibi gerekli bilgileri ilettiğinde ve temsilci çalışmaya devam edebildiğinde gerçekleşir. Genellikle talep sahibinin yorum eklemesiyle kaydın "Müşteri bekleniyor" durumundan çıkmasından çıkarımla belirlenir. | ||
|
Neden önemli?
Bu etkinlik, müşteriyle yürütülen talep-yanıt döngüsünü tamamlar. Bilgi talebi ile yanıtın alınması arasında geçen süre, süreçteki bekleme süresinin önemli bir bölümüdür.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, kaydın durumunun "Müşteri bekleniyor" durumundan yeniden "Devam ediyor" durumuna geçtiği ana karşılık gelir.
Kaydedin
'status' alanının 'waiting' durumundan yeniden 'active' durumuna geçtiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Çözüm onaylandı
|
Talep sahibi önerilen çözümü resmi olarak kabul ettiğinde gerçekleşir ve çoğu zaman durumun otomatik olarak "Çözüldü" durumuna geçmesini sağlar. Bu olay genellikle söz konusu durum değişikliğinden çıkarımla belirlenir. | ||
|
Neden önemli?
Bu kilometre taşı çözümün etkili olduğunu doğrular ve SLA sayacının durdurulmasını sağlar. Müşterilerin çözümleri onaylamasının ne kadar sürdüğünü ölçmeye yardımcı olur.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, durumun "Müşteri onayı bekleniyor" durumundan "Çözüldü" veya "Kapalı" durumuna geçtiği ana karşılık gelir.
Kaydedin
'Pending Customer Acceptance' durumundan 'Resolved' veya 'Closed' durumuna geçişin zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Çözüm uygulandı
|
Temsilcinin hizmet talebini karşılamak için gerekli işlemleri yaptığını veya bir çözüm geliştirdiğini belirtir. Genellikle durumun "İnceleme bekleniyor" ya da doğrudan "Çözüldü" olarak değişmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
Bu kilometre taşı, temel çözüm çalışmalarının tamamlandığını gösterir. Bu etkinliğe kadar geçen süre, sürecin asıl değer üreten bölümünü oluşturur.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, durumun "Çözüldü", "Onay bekleniyor" veya kapanış öncesindeki benzer bir duruma geçtiği ana karşılık gelir.
Kaydedin
'status' alanının işin tamamlandığını belirten bir değere değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Talep ön değerlendirmeden geçti
|
Bir hizmet talebinin önceliğinin, kategorisinin ve etkisinin belirlendiği ilk değerlendirmeyi ifade eder. Bu etkinlik genellikle durumun "Yeni" durumundan "Devam ediyor" durumuna geçmesi veya özel bir "Ön değerlendirmeden geçti" durumuna geçiş gibi bir durum değişikliğinden çıkarımla belirlenir. | ||
|
Neden önemli?
Ön değerlendirme süresini analiz etmek, ilk talep işleme sürecinin verimliliğini değerlendirmeye yardımcı olur. Bu aşamadaki gecikmeler toplam çözüm sürelerini ve SLA hedeflerine uyumu ciddi ölçüde etkileyebilir.
Nereden alınır?
Kayıt geçmişinde, ilk "Yeni" veya "Açık" durumundan "Devam ediyor" gibi etkin bir duruma geçişin ilk zaman damgası belirlenerek çıkarımla saptanır.
Kaydedin
Projenin iş akışına göre "Yeni" veya eşdeğer bir başlangıç durumundan gerçekleşen ilk durum değişikliğini belirleyin.
Olay türü
inferred
|
|||
|
Talep yeniden açıldı
|
Bu etkinlik, daha önce çözülmüş bir hizmet talebinin yeniden etkin duruma döndüğü durumları kaydeder. Çözülmüş veya kapalı durumdan açık ya da devam ediyor durumuna geçişle çıkarımla belirlenir. | ||
|
Neden önemli?
Yeniden açılan talepleri izlemek, çözüm kalitesini ve ilk seferde çözüm oranını ölçmek açısından önemlidir. Yeniden açılma oranının yüksek olması, çözümlerin etkisiz kaldığını veya sorunların tekrarlandığını gösterir.
Nereden alınır?
Kayıt geçmişinde, "Çözüldü" veya "Kapalı" kategorisindeki bir durumdan "Açık" veya "Devam ediyor" kategorisindeki bir duruma geçiş belirlenerek saptanır.
Kaydedin
"Tamamlandı" durum kategorisinden "Yapılacak" veya "Devam ediyor" durum kategorisine geçiş olup olmadığını kontrol edin.
Olay türü
inferred
|
|||
|
Tedarikçiyle çalışma başladı
|
Bu etkinlik, hizmet talebinin harici bir tedarikçiye aktarıldığını veya tedarikçinin işlem yapmasının gerektiğini belirtir. Kaydın "Tedarikçi bekleniyor" veya "Üçüncü tarafla çalışılıyor" gibi bir duruma geçmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
Tedarikçiyle yürütülen çalışmaları izlemek, kurum içi hizmet masasının doğrudan kontrolü dışındaki harici bağımlılıkları ve gecikmeleri belirlemek açısından önemlidir.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, kaydın belirlenmiş bir "tedarikçi" durumuna geçtiği ana karşılık gelir.
Kaydedin
'status' alanının 'Waiting for Vendor' gibi bir değere değiştiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
|
Tedarikçiyle çalışma sona erdi
|
Harici tedarikçinin işlemini tamamlayıp hizmet talebinin kurum içi ekibe döndüğü anı ifade eder. Kaydın "Tedarikçi bekleniyor" durumundan çıkmasından çıkarımla belirlenir. | ||
|
Neden önemli?
Tedarikçiyle çalışmanın süresini ölçmek, tedarikçi performansını yönetmeye ve harici tarafların toplam çözüm sürelerine etkisini anlamaya yardımcı olur.
Nereden alınır?
Kayıt geçmişinden çıkarımla belirlenir. Zaman damgası, kaydın "tedarikçi" durumundan yeniden "Devam ediyor" durumuna geçtiği ana karşılık gelir.
Kaydedin
'status' alanının 'vendor' durumundan yeniden 'active' durumuna geçtiği zaman damgasını belirleyin.
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Process Mining çalışmalarınıza bu şablonla başlayın ve hizmet talebi yönetiminizi önemli ölçüde iyileştirin. Operasyonlarınızı bugün iyileştirmeye başlayın.
Jira’da hizmet talebi yönetimini hemen iyileştirin
%70 otomasyona ulaşın ve yavaş talep karşılamaya son verin. Verimliliği hemen artırın!
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.