Hizmet talebi yönetimi için Veri Templateiniz

BMC Helix ITSM
Hizmet talebi yönetimi için Veri Templateiniz

Hizmet talebi yönetimi için Veri Templateiniz

Bu Template, hizmet talebi yönetimi süreciniz için toplanması gereken temel veri özniteliklerini ve izlenecek önemli etkinlikleri açıkça gösterir. Ayrıca bu verileri BMC Helix ITSM’den verimli biçimde nasıl çıkaracağınıza ilişkin pratik yönergeler içerir. Veri hazırlığını kolaylaştırmak ve Process Mining çalışmalarınızı güvenle başlatmak için bu kaynaktan yararlanın.
  • Toplanması önerilen öznitelikler
  • İzlenecek önemli etkinlikler
  • BMC Helix ITSM için veri çıkarma yönergeleri
Olay günlüklerine yeni misiniz? Process Mining için nasıl Event Log oluşturacağınızı öğrenin.

Hizmet talebi yönetimi öznitelikleri

Bu veri alanları, hizmet talebi yönetimi sürecinizi ayrıntılı biçimde analiz etmenizi sağlayacak kapsamlı bir Event Log oluşturmak için gereklidir.
5 Zorunlu 6 Önerilen 9 İsteğe bağlı
Ad Açıklama
Başlangıç zamanı
EventStartTime
Belirli bir etkinliğin veya olayın ne zaman başladığını gösteren zaman damgası.
Açıklama

Bu öznitelik, bir etkinliğin başladığı kesin tarih ve saati kaydeder. Sürecin kronolojik sırasını belirlemek için ilk gönderimden son kapatmaya kadar günlükteki her olayın başlangıç zamanı olmalıdır.

Bu zaman damgası, zamana dayalı tüm Process Mining analizleri için önemlidir. Çevrim sürelerini, etkinliklerin süresini ve adımlar arasındaki bekleme sürelerini hesaplamak, ayrıca SLA uyumunu kontrol etmek için kullanılır. Darboğazları belirlemeye ve süreç performansını zaman içinde analiz etmeye yardımcı olur.

Neden önemli?

Başlangıç zamanı, olayların kronolojik sırasını gösterir. Süreç sürelerini hesaplamak, gecikmeleri belirlemek ve sürecin zaman içindeki akışını anlamak için gereklidir.

Nereden alınır?

Bu bilgi, SRM:Request formuyla ilişkili denetim günlüklerindeki veya durum geçmişi tablolarındaki zaman damgası alanlarına karşılık gelir. İlk olay için Submit Date alanı buna örnektir.

Örnekler
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Etkinlik
ActivityName
Hizmet talebinin yaşam döngüsünde belirli bir anda gerçekleşen olayın veya görevin adı.
Açıklama

Bu öznitelik, Talep inceleniyor, Hizmetin yerine getirilmesi sürüyor veya Hizmet talebi çözüme kavuşturuldu gibi belirli bir adımı ya da durum değişikliğini açıklar. Her etkinlik, hizmet talebinin uçtan uca yolculuğundaki tek bir olayı temsil eder.

Etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining’in temelini oluşturur. Bu analiz, süreç haritalarını keşfetmenizi, darboğazları belirlemenizi ve süreç varyantlarını incelemenizi sağlar. Süreci iyileştirmek için hangi etkinliklerin gerçekleştiğini, hangi sırayla ilerlediğini ve ne sıklıkta tekrarlandığını anlamak önemlidir.

Neden önemli?

Etkinlikler, süreç haritasının temel yapı taşlarıdır. Bunları izleyerek süreç akışını görselleştirebilir ve analiz edebilir, işlerin gerçekte nasıl yürütüldüğünü görebilirsiniz.

Nereden alınır?

Bu bilgi genellikle SRM:Request formundaki Status ve Status Reason alanlarındaki değişikliklerden veya ilgili hizmet uygulaması günlüklerinden (ör. Incident, Work Order) elde edilir.

Örnekler
Talep onay bekliyorHizmetin yerine getirilmesi sürüyorHizmet talebi çözüme kavuşturulduHizmet talebi kapatıldı
Hizmet Talebi Kimliği
ServiceRequestId
Her hizmet talebini benzersiz biçimde tanımlayan ve tüm süreç boyunca izlenmesini sağlayan birincil anahtar.
Açıklama

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 temel referanstır. Böylece her hizmet talebinin yolculuğunu baştan sona analiz edebilirsiniz.

Process Mining’de bu kimlik, her vakanın etkinlik sırasını yeniden oluşturmak için gereklidir. Araç, Talep gönderildi, Talep atandı ve Hizmet talebi kapatıldı gibi ilişkili tüm olayları tek bir süreç örneğinde gruplandırır. Süreç analizinin temeli budur.

Neden önemli?

Bu, temel vaka kimliğidir. Bu kimlik olmadan hizmet talebinin uçtan uca yolculuğunu izlemek mümkün olmaz; dolayısıyla süreci keşfetmek ve analiz etmek de mümkün değildir.

Nereden alınır?

Bu alan, BMC Helix ITSM’deki SRM:Request formunda genellikle InstanceId veya Request Number olarak adlandırılır.

Örnekler
SR000010572931SR000010572932SR000010572933
Kaynak sistem
SourceSystem
Verilerin hangi sistemden çıkarıldığını belirtir.
Açıklama

Bu öznitelik, süreç verilerinin kaynağını belirtir. Bu görünümde, hizmet talepleriyle ilgili tüm olayların bu sistemden alındığını göstermek için BMC Helix ITSM olarak sabitlenir.

Birden fazla sistemin entegre olduğu ortamlarda bu alan, verinin kaynağını izlemek ve verileri kaynağa göre ayırmak için önemlidir. Özellikle farklı platformlardan gelen veriler birleştirildiğinde açıklık ve izlenebilirlik sağlar.

Neden önemli?

Verinin kaynağı hakkında bilgi verir. Bu, birden fazla sistemin kullanıldığı ortamlarda veri yönetişimi, izlenebilirlik ve sorun giderme açısından önemlidir.

Nereden alınır?

Bu, BMC Helix ITSM’de bulunan bir alan değil, veri çıkarma ve dönüştürme sırasında eklenen sabit bir değerdir.

Örnekler
BMC Helix ITSM
Son veri güncellemesi
LastDataUpdate
Bu sürecin verilerinin kaynak sistemden en son yenilendiği zaman damgası.
Açıklama

Bu öznitelik, BMC Helix ITSM’den en son veri çıkarma işleminin tarih ve saatini gösterir. Analiz ettiğiniz verilerin ne kadar güncel olduğunu ve hangi dönemi kapsadığını anlamanıza yardımcı olur.

Bu, Process Mining Dashboardları veya analizleri için önemli bir üst veri özniteliğidir. İçgörülerin neredeyse gerçek zamanlı verilere mi yoksa geçmiş bir anlık görüntüye mi dayandığını gösterir. Bu bilgi, çıkarımların geçerliliğini ve güncelliğini değerlendirmenizi sağlar.

Neden önemli?

Verilerin ne kadar güncel olduğunu gösterir. Böylece mevcut süreç performansı bilgilerine dayanarak karar verebilirsiniz.

Nereden alınır?

Bu zaman damgası, veri çıkarma ve yükleme sırasında oluşturulup eklenir.

Örnekler
2024-05-21T08:00:00Z
Atanan ekip
AssignedTeam
Hizmet talebine şu anda atanmış destek grubu veya ekip.
Açıklama

Bu öznitelik, talebi ele almaktan sorumlu işlevsel grubu belirtir. Örneğin Yardım Masası, Ağ Ekibi veya Veritabanı Yönetimi. Bu alandaki değişiklik, sorumluluğun ekipler arasında devredildiğini gösterir.

Atanan ekibe göre yapılan analiz, ekip düzeyindeki darboğazları belirlemeye, ekipler arası devir teslimleri incelemeye ve farklı destek gruplarının verimliliğini değerlendirmeye yardımcı olur. Talebin kuruluş içinde nasıl yönlendirildiğine ilişkin örüntüleri ortaya çıkararak Talebin Yeniden Çalışılması ve Yeniden Atanması ile Önceliklendirme Verimliliği Dashboardları için temel oluşturur.

Neden önemli?

Farklı işlevsel gruplar arasındaki süreç akışını analiz etmenizi sağlar; yönlendirme verimsizliklerini belirlemeye ve ekip performansını ölçmeye yardımcı olur.

Nereden alınır?

Bu, hizmet talebiyle ilişkili tamamlanma kaydındaki (ör. İş Emri veya Olay) Assigned Group alanına karşılık gelir.

Örnekler
Hizmet MasasıAltyapı Desteği2. Seviye Uygulama Desteği
Atanan temsilci
AssignedAgent
Hizmet talebi üzerinde çalışmak üzere şu anda atanmış olan kullanıcı.
Açıklama

Bu öznitelik, belirli bir anda talepten sorumlu olan BT temsilcisini veya destek personelini belirtir. Tek bir talebin yaşam döngüsü boyunca bu alandaki değişiklikler, talebin başka bir kişiye devredildiğini veya yeniden atandığını gösterir.

Bu öznitelik, temsilci performansını ve iş yükünü analiz etmek için önemlidir. Her temsilcinin kaç talep aldığını, ortalama çözüm süresini ve yeniden atama sıklığını izlemenizi sağlar. Bu veriler, kaynak yönetimini ve eğitim fırsatlarının belirlenmesini destekler.

Neden önemli?

Atanan temsilciyi izlemek; devir teslimleri analiz etmek, bireysel performansı ölçmek ve destek ekibindeki iş yükü dağılımını anlamak için gereklidir.

Nereden alınır?

Bu, hizmet talebiyle ilişkili tamamlanma kaydındaki (ör. İş Emri veya Olay) Assignee ya da Assigned To alanına karşılık gelir.

Örnekler
Bob SmithAlice JohnsonCharlie Brown
Bitiş zamanı
EventEndTime
Belirli bir etkinliğin veya olayın ne zaman tamamlandığını gösteren zaman damgası.
Açıklama

Bitiş zamanı, bir etkinliğin sona erdiği anı gösterir. ITSM sistemlerindeki birçok etkinlik anlık durum değişikliklerinden oluşsa da bazıları ölçülebilir bir süreye sahiptir. Bitiş zamanı, bu etkinliklerin süresini hassas biçimde hesaplamanızı sağlar.

Analizde, tek tek etkinliklerin işlem süresini hesaplamak için Bitiş zamanı ile Başlangıç zamanı birlikte kullanılır. Böylece süreçte en çok zaman alan adımları, yalnızca adımlar arasındaki bekleme sürelerini değil, belirleyebilirsiniz.

Neden önemli?

Etkinliklerin işlem sürelerini hesaplamayı sağlar. Verimsiz adımları belirlemek ve kaynakların zamanını nerede harcadığını anlamak için önemlidir.

Nereden alınır?

Bu değer türetilebilir. Aynı vakadaki bir etkinliğin Bitiş zamanı, çoğu zaman sıradaki etkinliğin Başlangıç zamanıdır. Son etkinlik için çözüm veya kapatma zaman damgası kullanılı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 niteliğini sınıflandırır. Örneğin Yeni yazılım talebi, Parola sıfırlama veya Yeni çalışanı işe başlatma. Süreç verilerini filtrelemek ve gruplara ayırmak için temel bir boyuttur.

Süreç analizinde bu öznitelik, farklı talep türlerinin performansını karşılaştırmak için kullanılır. Hangi hizmet türlerinin çözümünün en uzun sürdüğü veya hangilerinde yeniden çalışmanın daha sık görüldüğü gibi soruları yanıtlamaya yardımcı olur. Çözüm Süresi ve SLA Uyumu Dashboardları için önemlidir.

Neden önemli?

Hizmet taleplerini gruplara ayırarak süreç akışlarını karşılaştırmanızı, belirli talep türlerine özgü sorunları belirlemenizi ve iyileştirme çalışmalarını doğru noktalara yönlendirmenizi sağlar.

Nereden alınır?

Bu veri genellikle SRM:Request formundaki Title alanında veya sınıflandırma alanında bulunur ve katalogdan seçilen hizmete göre belirlenir.

Örnekler
Yeni donanım talebiYazılım erişim talebiVPN erişimi ayarlama
Öncelik
Priority
Hizmet talebine atanan ve iş üzerindeki etkisini ve aciliyetini gösteren öncelik düzeyi.
Açıklama

Öncelik, taleplerin hangi sırayla ve ne hızda ele alınacağını belirler. Yaygın değerler arasında Kritik, Yüksek, Orta ve Düşük bulunur. Öncelik genellikle talebin iş üzerindeki etkisi ve aciliyeti birlikte değerlendirilerek belirlenir.

Önceliğe göre analiz yapmak, yüksek öncelikli taleplerin düşük öncelikli taleplerden daha hızlı işlenip işlenmediğini değerlendirmek için önemlidir. Çözüm süresi ve SLA uyumu Dashboardlarında temel bir boyut olarak kaynakların en önemli iş ihtiyaçlarına uygun biçimde ayrılmasına yardımcı olur.

Neden önemli?

Sürecin işleri doğru biçimde önceliklendirip önceliklendirmediğini ve iş üzerindeki etkisi farklı olan talepler için beklenen hizmet seviyelerini karşılayıp karşılamadığını değerlendirmenizi sağlar.

Nereden alınır?

Bu, SRM:Request formundaki Priority alanıdır.

Örnekler
KritikYüksekOrtaDüşük
Talep durumu
RequestStatus
Olayın gerçekleştiği sırada hizmet talebinin durumu; örneğin In Progress, Pending veya Closed.
Açıklama

Bu öznitelik, hizmet talebinin yaşam döngüsünün farklı noktalarındaki durumunu kaydeder. Durum, her etkinliğe bağlam kazandırır ve çoğu zaman Etkinlik özniteliğinin kaynağını oluşturur.

Duruma göre analiz yapmak, taleplerin Pending Customer veya Waiting for Approval gibi durumlarda ne kadar kaldığını anlamaya yardımcı olur. Bu bilgi, dış bağımlılıklardan veya iç kuyruklardan kaynaklanan darboğazları ve gecikmeleri belirlemek için gereklidir. Darboğazları Belirleme Dashboardunu doğrudan destekler.

Neden önemli?

Talebin belirli bir andaki durumunu gösterir. Böylece beklemede geçen süreyi etkin durumlarda geçen süreyle karşılaştırabilir ve darboğazları belirleyebilirsiniz.

Nereden alınır?

Bu, SRM:Request formundaki Status alanıdır. Geçmiş değerler denetim günlüğünde bulunabilir.

Örnekler
PlanlamaDevam ediyorBeklemedeÇözüme kavuşturulduKapatıldı
Çözüm kategorisi
ResolutionCategory
Talebi çözmek için sunulan çözümün sınıflandırması.
Açıklama

Bu öznitelik, talebin nasıl çözüldüğünü Yazılım düzeltmesi, Kullanıcı eğitimi veya Veri düzeltmesi gibi kategorilerle yapılandırılmış biçimde gösterir. Basit bir kapatma kodundan farklı olarak çözümün niteliğini açıklar.

Çözüm kategorisi doğruluğu Dashboardunda bu bilgi, tutarlılığı denetlemek için başlangıçtaki hizmet türüyle karşılaştırılabilir. Çözüm kategorilerini analiz etmek, sorunlardaki eğilimleri belirlemeye ve proaktif sorun yönetimini planlamaya yardımcı olur. Örneğin, çok sayıda talebin kullanıcı eğitimiyle çözüldüğü görülebilir.

Neden önemli?

Çözümlerin niteliğini göstererek tekrarlayan sorunlardaki eğilimleri ve proaktif sorun yönetimi ya da kullanıcı eğitimi fırsatlarını belirlemeye yardımcı olur.

Nereden alınır?

Bu bilgi, tamamlanma kaydındaki operasyonel ve ürün sınıflandırma alanlarında yer alır; alan genellikle Resolution Category olarak adlandırılır.

Örnekler
Hesap yönetimiDonanım arızasıYazılım yükseltmesiBilgi sağlandı
Devir teslim sayısı
HandoffCount
Bir hizmet talebinin farklı temsilcilere veya ekiplere toplam kaç kez yeniden atandığı.
Açıklama

Bu hesaplanmış metrik, tek bir hizmet talebinde AssignedAgent veya AssignedTeam değerinin kaç kez değiştiğini sayar. Devir teslim sayısının yüksek olması, sürecin parçalı ilerlediğine, ilk görüşmede çözüm oranının düşük olduğuna veya yönlendirmenin verimsiz olduğuna işaret edebilir.

Bu öznitelik, Talep başına ortalama temsilci devir teslimi KPI’ının temelini oluşturur ve Talebin yeniden çalışılması ve yeniden atanması Dashboardunda kullanılır. Devir teslim sayısı yüksek vakaları analiz ederek önceliklendirmeyi iyileştirme, daha iyi eğitim sağlama veya çözüm sürecini sadeleştirme fırsatlarını belirleyebilirsiniz. Böylece gecikmeleri azaltıp müşteri memnuniyetini artırabilirsiniz.

Neden önemli?

Sürecin ne ölçüde parçalandığını ve iletişim için harcanan çabayı ölçer. Devir teslim sayısının yüksek olması genellikle daha uzun çözüm süreleri ve daha düşük süreç verimliliğiyle ilişkilidir.

Nereden alınır?

Bu hesaplanmış metrik, her benzersiz Service Request ID için AssignedAgent veya AssignedTeam özniteliğindeki farklı değerlerin sayılmasıyla elde edilir.

Örnekler
0135
Kapatma kodu
CloseCode
Hizmet talebinin kapanış sonucunu veya nedenini belirten kod.
Açıklama

Kapatma kodu, hizmet talebinin çözümünü standart biçimde sınıflandırır. Örnekler arasında Hizmet Masası tarafından çözüldü, Kullanıcı tarafından iptal edildi veya Yinelenen talep yer alır.

Kapatma kodlarını analiz etmek, taleplerin yaygın sonuçlarını anlamaya yardımcı olur. Kullanıcıların çok sayıda talebi iptal etmesi, sürecin uzun sürdüğüne; çok sayıda yinelenen talep ise sistem veya iletişim sorunlarına işaret edebilir. Bu öznitelik, Çözüm kategorisi doğruluğu Dashboardunu destekler.

Neden önemli?

Talep sonuçlarına ilişkin yapılandırılmış veri sunarak çözüm etkinliğini ve tamamlanmama ya da iptal nedenlerini analiz etmenizi sağlar.

Nereden alınır?

Bu bilgi genellikle hizmet talebiyle ilişkili tamamlanma kaydındaki Resolution veya Closure Code alanında bulunur.

Örnekler
Başarıyla tamamlandıKullanıcı tarafından iptal edildiArtık gerekli değilOtomatik çözüm
SLA hedef tarihi
SlaTargetDate
Hizmet Seviyesi Anlaşması (SLA) uyarınca hizmet talebinin çözülmesinin beklendiği tarih ve saat.
Açıklama

SLA hedef tarihi, hizmet talebinin tamamlanması için son tarihi gösteren hesaplanmış bir zaman damgasıdır. Bu tarih, genellikle talebin önceliği ve türü gibi etkenleri dikkate alan hizmet anlaşması kurallarına göre belirlenir.

Bu öznitelik, SLA Uyumluluğu Genel Bakış Dashboardu için temel verilerden biridir. Gerçek çözüm süresini karşılaştırmak için ölçüt olarak kullanılır. Son çözüm etkinliğinin EventEndTime değeri hedef tarihle karşılaştırılarak hizmet taahhüdünün yerine getirilip getirilmediği belirlenebilir.

Neden önemli?

Hizmet performansını taahhütlerle karşılaştırmak için kullanılan temel ölçüttür; SLA uyumluluğunu izlemek ve raporlamak açısından önemlidir.

Nereden alınır?

Bu tarih, Hizmet Seviyesi Yönetimi (SLM) modülü tarafından hesaplanıp kaydedilir ve hizmet talebiyle bağlantılı SLM formlarında bulunabilir.

Örnekler
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
SLA ihlal edildi mi
IsSlaBreached
Hizmet talebinin SLA hedef tarihinden sonra çözüldüğünü belirten Boole değeri.
Açıklama

Hizmet talebinin son çözüm zaman damgası SLA hedef tarihinden sonraysa bu hesaplanmış işaret true değerini alır. Her talep için SLA performansını basit, ikili bir sonuçla gösterir.

Bu öznitelik, SLA Uyumluluğu Genel Bakış Dashboardu ve SLA uyum oranı KPI’ı için gereklidir. Genel uyum oranlarını hesaplamak üzere verileri kolayca toplamanızı sağlar. Ayrıca, SLA ihlali olan taleplerle uyumlu taleplerin süreç özelliklerini filtreleyip karşılaştırarak SLA başarısızlıklarının temel nedenlerini belirlemenize yardımcı olur.

Neden önemli?

Zaman damgalarını karşılaştırmak yerine basit bir Boole işareti kullanarak SLA performansı analizini kolaylaştırır. Böylece uyum oranlarını ölçüp görselleştirebilirsiniz.

Nereden alınır?

Bu, hesaplanmış bir alandır. Mantık şöyledir: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false.

Örnekler
truefalse
Talep kanalı
SubmissionChannel
Hizmet talebinin iletildiği yöntem veya kanal.
Açıklama

Bu öznitelik, hizmet talebinin nasıl başlatıldığını kaydeder. Örneğin self servis portalı, e-posta, Hizmet Masasına telefon veya otomatik sistem uyarısı. Farklı kanallar, farklı süreç varyantlarına ve çözüm sürelerine yol açabilir.

Süreci talep kanalına göre analiz etmek, belirli başvuru yöntemleriyle ilişkili verimsizlikleri veya iyi uygulamaları ortaya çıkarabilir. Örneğin self servis portalından iletilen talepler, başlangıçtaki veri kalitesi daha yüksek olduğu için daha hızlı çözülebilir. E-postayla gelen talepler ise daha fazla manuel önceliklendirme gerektirebilir.

Neden önemli?

Talep alma yönteminin süreç verimliliğini, veri kalitesini ve genel çevrim süresini nasıl etkilediğini anlamanıza yardımcı olur. Böylece belirli kanallarda hedefli iyileştirmeler yapabilirsiniz.

Nereden alınır?

Bu bilgi, SRM:Request formundaki Client Type veya Reported Source alanlarından ya da ilişkili tamamlanma kayıtlarından çıkarılabilir.

Örnekler
Self servis portalıE-postaTelefonSistem tarafından oluşturuldu
Talep sahibinin departmanı
RequestorDepartment
Talebi ileten kullanıcının iş departmanı veya birimi.
Açıklama

Bu öznitelik, hizmet talebinde bulunan kişinin Finans, İnsan Kaynakları veya BT gibi kurumsal departmanını belirtir. Bu bilgi genellikle kullanıcının sistemdeki profilinden alınır.

Süreç analizini departmana göre bölümlere ayırmak; departmana özgü ihtiyaçları, talep örüntülerini ve hedefli eğitim ya da hizmet iyileştirmesi fırsatlarını belirlemeyi sağlar. Örneğin, Finans departmanının talepleri daha uzun süre mi bekliyor? gibi soruları yanıtlamaya yardımcı olur.

Neden önemli?

Hizmet kullanımını ve süreç performansını iş birimine göre analiz etmenizi sağlar; departmana özgü sorunları veya eğilimleri ortaya çıkarabilir.

Nereden alınır?

Bu bilgi genellikle SRM:Request formundaki Requested For kullanıcısıyla ilişkili kullanıcı profilinden alınır.

Örnekler
FinansSatışİnsan KaynaklarıBilgi Teknolojileri
Üst kademeye aktarıldı mı
IsEscalated
Hizmet talebinin üst kademeye aktarılıp aktarılmadığını belirten Boole değeri.
Açıklama

Hizmet talebi işlevsel veya hiyerarşik olarak üst kademeye aktarıldığında bu işaret true değerini alır. Talep beklendiği gibi ilerlemediğinde, SLA ihlali yaklaşırken ya da onay veya işlem için daha üst düzey yetki gerektiğinde genellikle üst kademeye aktarım yapılır.

Bu öznitelik, Talep üst kademeye aktarım verimliliği analizi Dashboardu için önemlidir. Üst kademeye aktarılan taleplerin süreç yollarını filtreleyip analiz ederek aktarımı neyin tetiklediğini, aktarım sonrasında çözümün ne kadar sürdüğünü ve aktarım sürecinin ne kadar etkili olduğunu anlamanızı sağlar.

Neden önemli?

Üst kademeye aktarım gerektiren talepleri ayırıp analiz etmenizi sağlar. Böylece standart süreçteki zayıf noktaları veya karmaşık sorunları tetikleyen etkenleri belirleyebilirsiniz.

Nereden alınır?

Bu bilgi genellikle tek bir alanda tutulmaz. Denetim günlüğündeki üst kademeye aktarımla ilgili etkinlikler veya aktarım protokolünü izleyen öncelik ya da atama değişiklikleri kontrol edilerek elde edilir.

Örnekler
truefalse
Yeniden çalışma var mı
IsRework
Hizmet talebinin önceki bir aşamaya dönmek gibi yeniden çalışma gerektiren bir süreçten geçtiğini belirten Boole değeri.
Açıklama

Bu işaret, süreç akışında döngüye giren veya yeniden çalışma gerektiren hizmet taleplerini belirler. Örneğin, Tamamlanıyor aşamasından Talep incelemede aşamasına dönen bir talep yeniden çalışma olarak değerlendirilir. Kesin tanım, iş sürecinin mantığına bağlıdır.

Bu öznitelik, Talebin yeniden çalışılması ve yeniden atanması analizi Dashboardunu ve Talebin yeniden çalışma oranı KPI’ını doğrudan destekler. Yeniden çalışma sıklığını ölçmenizi ve hatalı ilk değerlendirme ya da eksik bilgi gibi yaygın nedenleri analiz etmenizi sağlar. Bu nedenler süreçte verimsizliğe yol açabilir.

Neden önemli?

İdeal yoldan sapan vakaları işaretleyerek süreç verimsizliğini ölçer; döngülerin ve tekrarlanan işlerin temel nedenlerini belirlemeye yardımcı olur.

Nereden alınır?

Bu, Event Logdaki etkinlik sırasından elde edilen hesaplanmış bir özniteliktir. Süreç akışındaki geriye dönüşleri saptamak için mantık tanımlanmalıdır.

Örnekler
truefalse
Zorunlu Önerilen İsteğe bağlı

Hizmet talebi yönetimi etkinlikleri

Süreci doğru şekilde keşfedip görselleştirmek için bu temel adımları ve kilometre taşlarını Event Loga ekleyin.
6 Önerilen 8 İsteğe bağlı
Aktivite Açıklama
Hizmet talebi çözüme kavuşturuldu
Hizmet talebinin yerine getirilmesi tamamlanmış ve çözüm talep sahibine bildirilmiştir. Talep, son onayı bekler veya belirlenen süre sonunda otomatik olarak kapatılır.
Neden önemli?

Hizmet sunum döngüsünün sonunu gösteren önemli bir kilometre taşıdır. Çözüm süresini ve SLA’lara uyumu ölçmek için temel bitiş noktasıdır.

Nereden alınır?

SRM:Request formundaki durumun Resolved veya Completed olarak değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Resolved veya Completed olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Hizmet talebi gönderildi
Bu etkinlik, kullanıcının yeni bir hizmet talebi oluşturup göndermesini ifade eder. SRM:Request formunda genellikle Submitted başlangıç durumuyla yeni bir kayıt oluşturulduğunda kaydedilir.
Neden önemli?

Her hizmet talebi vakasının başlangıç noktasıdır. Toplam süreç süresini ölçmek ve gelen talep hacmini analiz etmek için gereklidir.

Nereden alınır?

Bu olay, SRM:Request formundaki kaydın oluşturulma zaman damgası ve başlangıç durumu (ör. Submitted) üzerinden belirlenir.

Kaydedin

Durum Submitted olduğunda, SRM:Request formunda yeni bir Hizmet Talebi Kimliği için oluşturulma zaman damgasını belirleyin.

Olay türü inferred
Hizmet talebi iptal edildi
Hizmet talebi, hizmetin yerine getirilmesi tamamlanmadan önce talep sahibi veya Hizmet Masası tarafından geri çekilmiştir. Bu, talebin sona erdiği bir durumdur.
Neden önemli?

İptalleri izlemek, kullanıcıların yanlış talep gönderdiği veya artık ihtiyaç duyulmayan hizmetleri istediği gibi örüntüleri belirlemeye yardımcı olur. Bu bilgiler, hizmet kataloğunu iyileştirmek için kullanılabilir.

Nereden alınır?

SRM:Request formundaki durumun Canceled olarak değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Canceled olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Hizmet talebi kapatıldı
Hizmet talebi resmen kapatılır ve salt okunur, arşivlenmiş duruma alınır. Bu işlem, talep çözüme kavuşturulduktan ve varsa onay süresi geçtikten sonra gerçekleşir.
Neden önemli?

Bu etkinlik, sürecin kesin olarak sona erdiğini gösterir. Resolved ile Closed arasındaki süre, kapatma işlemindeki verimsizlikleri ortaya çıkarabilir.

Nereden alınır?

SRM:Request formundaki son durum değişikliğinin Closed olmasıyla belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Closed olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Hizmetin yerine getirilmesi sürüyor
Atanan temsilci veya ekip, hizmet talebini yerine getirmek için çalışmaya başlamıştır. Talebin kuyruktan çıkarak etkin çalışma aşamasına geçtiğini gösterir.
Neden önemli?

Hizmete değer katan çalışmaların başlangıcını gösterir. Bu aşamada harcanan süreyi analiz etmek, kaynak verimliliğini ve hizmetin yerine getirilme sürecinin karmaşıklığını anlamaya yardımcı olur.

Nereden alınır?

SRM:Request formundaki durumun In Progress olarak değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının In Progress olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Talep atandı
Hizmet talebi, işi tamamlamaktan sorumlu belirli bir hizmet temsilcisine veya ekibine atanmıştır. Bu, ilk sınıflandırma aşamasının sonunu gösterir.
Neden önemli?

Bu kilometre taşı, ilk sınıflandırma süresini ölçmek ve temsilci iş yükünü analiz etmek için önemlidir. Sık yeniden atamalar, yönlendirme sorunlarına veya beceri eksikliklerine işaret edebilir.

Nereden alınır?

Bu olay, SRM:Request formundaki veya ilgili hizmet uygulaması formlarındaki (ör. WOI:WorkOrder) Assigned Group ya da Assignee alanlarının denetim günlüğünden doğrudan kaydedilebilir.

Kaydedin

Assignee alanına ilk kez boş olmayan bir değer girildiğini gösteren denetim günlüğü zaman damgası.

Olay türü explicit
Çözüm uygulandı
Hizmet talebini yerine getirmek için gereken teknik çalışma temsilci tarafından tamamlanmıştır. Talep, resmen çözüme kavuşturulmadan önce kullanıcıdan onay alınmaya hazırdır.
Neden önemli?

Bu etkinlik, teknik çalışmanın tamamlanmasıyla talebin resmen çözüme kavuşturulmasını birbirinden ayırır. Böylece işin bitmesi ile kullanıcı onayı arasındaki gecikmeleri belirleyebilirsiniz.

Nereden alınır?

Üst SRM:Request kaydı Resolved olarak işaretlenmeden önce, arka uçtaki hizmet talebi kaydının (ör. Work Order durumunun Completed olması) durum değişikliğinden belirlenebilir.

Kaydedin

SRM:Request ile bağlantılı bir arka uç kaydının (Work Order, Incident vb.) tamamlandı olarak işaretlendiği zaman damgası.

Olay türü inferred
Kullanıcı çözümü onayladı
Talep sahibi, hizmetin beklendiği gibi sunulduğunu ve talebin çözüme kavuştuğunu açıkça onaylamıştır. Bu onay çoğu zaman talebin son kez kapatılmasını başlatır.
Neden önemli?

Müşteri memnuniyetini açıkça gösterir ve hizmet etkileşimini resmen tamamlar. Sürecin çözüme ulaşmasıyla müşterinin çözümü kabul etmesini birbirinden ayırır.

Nereden alınır?

Kullanıcı portal veya e-posta üzerinden onay verdiğinde bu olay SRM:Request iş günlüklerine ya da etkinlik notlarına kaydedilebilir. Ancak her zaman ayrı bir durum olarak tutulmaz.

Kaydedin

Kullanıcı onayını veya anketin tamamlandığını gösteren kayıtları bulmak için iş günlüklerini (SRM:WorkInfo) tarayın.

Olay türü explicit
Kullanıcıdan bilgi istendi
Hizmet temsilcisinin çalışmaya devam edebilmesi için talep sahibinden ek bilgi alması gerekir. Talep genellikle Pending durumuna alınır.
Neden önemli?

Bu etkinlik, Dış Bilgi Bekleme Süresi’ni hesaplamak ve eksik bilgi nedeniyle taleplerin ne sıklıkla beklediğini belirlemek için önemlidir.

Nereden alınır?

SRM:Request formundaki durumun Pending olarak değişmesi ve durum nedeninin Customer Hold veya Awaiting Information gibi bir değer olmasıyla belirlenir.

Kaydedin

Pending durumuna geçişin ve belirli bir durum nedeninin zaman damgası.

Olay türü inferred
Talep inceleniyor
Hizmet Masası, talebin niteliğini ve önceliğini belirlemek, ayrıca uygun hizmet ekibini seçmek için ilk inceleme ve sınıflandırmayı yapar. Bu aşama genellikle talep kaydındaki durum değişikliğiyle gösterilir.
Neden önemli?

Bu etkinliği izlemek, ilk sınıflandırmanın verimliliğini ölçmeye ve gönderim ile atama arasındaki gecikmeleri belirlemeye yardımcı olur. Bu ölçüm, Ortalama İlk Sınıflandırma Süresi KPI’ı için önemlidir.

Nereden alınır?

SRM:Request formundaki durumun In Review veya Planning gibi bir değere değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının In Review olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Talep onay bekliyor
Hizmet talebi, hizmetin yerine getirilmesine başlanmadan önce karar vermesi için belirlenmiş bir onaylayıcıya veya onay grubuna gönderilmiştir. Maliyet ya da erişim hakları içeren taleplerde bu adım sık görülür.
Neden önemli?

Bu etkinlik, onay kaynaklı gecikmeleri ayrı olarak incelemenizi sağlar. Böylece onay çevrim sürelerini analiz edebilir ve onay zincirindeki darboğazları belirleyebilirsiniz.

Nereden alınır?

SRM:Request formundaki durumun Waiting Approval gibi bir değere değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Waiting Approval olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Talep onaylandı
Hizmet talebi, gerekli tarafça resmen onaylanmıştır ve hizmetin yerine getirilmesi süreci devam edebilir. Bu olay genellikle Waiting for Approval durumunu izler.
Neden önemli?

Onay alt sürecinin sonunu gösterir. Onayların ne kadar sürdüğünü ve toplam çözüm süresini nasıl etkilediğini izlemek için önemli bir kilometre taşıdır.

Nereden alınır?

SRM:Request formundaki durumun Waiting Approval değerinden Planning veya In Progress gibi sonraki bir duruma geçmesinden belirlenir. Onay kararı, ilgili onay formlarında kaydedilir.

Kaydedin

Olumlu onay kararının ardından Waiting Approval durumundan çıkıldığı andaki zaman damgası.

Olay türü inferred
Talep reddedildi
Hizmet talebi, onay aşamasında reddedilmiştir. Bu, hizmetin yerine getirilmesi başlamadan süreci durduran bir son durumdur.
Neden önemli?

Reddedilen talepleri analiz etmek, talep gerekçeleri, uygunluk ölçütleri veya onay politikalarıyla ilgili sorunları ortaya çıkarabilir.

Nereden alınır?

SRM:Request formundaki durumun Rejected olarak değişmesinden belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Rejected olarak değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Talep yeniden başlatıldı
Hizmet talebi, genellikle kullanıcı gerekli bilgileri sağladıktan sonra beklemedeki durumdan çıkarılmıştır. Hizmet temsilcisi talep üzerindeki çalışmaya devam eder.
Neden önemli?

Bekleme süresinin sonunu gösterir. Böylece dış kaynaklı bekleme sürelerini ve bunların SLA uyumuna etkisini hassas biçimde ölçebilirsiniz.

Nereden alınır?

SRM:Request durumunun Pending değerinden yeniden In Progress değerine geçmesiyle belirlenir.

Kaydedin

SRM:Request formundaki Status alanının Pending değerinden In Progress değerine değiştiği güncelleme olayının zaman damgası.

Olay türü inferred
Önerilen İsteğe bağlı

Veri çıkarma kılavuzları

BMC Helix ITSM’den verilerinizi nasıl alabilirsiniz?

Başlamaya hazır mısınız?

Veri toplama sürecinizi kolaylaştırmak ve Process Mining çalışmalarınıza güvenle başlamak için bu Templatei kullanın. Hizmet talebi yönetiminizi bugün iyileştirmeye başlayın.

Verimliliği artırın: Hizmet talebi yönetiminizi bugün iyileştirin

%70 otomasyona ulaşın, yavaş talep karşılamayı ortadan kaldırın ve kullanıcı memnuniyetini artırın.

Ücretsiz denemeyi başlatın

Kredi kartı gerekmez. Dakikalar içinde başlayın.