Hizmet Talep Yönetimi Veri Template'iniz

Activity özniteliği, bir hizmet talebi üzerinde atılan belirli bir adımı veya eylemi tanımlar. Bu activity'ler, 'Talep Oluşturuldu', 'Talep Atandı', 'Devam Eden İş' ve 'Talep Kapatıldı' gibi sürecin sıralı yapı taşlarını oluşturur. Her activity, bir hizmet talebinin yolculuğunda belirli bir timestamp'i temsil eder.

Activity'leri analiz etmek, Process Mining'in temelini oluşturur. Gerçek süreç akışının keşfedilmesini ve görselleştirilmesini sağlar. Activity'lerin sırasını ve sıklığını inceleyerek, analistler ortak yolları, standart süreçten sapmaları, taleplerin takıldığı Bottleneck'leri ve adımların gereksiz yere tekrarlandığı yeniden işleme döngülerini belirleyebilir.

Süreçteki adımları tanımlar, fiili süreç akışının, darboğazların ve sapmaların keşfedilmesini sağlar.

Genellikle hizmet talebi nesnesiyle ilişkili durum değişikliği günlüklerinden, event tablolarından veya denetim izlerinden türetilir.

Başlangıç Zamanı, belirli bir faaliyetin başladığı kesin tarih ve saati kaydeder. Bu zaman damgası, olayları kronolojik olarak sıralamak ve faaliyetlerin süresi ile genel olay yaşam döngüsünü hesaplamak için çok önemlidir. Doğru bir event log oluşturmak için süreçteki her faaliyetin ilgili bir Başlangıç Zamanı olmalıdır.

Süreç analizinde, Başlangıç Zamanı, döngü süresi, faaliyetler arası bekleme süresi ve faaliyet işleme süresi gibi temel performans göstergelerini (KPI) hesaplamak için kullanılır. Sürecin zaman tabanlı bir görünümünü oluşturmayı, gecikmeleri vurgulamayı ve hangi adımların en çok zaman tükettiğini belirlemeye yardımcı olur. Doğru zaman damgaları, performansla ilgili herhangi bir analiz için temeldir.

Bu zaman damgası, event'leri doğru sıralamak ve döngü süreleri ve darboğazlar gibi zamanla ilgili tüm metrikleri hesaplamak için kritik öneme sahiptir.

Event Log veya denetim izleme tablolarında bulunur, genellikle her activity kaydı için 'oluşturma tarihi' veya 'event timestamp' olarak kaydedilir.

Hizmet Talebi ID'si, yaşam döngüsü boyunca her hizmet talebini benzersiz bir şekilde tanımlayan birincil anahtardır. Tüm ilgili activity'leri, durum değişikliklerini ve öznitelikleri tutarlı bir süreç instance'ında bir araya getiren case identifier olarak işlev görür.

Process Mining analizinde bu ID, her talebin uçtan uca yolculuğunu yeniden yapılandırmak için temeldir. Tüm event'leri ortak bir CaseId altında gruplandırarak, analistler süreç akışlarını görselleştirebilir, case sürelerini hesaplayabilir ve farklı taleplerin nasıl ele alındığına dair varyasyonları belirleyebilir. Hizmet talebi yönetimi sürecinde yapılan herhangi bir analizin temel taşıdır.

Bu ID, bir hizmet talebinin tüm event'lerini bir araya getirerek eksiksiz bir uçtan uca süreç görünümü sağlamak için temeldir.

Genellikle hizmet talepleri için başlık veya ana işlem tablosunda bulunur.

Kaynak Sistem özniteliği, verilerin çıkarıldığı BT Hizmet Yönetimi (ITSM) platformunun veya diğer uygulamanın adını belirtir. Birden fazla sistemin bulunduğu ortamlarda, bu alan veri kaynaklarını ayırt etmeye yardımcı olur ve veri soy ağacının net olmasını sağlar.

Çoğu süreç akış analizinde doğrudan kullanılmasa da, veri yönetimi, doğrulama ve sorun giderme için kritik öneme sahiptir. Birden fazla kaynaktan gelen verileri birleştirirken, bu öznitelik analistlerin süreç görünümünü sisteme göre segmentlere ayırmasına olanak tanır; bu da farklı platformlar arasındaki süreç yürütme veya veri kalitesi farklılıklarını ortaya çıkarabilir.

Veri yönetimi ve sorun giderme için kritik öneme sahiptir; özellikle birden fazla entegre sistemin bulunduğu ortamlarda verinin kökenini netleştirir.

Bu değer genellikle veri çıkarma (ETL) süreci sırasında eklenir ve kaynak sistemin kendisinde doğal bir alan değildir.

Son Veri Güncellemesi, en son veri çıkarma veya yenilemenin bir timestamp'ini sağlar. Kullanıcıları analiz ettikleri verilerin güncelliği hakkında bilgilendirir, analizin mevcut durumu mu yoksa geçmiş bir anlık görüntüyü mü yansıttığını anlamalarını sağlar.

Bu öznitelik, üretilen içgörülerin zamanında sağlanması için bağlam sağladığından, operasyonel izleme ve raporlama için hayati öneme sahiptir. Kullanıcıların verilere güvenmelerine ve güncelliğine dayanarak bilinçli kararlar almalarına yardımcı olur. Örneğin, bir hafta önce güncellenen verileri gösteren bir Dashboard, bir saat önce güncellenen bir Dashboard'dan farklı yorumlanacaktır.

Analizlerin ilgili ve güncel bilgilere dayanmasını sağlamak için hayati önem taşıyan verilerin güncelliğini gösterir.

Bu, genellikle veri çıkarma (ETL) süreci sırasında oluşturulan ve depolanan bir metadata alanıdır.

Atanan Ekip, hizmet talebinden sorumlu belirli destek grubunu ifade eder. Talepler, gereken uzmanlığa bağlı olarak genellikle farklı ekipler (örneğin, 1. Seviye yardım masası, ağ ekibi veya yazılım geliştirme ekibi) arasında yönlendirilir.

Ekipler arasındaki devir teslimleri analiz etmek, hizmet yönetimi Process Mining'inin temel bir parçasıdır. Bu öznitelik, ekipler arası transferlerin görselleştirilmesini sağlayarak iletişim boşluklarını veya gecikmeleri belirlemeye yardımcı olur. Ayrıca, ekipler arasında performans karşılaştırması yaparak verimliliklerini, talep hacimlerini ve talepleri daha fazla yükseltme olmadan çözme yeteneklerini karşılaştırmaya olanak tanır.

Ekipler arasındaki süreç devirlerini analiz etmek, transferlerdeki gecikmeleri belirlemek ve ekip performansını karşılaştırmak için çok önemlidir.

Hizmet talebi kaydında standart bir alan. Bu alandaki değişiklikler bir denetim günlüğünde izlenir.

Atanan Temsilci, belirli bir zamanda hizmet talebini ele almaktan sorumlu belirli kişidir. Bir talep, yaşam döngüsü boyunca farklı temsilcilere atanabilir.

Bu öznitelik, performans ve iş yükü analizi için temeldir. Kuruluşların, ortalama çözüm süreleri ve ele aldıkları talep hacmi dahil olmak üzere bireysel temsilcilerin performansını ölçmesini ve karşılaştırmasını sağlar. Ayrıca, ilk triyaj, temsilci uzmanlığı veya iş yükü dengeleme sorunlarına işaret edebilen temsilciler arasındaki yeniden atamaları analiz etmek için de kullanılır.

Bireysel temsilci performansının, iş yükü dağılımının ve temsilciler arasındaki yeniden atamaların sıklığının analizini sağlar.

Hizmet talebi kaydında mevcuttur. Bu alandaki değişiklikler genellikle bir denetim günlüğünde veya geçmiş tablosunda izlenir.

Hizmet Türü, hizmet talebinin doğasını sınıflandırır. Bu, yeni donanım veya yazılım erişimi taleplerinden genel sorgulamalara veya teknik desteğe kadar değişebilir. Bu kategorizasyon, talebin doğru ekibe yönlendirilmesine ve farklı hizmetlere olan talebin anlaşılmasına yardımcı olur.

Süreç analizinde Hizmet Türü, verileri segmentlere ayırmak için güçlü bir boyuttur. Süreç haritasını farklı hizmet türlerine göre filtreleyerek, kuruluşlar belirli türdeki taleplerin çok farklı süreçleri takip ettiğini, daha uzun döngü sürelerine sahip olduğunu veya daha fazla yeniden işleme deneyimi yaşadığını ortaya çıkarabilir. Bu içgörü, belirli hizmet kategorileri için hedeflenen süreç iyileştirme çabalarına olanak tanır.

Farklı talep kategorilerine göre süreçleri filtrelemeye ve karşılaştırmaya olanak tanır, her tür için benzersiz Bottleneck'leri veya verimsizlikleri ortaya çıkarır.

Hizmet talebi kaydında standart bir alan, genellikle bir hizmet kataloğuna bağlıdır.

SLA Bitiş Tarihi, talebe ilişkin Hizmet Seviyesi Anlaşması'na göre hesaplanan hedeflenen bir zaman damgasıdır. Talebin önceliği, türü ve oluşturulma zamanı gibi faktörler tarafından belirlenir ve beklenen çözüm zaman çerçevesini tanımlar.

Bu öznitelik, tüm SLA uyumluluk analizlerinin temelini oluşturur. Gerçek çözüm süresi ile SLA Bitiş Tarihi karşılaştırılarak, kuruluşlar bir talebin zamanında çözülüp çözülmediğini veya SLA'nın ihlal edilip edilmediğini belirleyebilir. Bu, hizmet kalitesini ölçmek için kritik bir KPI'dır ve gecikmelere yol açan ve ihlallere neden olan sistemik sorunları tespit etmek için kullanılır.

Bu, performansı ölçmek için bir karşılaştırma noktasıdır. SLA uyumluluk oranlarını hesaplamak ve hangi taleplerin ihlal edildiğini belirlemek için kullanılır.

Genellikle hizmet talebi kaydında, uygulanan SLA politikası tarafından belirlenen hesaplanmış bir alan.

Talep Durumu, hizmet talebinin yaşam döngüsündeki belirli bir noktadaki durumunu gösterir. Yaygın durumlar Yeni, Devam Ediyor, Beklemede, Çözüldü ve Kapalı'yı içerir. Bu öznitelik, talebin genel süreçte nerede olduğuna dair bir anlık görüntü sağlar.

Talep Durumunu analiz etmek, süreç akışını ve durum geçişlerini anlamak için anahtardır. Case'leri filtrelemek, belirli bir durumda takılı kalan talepleri belirlemek ve her durumda harcanan süreyi ölçmek için kullanılabilir. Örneğin, taleplerin 'Beklemede' durumunda ne kadar kaldığını analiz etmek, kullanıcılar veya harici ekiplerden bilgi beklemekten kaynaklanan gecikmeleri ortaya çıkarabilir.

Taleplerin her durumda ne kadar süre geçirdiğini analiz etmeye olanak tanır, süreçteki darboğazları veya gecikmeleri vurgular.

Ana hizmet talebi tablosunda veya durum geçmişi günlüklerinde mevcuttur.

Talep Önceliği, destek ekiplerinin talepleri ele alma sırasını belirlemesine yardımcı olan bir sınıflandırmadır. Genellikle talebin iş üzerindeki etkisi ve aciliyeti kombinasyonuna dayanır. Yaygın öncelik seviyeleri Düşük, Orta, Yüksek ve Kritik'i içerir.

Bu öznitelik, performans analizi ve kaynak tahsisi için hayati öneme sahiptir. Analistler, yüksek öncelikli taleplerin uygun şekilde ele alındığından emin olmak için farklı öncelik seviyeleri arasındaki döngü sürelerini ve SLA uyumluluğunu karşılaştırabilir. Ayrıca düşük öncelikli taleplerin göz ardı edilip edilmediğini veya önceliklendirme sisteminin destek ekipleri tarafından doğru bir şekilde takip edilip edilmediğini belirlemeye de yardımcı olur.

Taleplerin iş önemine göre ele alınıp alınmadığını analiz etmek ve önceliğin çözüm süresini nasıl etkilediğini anlamak için hayati öneme sahiptir.

Genellikle ana hizmet talep kaydında standart bir alan.

Gönderim Kanalı, hizmet talebinin nasıl oluşturulduğunu gösterir; örneğin, bir self-service portalı, e-posta, telefon görüşmesi veya API aracılığıyla. Farklı kanalların farklı ilişkili süreçleri veya kullanıcı beklentileri olabilir.

Gönderim kanalına göre süreci analiz etmek önemli içgörüler ortaya çıkarabilir. Örneğin, bir self-service portalı aracılığıyla gönderilen talepler, manuel veri girişi gerektirebilecek e-posta aracılığıyla gönderilenlere göre daha yapılandırılmış ve daha hızlı çözülebilir. Bu analiz, kuruluşların daha verimli kanalları teşvik etmesine veya daha az verimli olanların süreçlerini iyileştirmesine yardımcı olabilir.

Gönderme yönteminin süreç verimliliğini, çözüm süresini veya ilk temas çözüm oranını etkileyip etkilemediğini belirlemeye yardımcı olur.

Genellikle hizmet talep kaydında standart bir alan olarak bulunur.

Bitiş Zamanı, belirli bir activity'nin tamamlandığı kesin tarihi ve saati kaydeder. Başlangıç Zamanı başlangıcı işaret ederken, Bitiş Zamanı bir tek süreç adımının süresini tanımlayarak sonucu işaretler. Tüm event'lerin ayrı bir Bitiş Zamanı yoktur, çünkü bazıları anlık olabilir.

Bu öznitelik, bireysel activity'lerin işlem süresini hesaplamak için hayati öneme sahiptir. Başlangıç Zamanı'nı Bitiş Zamanı'ndan çıkararak, analistler temsilcilerin veya sistemlerin bir görev üzerinde aktif olarak ne kadar süre harcadığını ölçebilirler. Bu, hangi belirli activity'lerin zaman alıcı olduğunu ve optimizasyon veya otomasyon için birincil adaylar olduğunu belirlemeye yardımcı olur.

Etkinlik işlem sürelerinin hesaplanmasını sağlayarak, süreçteki hangi adımların en çok zaman aldığını belirlemeye yardımcı olur.

Event Log veya denetim izleme tablolarında bulunur. Açıkça mevcut değilse, bir sonraki activity'nin Başlangıç Zamanı kullanılarak türetilmesi gerekebilir.

Çözüm Kodu, bir hizmet talebinin sonucunu sınıflandırmak için yapılandırılmış bir yol sunar. Örnekler arasında 'Kullanıcı Tarafından Çözüldü', 'Donanım Değiştirildi', 'Yazılım Dağıtıldı' veya 'Yinelenen Talep' yer alır. Bu bilgi genellikle temsilci tarafından talep kapatılırken girilir.

Bu kodlar, kök neden analizi için değerlidir. Farklı çözüm kodlarının sıklığını analiz ederek, kuruluşlar tekrarlayan sorunları, ortak çözümleri ve bilgi tabanı makaleleri veya otomatik çözümler oluşturma fırsatlarını belirleyebilir. Örneğin, yüksek sayıda 'Şifre Sıfırlama' çözümü, bir self-service şifre sıfırlama aracına yatırım yapılmasını haklı çıkarabilir.

Taleplerin nasıl çözüldüğünü kategorize ederek kök neden analizine olanak tanır, eğilimleri ve proaktif sorun yönetimi alanlarını belirlemeye yardımcı olur.

Genellikle temsilci tarafından hizmet talebi çözümlenirken veya kapatılırken manuel olarak doldurulan bir alan.

Bu boolean öznitelik, hizmet talebinin tanımlanmış hizmet seviyesi anlaşmasını karşılayıp karşılamadığını gösterir. Talep 'SlaDueDate' sonrasında çözülürse doğru, aksi takdirde yanlıştır.

Bu öznitelik, SLA uyumluluk raporlamasını ve analizini basitleştirir. Her sorguda tarih karşılaştırmaları yapmak yerine, bu basit işaret kolay filtreleme ve toplama sağlar. SLA performansına odaklanan Dashboard'lar için birincil bir ölçüttür ve hizmet hedeflerini karşılamayan taleplerin hacmini ve yüzdesini hızlı bir şekilde belirlemeye yardımcı olur.

SLA performans analizi için net ve basit bir işaret sağlar, ihlal edilen talepleri filtrelemeyi ve raporlamayı kolaylaştırır.

Bu, veri dönüşümü sırasında nihai çözüm zaman damgasını 'SlaDueDate' alanı ile karşılaştırarak hesaplanan türetilmiş bir özniteliktir.

Bu öznitelik, hizmet talebini başlatan kişinin departmanını veya iş birimini tanımlar. Talebe kurumsal bağlam sağlar.

Departmana göre talepleri analiz etmek, departmana özgü ihtiyaçları, eğilimleri veya sorunları belirlemeye yardımcı olabilir. Örneğin, Finans departmanından belirli bir talep türünün yüksek hacimli olması, hedeflenmiş bir eğitime veya sistem iyileştirmesine ihtiyaç duyulduğunu gösterebilir. Ayrıca, geri ödeme raporlaması ve kuruluş genelindeki BT hizmetleri talebini anlamak için de olanak tanır.

Kurumsal bağlam sağlar, iş birimine göre talep modellerinin ve hizmet talebinin analizine olanak tanır.

Bu bilgi genellikle talep sahibinin çalışan dizinindeki veya ITSM sistemindeki kullanıcı profilinden çekilir.

Yeniden Atama Sayısı, bir hizmet talebinin bir temsilciden veya ekipten diğerine kaç kez aktarıldığını gösteren bir metriktir. Yüksek bir sayı, yanlış başlangıç yönlendirmesi, temsilci bilgi eksikliği veya net olmayan süreç sahipliği gibi sorunlara işaret edebilir.

Bu, süreç verimsizliğinin temel bir göstergesidir. Process Mining'de bu metrik, bir talebin yaşadığı 'ping-pong' miktarını nicelleştirmeye yardımcı olur. Yüksek yeniden atama sayılarına sahip case'leri analiz etmek, triyaj sürecini iyileştirmek, temsilci eğitimini artırmak veya taleplerin ilk seferde doğru şekilde yönlendirilmesini sağlamak için ekip sorumluluklarını geliştirmek için fırsatlar ortaya çıkarabilir.

Süreç verimsizliğini tespit etmek için önemli bir metrik. Yüksek yeniden atama sayıları genellikle daha uzun çözüm süreleri ve kullanıcı memnuniyetsizliği ile ilişkilidir.

Bu, belirli bir 'CaseId' için 'AssignedAgent' veya 'AssignedTeam' alanının değiştiği sayıyı sayarak elde edilen hesaplanmış bir metriktir.