Hizmet Talebi Yönetimi Veri Template'inuz

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 zaman damgası (zaman damgası)'i temsil eder.

Aktiviteleri analiz etmek, Process Mining'in temelini oluşturur. Gerçek süreç akışının keşfedilmesini ve görselleştirilmesini sunar. Aktivitelerin sırasını ve sıklığını inceleyerek, analistler ortak yolları, standart süreçten sapmaları, taleplerin takıldığı Darboğazlar (Bottlenecks)i 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 sunar.

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ığı tam tarih ve saati kaydeder. Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve faaliyetlerin süresi ile genel olay süreç döngüsünü hesaplamak için büyük önem taşır. 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 büyük önem taşır.

Bu zaman damgası (zaman damgası), olayları doğru sıralamak ve döngü süreleri ve darboğazlar gibi zamanla ilgili tüm metrikleri hesaplamak için büyük önem taşır.

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

BT Hizmet Talebi Yönetimi ID'si, süreç döngüsü boyunca her hizmet talebini benzersiz bir şekilde tanımlayan birincil temel rol oynar. Tüm ilgili aktiviteleri, durum değişikliklerini ve nitelikleri tutarlı bir süreç örneğinda bir araya getiren case tanımlayıcı olarak işlev görür.

Process Mining analizinde bu ID, her talebin tüm sürecini yeniden yapılandırmak için büyük önem taşır. Tüm olayları ortak bir CaseId altında gruplandırarak, analistler süreç akışlarını görselleştirebilir, vaka 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 en önemli bileşenidir.

Bu ID, bir hizmet talebinin tüm olaylarıni bir araya getirerek eksiksiz bir uçtan uca süreç görünümü güçlüak için büyük önem taşır.

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 izlenebilirliğinın net olmasını sunar.

Çoğu süreç akış analizinde doğrudan kullanılmasa da, veri yönetimi, doğrulama ve sorun giderme için büyük önem taşır. Birden fazla kaynaktan gelen verileri birleştirirken, bu öznitelik analistlerin süreç görünümünü sisteme göre segmentlere ayırmasına sunar; 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 büyük önem taşır; ö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 zaman damgası (zaman damgası)'ini sunar. 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ı sunar.

Bu öznitelik, üretilen stratejik bilgilerin zamanında sağlanması için bağlam sağladığından, operasyonel izleme ve raporlama için büyük önem taşır. 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ı güçlüak için kritik 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 sunar.

Ekipler arasındaki süreç devirlerini analiz etmek, transferlerdeki gecikmeleri belirlemek ve ekip performansını karşılaştırmak için büyük önem taşır.

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, süreç döngüsü boyunca farklı temsilcilere atanabilir.

Bu öznitelik, performans ve iş yükü analizi için büyük önem taşır. 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ı sunar. 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 sunar.

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 önemli bilgi, belirli hizmet kategorileri için hedeflenen süreç iyileştirme çabalarına sunar.

Farklı talep kategorilerine göre süreçleri filtrelemeye ve karşılaştırmaya sunar, her tür için benzersiz Darboğazlar (Bottlenecks)i veya verimsizlikleri ortaya çıkarır.

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

SLA Bitiş Zamanıtiş Tarihi, talebe ilişkin Hizmet Seviyesi Anlaşması'na göre hesaplanan hedeflenen bir zaman damgası (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ş Zamanıtiş 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 süreç 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ü sunar.

Talep Durumunu analiz etmek, süreç akışını ve durum geçişlerini anlamak için temel rol oynar. 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 sunar, 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 büyük önem taşır. 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 büyük önem taşır.

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 yeni veriler keşfedebilir. Ö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 faaliyetin 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 olayların ayrı bir Bitiş Zamanı yoktur, çünkü bazıları anlık olabilir.

Bu öznitelik, bireysel aktivitelerin işlem süresini hesaplamak için büyük önem taşır. 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 aktivitelerin 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 faaliyetin 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 sunar, 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 sunar. 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 sunar, ihlal edilen talepleri filtrelemeyi ve raporlamayı kolaylaştırır.

Bu, veri dönüşümü sırasında nihai çözüm zaman damgası (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 sunar.

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 sunar.

Kurumsal bağlam sunar, iş birimine göre talep modellerinin ve hizmet talebinin analizine sunar.

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 güçlüak 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.