Hizmet Talep Yönetimi Veri Şablonunuz

BMC Helix ITSM
Hizmet Talep Yönetimi Veri Şablonunuz

Hizmet Talep Yönetimi Veri Şablonunuz

Bu şablon, hizmet talep yönetimi süreciniz için toplanacak temel veri niteliklerinin ve izlenecek ana aktivitelerin net bir genel bakışını sunar. Ayrıca, bu verileri BMC Helix ITSM'den verimli bir şekilde nasıl çıkaracağınıza dair pratik rehberlik içerir. Veri hazırlığınızı kolaylaştırmak ve süreç madenciliği girişimlerinize güvenle başlamak için bu kaynağı kullanın.
  • Toplanması Önerilen Nitelikler
  • Takip Edilmesi Gereken Temel Aktiviteler
  • BMC Helix ITSM için `data` çekim rehberliği
Event log'lara yeni mi başlıyorsunuz? Öğrenin Process Mining event log'u nasıl oluşturulur.

Hizmet Talep Yönetimi Nitelikleri

Bu veri alanları, hizmet talep yönetimi sürecinizin derinlemesine analizini sağlayan kapsamlı bir olay günlüğü oluşturmak için elzemdir.
5 Gerekli 6 Önerilen 10 İsteğe Bağlı
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

Activity'ler, süreç haritasının yapı taşlarını oluşturur. Bunları takip etmek, süreç akışının görselleştirilmesine ve analizine olanak tanır, işin gerçekte nasıl yapıldığını ortaya koyar.

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

Data kaynağı hakkında bağlam sağlar, bu da çok sistemli ortamlarda data governance, izlenebilirlik ve sorun giderme için önemlidir.

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ı data'ların güncelliği hakkında bilgilendirir, bu da mevcut en güncel süreç performans bilgilerine dayanarak karar vermek için hayati öneme sahiptir.

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

Activity işlem sürelerinin hesaplanmasını sağlar, bu da verimsiz adımları belirlemek ve kaynakların zamanlarını nerede harcadığını anlamak için çok önemlidir.

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 dashboard'larda önemli bir boyuttur ve kaynakların en kritik iş ihtiyaçlarına uygun şekilde tahsis edilmesini sağlamaya yardımcı olur.

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 bottleneck'leri belirlemenin anahtarıdır.

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, data kalitesini ve genel cycle time'ı nasıl etkilediğini anlamaya yardımcı olur, belirli kanallarda hedeflenmiş iyileştirmelere olanak tanır.

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 handoff sayıları genellikle daha uzun çözüm süreleri ve daha düşük süreç verimliliği ile ilişkilidir.

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 event'in (örn. 'Service Request Submitted') timestamp'i ile son çözüm event'inin (örn. 'Service Request Resolved') timestamp'i arasındaki fark olarak hesaplanır.

Bu, Process Mining'deki en temel KPI'lardan biridir ve Hizmet Talebi Çözüm Süresi dashboard'unu doğrudan destekler. Ortalama cycle time'ı analiz etmek ve hizmet türü veya öncelik gibi boyutlara göre dilimlemek, sürecin genel verimliliğini ortaya koyar ve çok uzun süren alanları vurgular.

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ış data sağlar, çözüm etkinliğinin ve tamamlanmama veya iptal nedenlerinin analizini mümkün kılar.

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 timestamp karşılaştırmasını basit bir boolean flag'ine dönüştürerek SLA performans analizini basitleştirir, uyumluluk oranlarını ölçmeyi ve görselleştirmeyi kolaylaştırır.

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 case'leri işaretleyerek süreç verimsizliğini nicelleştirir, döngülerin ve tekrarlanan işlerin temel nedenlerini belirlemeye yardımcı olur.

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
Gerekli Önerilen İsteğe Bağlı

Hizmet Talep Yönetimi Aktiviteleri

Bu önemli süreç adımları ve kilometre taşları, doğru süreç keşfi ve görselleştirme için olay günlüğünüze kaydedilmelidir.
6 Önerilen 8 İsteğe Bağlı
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 timestamp'ini belirleyin.

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
Önerilen İsteğe Bağlı

Veri Çekim Kılavuzları

BMC Helix ITSM'den verilerinizi nasıl alırsınız?