Problem Yönetimi Veri Templateiniz
Problem Yönetimi Veri Templateiniz
- Temel neden analizinde gereken veri alanları
- İzleme için standartlaştırılmış süreç kilometre taşları
- BMC Helix ITSM’ye özel veri çıkarma yönergeleri
Problem Yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
Activity
|
Gerçekleşen belirli görev veya durum değişikliği olayıdır. | ||
|
Açıklama
Bu öznitelik, 'Sorun kaydı oluşturuldu', 'Kök neden belirlendi' veya 'Çözüm veritabanı güncellendi' gibi sorun yönetimi yaşam döngüsünde gerçekleştirilen belirli adımı gösterir. BMC Helix’te bu bilgiler genellikle Status History, Audit Logs veya Problem Investigation modülündeki işlem zaman damgalarından elde edilir. Bu öznitelik, süreç keşfinin temelini oluşturur. Process Mining aracı, etkinliklerin sırasını analiz ederek süreç haritasını oluşturur ve tasarlanan süreçle gerçek iş akışını karşılaştırır. Döngüleri, yeniden çalışmayı ve standart prosedürden sapmaları ortaya çıkarır. Yaşam döngüsü boyunca gerçekte ne olduğunu anlamak için etkinlik adlarının doğru olması önemlidir. Bu veri, kök nedenin belirlenmesiyle değişiklik talebinin başlatılması arasındaki süre gibi belirli adımlar arasındaki geçiş sürelerinin ölçülmesini sağlar.
Neden önemli?
Süreç haritasındaki düğümleri tanımlar ve iş akışının görselleştirilmesini sağlar.
Nereden alınır?
PBM:Problem Investigation durum geçmişinden veya PBM:AuditLogSystem’den elde edilir
Örnekler
Sorun kaydı oluşturulduDestek grubuna atandıİnceleme başladıKök neden belirlendi
|
|||
|
Olay zamanı
EventTime
|
Belirli bir etkinliğin gerçekleştiği zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, bir etkinliğin gerçekleştiği kesin tarih ve saati kaydeder. BMC Helix ITSM’de 'Submit Date', 'Last Modified Date' gibi alanlara veya durum değişikliklerinin geçmiş tablolarında kaydedilen belirli zaman damgalarına karşılık gelir. Analizde bu öznitelik, olayları kronolojik sıraya koymak ve süreleri hesaplamak için kullanılır. 'İnceleme çevrim süresi' veya 'Geçici çözümün yayımlanmasına kadar geçen süre' gibi süreçteki herhangi iki nokta arasındaki çevrim sürelerinin ölçülmesini sağlar. Darboğazları belirlemek için zaman damgalarının doğru olması önemlidir. Analistler, ardışık olaylar arasındaki süre farkını hesaplayarak gecikmelerin tam olarak nerede yaşandığını, ilk atama sırasında mı yoksa son inceleme aşamasında mı olduğunu belirleyebilir.
Neden önemli?
Süreye dayalı tüm KPI’ların hesaplanmasını ve olayların sıralanmasını sağlar.
Nereden alınır?
PBM:Problem Investigation ile ilişkili geçmiş tabloları veya denetim kayıtları
Örnekler
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
Sorun kaydı
ProblemRecord
|
Sorun inceleme vakasının benzersiz tanımlayıcısıdır. | ||
|
Açıklama
Bu öznitelik, sorun yönetimi sürecindeki temel vaka tanımlayıcısıdır. BMC Helix ITSM’de genellikle PBM:Problem Investigation formunda bulunan 'Problem ID' alanıdır (ör. PBI00000012345). Sorunun ilk kaydından son kapatılmasına ve uygulama sonrası incelemeye kadar ilgili tüm etkinlikleri birbirine bağlar. Process Mining analizinde bu öznitelik, tek tek olayları bir süreç örneği altında gruplamak için kullanılır. Analistlerin belirli bir sorun incelemesinin baştan sona nasıl ilerlediğini görmesini sağlar. Bu tanımlayıcı olmadan farklı destek gruplarının ve koordinatörlerin gerçekleştirdiği işlemlerin sırasını ilişkilendirmek mümkün olmaz. Bu alan, Event Log için birincil anahtar işlevi görür. Sorun başına toplam çevrim süresini hesaplamak veya öncelik düzeyine göre sorun sayısını belirlemek gibi tüm vaka düzeyindeki toplulaştırmalar için gereklidir.
Neden önemli?
Süreç görünümünü oluşturmak ve belirli sorunların yaşam döngüsünü izlemek için gereken temel anahtardır.
Nereden alınır?
PBM:Problem Investigation formundaki 'Problem ID' alanı
Örnekler
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin geldiği sistemdir. | ||
|
Açıklama
Bu öznitelik, süreç verisinin çıkarıldığı yazılım sistemini belirtir. Bu örnekte sistem 'BMC Helix ITSM’dir. Process Mining’in çeşitli ITSM, geliştirme veya harici tedarikçi araçlarından veri topladığı çok sistemli ortamlarda özellikle önem taşır. Analizde bu alan, kaydın kaynağını doğrulayan bir üst veri etiketi işlevi görür. Süreç görünümü, sorun yönetimi için BMC Helix’ten ve yazılım geliştirme için ayrı bir sistemden (ör. Jira) veri içeriyorsa bu öznitelik, analizin kaynak sisteme göre ayrılmasına yardımcı olur. Teknik sorunların giderilmesini de kolaylaştırır. Veri kalitesiyle ilgili sorunlar ortaya çıktığında kaynak sistemi bilmek, veri mühendislerinin sorunu ilgili veri çıkarma rutinine veya kaynak veritabanına kadar izlemesini sağlar.
Neden önemli?
Özellikle birden fazla sistemi kapsayan süreç görünümlerinde izlenebilirlik ve bağlam sağlar.
Nereden alınır?
Veri çıkarma işlemi sırasında sabit olarak atanır
Örnekler
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verinin çıkarıldığı veya son kez yenilendiği zaman damgasıdır. | ||
|
Açıklama
Bu öznitelik, verinin Process Mining uygulamasına en son ne zaman yüklendiğini gösterir. Analistlerin görüntüledikleri verinin ne kadar güncel olduğunu bilmesini sağlar. Genellikle veri çıkarma betiği veya veri hattı aracı tarafından oluşturulur. Analizde bu bilgi, güncelliğini yitirmiş verilere dayanarak karar alınmasını önlemeye yardımcı olur. Örneğin bir yönetici 'Açık sorun kayıtları’nı incelerken verinin bir saat önce mi yoksa bir hafta önce mi güncellendiğini bilmek, mevcut iş yükünü nasıl yorumlayacağını önemli ölçüde etkiler. Artımlı veri yüklemelerinde de kullanılır. ETL süreci, son güncelleme zamanını izleyerek önceki veri çıkarma işleminden bu yana değişen kayıtları alabilir. Böylece performans iyileşir ve sistem yükü azalır.
Neden önemli?
Verinin güncel kalmasını sağlar ve artımlı veri yükleme stratejilerine yardımcı olur.
Nereden alınır?
Veri çıkarma anındaki sistem saati
Örnekler
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Destek grubu
SupportGroup
|
Sorun incelemesine o anda atanmış teknik ekiptir. | ||
|
Açıklama
Bu öznitelik, olay sırasında sorun kaydından sorumlu olan belirli destek grubunu (ör. 'Sunucu yönetimi', 'Veritabanı desteği') gösterir. BMC Helix’te bu, 'Assigned Group' alanıdır. Bu öznitelik, 'Destek grubu iş yükü dağılımı' ve 'Destek grubu yeniden atama analizi' Dashboardları için önemlidir. Analistlerin süreç haritasını ekibe göre filtrelemesini, en fazla kayıtla ilgilenen grupları ve inceleme sürecindeki darboğazları görmesini sağlar. Destek grupları arasındaki devir teslimleri analiz etmek, bir kaydın çözülmeden ekipler arasında gidip geldiği durumları belirlemeye yardımcı olur. Bu durum çoğu zaman kuruluş içindeki sorumlulukların net olmadığını veya bilgi yönetiminin yetersiz kaldığını gösterir.
Neden önemli?
Kuruluş genelinde analiz yapılmasını ve ekip düzeyindeki darboğazların belirlenmesini sağlar.
Nereden alınır?
PBM:Problem Investigation formundaki 'Assigned Group' alanı
Örnekler
Hizmet Masası Düzey 1Arka ofis desteğiAğ yönetimi
|
|||
|
Hizmet yapılandırma öğesi
ServiceCI
|
Etkilenen temel iş hizmeti veya yapılandırma öğesidir. | ||
|
Açıklama
Bu öznitelik, sorunla ilişkili hizmet yapılandırma öğesini (CI) belirtir. Örnek olarak 'E-posta hizmeti', 'SAP ERP' veya 'Wi-Fi ağı' verilebilir. BMC Helix’te bu genellikle 'Service+' alanı veya birincil CI ilişkisidir. Analizde bu öznitelik, sorun kayıtlarının ürün veya hizmete göre ayrılmasını sağlar. BT yöneticilerinin hangi hizmetlerin daha kırılgan olduğunu ve en fazla sorun incelemesine yol açtığını anlamasına yardımcı olur. Ürün boyutu ekleyerek 'İşlem hacmi ve öncelik dağılımı' Dashboarduna katkı sağlar. Bu özniteliği 'İnceleme çevrim süresi' ile karşılaştırmak, temel bankacılık sistemi gibi karmaşık hizmetlerin incelenmesinin yazdırma gibi sıradan hizmetlere kıyasla doğal olarak daha uzun sürüp sürmediğini gösterebilir.
Neden önemli?
Süreç performansını belirli iş ürünleri veya hizmetleriyle ilişkilendirir.
Nereden alınır?
PBM:Problem Investigation formundaki 'ServiceCI' veya 'CI Name' alanı
Örnekler
E-posta hizmetiBordro sistemiKurumsal VPN
|
|||
|
İlişkili olay sayısı
RelatedIncidentCount
|
Bu sorun kaydıyla bağlantılı olayların sayısı. | ||
|
Açıklama
Bu öznitelik, sorunla ilişkili olayları sayarak sorunun etkisini ölçer. BMC Helix’te bu sayı genellikle PBM kaydıyla ilişkili HPD:Help Desk formu kayıtlarından elde edilir. Bu öznitelik, 'Olay Bağlantı Yoğunluğu' KPI’ını oluşturur. Sayının yüksek olması, Hizmet Masasında önemli ölçüde iş yükü yaratan ve çok sayıda olaya yol açan bir soruna işaret eder. Bu veriyi 'Priority' ile birlikte değerlendirmek, çok sayıda olaya yol açan sorunların gerçekten kritik olarak ele alınıp alınmadığını gösterir. Ayrıca birikmiş işleri önceliklendirmeye yardımcı olur. Bağlantılı 500 olayı olan bir sorun kaydı, yalnızca 1 bağlantılı olayı olan 'Kritik' bir sorundan muhtemelen önce ele alınmalıdır. İlk sorunun çözülmesi, Hizmet Masasının daha fazla kapasitesini serbest bırakır.
Neden önemli?
Sorunun operasyonel etkisini ve kullanıcıların yaşadığı sıkıntıyı ölçer.
Nereden alınır?
HPD:Associations veya HPD:Help Desk tablolarındaki ilişkili satırlar sayılarak hesaplanır.
Örnekler
15120
|
|||
|
İnceleme nedeni
InvestigationDriver
|
Sorun incelemesinin başlatılma nedenidir. | ||
|
Açıklama
Bu öznitelik, sorun kaydını başlatan nedeni sınıflandırır. Örnekler arasında 'Olay hacmi', 'Büyük olay', 'Tedarikçi bildirimi' ve 'Proaktif eğilim analizi' bulunur. BMC Helix’te bu, 'Investigation Driver' alanıdır. Bu öznitelik, 'Proaktif belirleme eğilimleri' Dashboardunu destekler. Kuruluşun olaylara müdahale ederek sorunları gidermeye çalıştığı reaktif yaklaşımdan, riskleri ortaya çıkmadan belirleyen proaktif sorun yönetimine ne ölçüde geçtiğini ölçmesini sağlar. Süreç akışlarını 'İnceleme nedeni’ne göre analiz etmek, farklı çalışma biçimlerini ortaya çıkarabilir. Örneğin, 'Proaktif' sorunlar anlık kesintilere yol açmadıkları için kuyrukta daha uzun süre bekleyebilirken 'Büyük olay' kaynaklı sorunlar süreçte daha hızlı ilerletilebilir.
Neden önemli?
Reaktif ve proaktif çalışmaları birbirinden ayırır; bu, süreç olgunluğunun önemli bir göstergesidir.
Nereden alınır?
PBM:Problem Investigation formundaki 'Investigation Driver' alanı
Örnekler
ReaktifProaktifTekrarlanan olaylar
|
|||
|
Kök neden kategorisi
RootCauseCategory
|
Sorunun altında yatan nedenin sınıflandırmasıdır. | ||
|
Açıklama
Bu öznitelik, kök neden belirlendiğinde seçilen kategoriyi içerir (ör. 'Yazılım hatası', 'Donanım arızası', 'Süreç açığı'). BMC Helix’te bu kategori genellikle 'Root Cause' veya 'Generic Categorization' menülerinden seçilir. Bu öznitelik, 'Çözüm etkinliği ve kalitesi' görünümü için gereklidir. Kuruluşun belirli kök neden türlerini yeniden çalışma oranlarıyla veya uzun inceleme süreleriyle ilişkilendirmesini sağlar. Örneğin, 'Yazılım hatası' kaynaklı sorunların çözümünün sürekli olarak 'Donanım arızası' kaynaklı sorunların çözümünden iki kat uzun sürdüğünü ortaya çıkarabilir. Ayrıca 'Kök neden sınıflandırma oranı’nı hesaplamak için kullanılır. Bu alandaki 'Bilinmiyor' veya 'Diğer' değerlerinin yüksek oranda olması, daha iyi teknik eğitim ya da daha ayrıntılı sınıflandırma seçenekleri gerektiğini gösterir.
Neden önemli?
Sistemik sorunlardaki eğilimlerin analiz edilmesini sağlar ve proaktif sorun yönetimini destekler.
Nereden alınır?
PBM:Problem Investigation formundaki 'Root Cause' alanı veya sınıflandırma sekmesindeki alanlar
Örnekler
Yazılım modülüAğ altyapısıİnsan hatası
|
|||
|
Öncelik
Priority
|
Sorunun etkisine ve aciliyetine göre hesaplanan önceliğidir. | ||
|
Açıklama
Bu öznitelik, sorun kaydının öncelik düzeyini (ör. Kritik, Yüksek, Orta, Düşük) gösterir. BMC Helix’te bu değer genellikle Etki ve Aciliyet seçimlerinden hesaplanır. Analizde bu öznitelik, 'İşlem hacmi ve öncelik dağılımı' Dashboardu için kullanılır. Kuruluşların kaynaklarını iş ihtiyaçlarıyla doğru biçimde eşleştirip eşleştirmediğini kontrol etmelerini sağlar. Örneğin, 'Kritik' öncelikli sorunların ilk atama süresinin daha kısa ve toplam çevrim süresinin 'Düşük' öncelikli sorunlara kıyasla daha az olması beklenir. Önceliğe göre filtreleme, iyileştirme çalışmalarına odaklanmaya yardımcı olur. 'Düşük' öncelikli bir süreçteki darboğaz kabul edilebilir olabilir; ancak 'Kritik' öncelikli bir süreçteki aynı gecikme, iş sürekliliği ve SLA uyumluluğu açısından önemli bir risk oluşturur.
Neden önemli?
Analizi iş açısından önem düzeyine göre ayırır ve SLA analizini destekler.
Nereden alınır?
PBM:Problem Investigation formundaki 'Priority' alanı
Örnekler
KritikYüksekOrtaDüşük
|
|||
|
Problem koordinatörü
ProblemCoordinator
|
İncelemeyi koordine etmek üzere atanmış kişidir. | ||
|
Açıklama
Bu öznitelik, sorun kaydından sorumlu kişiyi belirtir. BMC Helix ITSM’de bu, 'Problem Coordinator' alanıdır. Görevler başkalarına devredilse bile sorun kaydının yaşam döngüsünden bu kişi sorumludur. Bu öznitelik, 'Destek grubu iş yükü dağılımı' Dashboardunu destekler. Yöneticilerin bazı kişilerin incelemelerle aşırı yüklenip yüklenmediğini, diğerlerinin ise kapasitesi olup olmadığını görmesine yardımcı olur. Ayrıca kişi düzeyinde performans analizine imkân vererek eğitim ihtiyaçlarının veya yüksek performans gösteren çalışanların belirlenmesini sağlar. Process Mining’de bu alan, kaynak özniteliği olarak kullanılır. İşin kişiler arasında nasıl ilerlediğini görselleştirir ve sürecin tek bir uzmana aşırı bağımlı olduğu, aksama riski taşıyan noktaları ortaya çıkarabilir.
Neden önemli?
Kaynak analizini ve kişi düzeyinde iş yükü dengelemesini sağlar.
Nereden alınır?
PBM:Problem Investigation formundaki 'Problem Coordinator' alanı
Örnekler
John DoeJane SmithSistem yöneticisi
|
|||
|
SLA ihlali var mı
IsSLABreached
|
Sorunun çözümünün izin verilen süreyi aşıp aşmadığını belirten işaret. | ||
|
Açıklama
Bu doğru/yanlış özniteliği, sorun kaydında hizmet seviyesi anlaşmasının ihlal edilip edilmediğini belirtir. 'Resolution Verified' zaman damgası 'SLA Due Date' ile karşılaştırılarak hesaplanır veya doğrudan SLM durumundan alınır. Bu öznitelik, 'SLA Uyumluluğu ve İhlal Eğilimleri' Dashboardu için önemlidir. Sürecin uyumlu ve uyumsuz olarak iki gruba ayrılmasını sağlar. Böylece başarısız süreçlerin ortak özellikleri kolayca belirlenebilir (ör. 'SLA ihlali olan vakalarda her zaman X Destek Grubu mu yer alıyor?'). Süreç başarısızlıklarının kök neden analizinde temel filtrelerden biri olarak kullanılır. Analistler 'IsSLABreached = True' filtresini uygulayıp süreç haritasını inceleyerek zamanın nerede kaybedildiğini görebilir (ör. tedarikçi onayı için uzun bekleme süreleri).
Neden önemli?
Uyumluluk raporlamasını ve başarısızlık analizini kolaylaştırır.
Nereden alınır?
SLM:Measurement formundan alınır veya hesaplanır.
Örnekler
truefalse
|
|||
|
SLA son tarihi
SLADueDate
|
Sorunun çözülmesi gereken hedef tarih ve saat. | ||
|
Açıklama
Bu öznitelik, hizmet seviyesi anlaşmasına göre sorunun çözülmesi için belirlenen son tarihi içerir. BMC Helix’te bu bilgi genellikle 'Target Resolution Date' alanında veya hesaplanan bir SLA kilometre taşı zaman damgasında bulunur. Bu öznitelik, 'SLA Uyumluluğu ve İhlal Eğilimleri' Dashboardunun temelini oluşturur. Sistem, bu zaman damgasını 'Resolution Verified' etkinliğinin zaman damgasıyla karşılaştırarak SLA hedefinin karşılanıp karşılanmadığını hesaplar. Bu tarihi görselleştirmek, ekibin son tarihe ne kadar yaklaştığını gösterir. Sorunları günler öncesinden mi çözüyorlar, yoksa ihlalden yalnızca birkaç dakika önce mi tamamlıyorlar? Bu bilgi kapasite planlamasına yön verir.
Neden önemli?
Uyumluluk ve zamanında tamamlama metriklerinin hesaplanmasında referans noktasıdır.
Nereden alınır?
PBM:Problem Investigation formundaki 'Target Resolution Date' alanı
Örnekler
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Bölge
Region
|
Sorunla ilişkili coğrafi bölge. | ||
|
Açıklama
Bu öznitelik, sorunun ortaya çıktığı veya yönetildiği coğrafi konumu (ör. 'Kuzey Amerika', 'EMEA') belirtir. BMC Helix’te bu bilgi genellikle talep sahibiyle veya etkilenen varlıkla ilişkili 'Region' ya da 'Site' alanlarında bulunur. Analiz sırasında coğrafi segmentasyon yapılmasını sağlar. Belirli bölgelerde sorun sayısının daha yüksek veya çözüm sürelerinin daha uzun olup olmadığını belirlemeye yardımcı olur. Böylece farklı konumlardaki destek personeli sayısı veya altyapı kalitesi arasındaki farklar ortaya çıkarılabilir. Hizmet sunumunun tutarlı olmasını sağlamak isteyen küresel kuruluşlar için yararlıdır. 'APAC' bölgesindeki 'Investigation Cycle Time', 'NAM' bölgesindekinin iki katıysa kaynak dağılımı veya süreçlere uyum bu bölgede incelenmelidir.
Neden önemli?
Süreç performansının coğrafi bölgelere göre karşılaştırılmasını sağlar.
Nereden alınır?
PBM:Problem Investigation formundaki 'Region' alanı
Örnekler
Amerika kıtasıEMEAAPAC
|
|||
|
Geçici çözüm durumu
WorkaroundStatus
|
Geçerli bir geçici çözüm bulunup yayımlandığını belirtir. | ||
|
Açıklama
Bu öznitelik, geçici çözümün (Workaround) durumunu izler. Basit bir doğru/yanlış değeri ('Has Workaround') veya durum metni olabilir. BMC Helix’te bu bilgi genellikle 'Workaround' alanında metin bulunup bulunmadığına ya da belirli bir durum işaretine göre belirlenir. Bu öznitelik, 'Geçici Çözüm Yayınlama Performansı' Dashboardu için önemlidir. Kök neden araştırılırken ekibin etkinin azaltılmasını ne ölçüde sağladığını gösterir. 'No Workaround' filtresi uygulanan süreç görünümü, inceleme sürerken iş biriminin sorunun tüm etkilerine maruz kaldığı vakaları öne çıkarır. Kalite denetimlerini de destekler. Kalıcı bir çözüm (Değişiklik Talebi) OLMADAN ve geçici çözüm de sunulmadan kapatılan sorun kayıtları genellikle incelenmesi gereken bir süreç aksaklığına işaret eder.
Neden önemli?
İnceleme sırasında etkinin azaltılmasındaki başarıyı ölçer.
Nereden alınır?
PBM:Problem Investigation formundaki 'Workaround' alanının dolu olup olmadığının kontrolü
Örnekler
EtkinYokEmekli
|
|||
|
İlişkili değişiklik talebi kimliği
RelatedChangeRequestId
|
Sorunu gidermek için başlatılan değişiklik talebinin kimliği. | ||
|
Açıklama
Bu öznitelik, sorun kaydıyla bağlantılı Değişiklik Talebinin kimliğini (ör. CRQ0000...) içerir. İnceleme aşamasından kalıcı çözümün uygulanmasına geçişi gösterir. Bu öznitelik, 'Kök Neden ile Değişiklik Arasındaki Süre' KPI’ı için gereklidir. Process Mining aracı, kök nedenin bulunmasıyla değişiklik sürecinin başlatılması arasındaki gecikmeyi ölçebilir. Bu devir teslim noktasında süreç sık sık yavaşlar. Ayrıca 'sürecin eksiksizliğini' doğrulamaya yardımcı olur. 'Completed' durumuyla kapatılan bir sorun kaydında ilişkili bir değişiklik talebi (veya geçici çözüm) yoksa kök neden bulunmuş ancak sorun hiç giderilmemiş olabilir. Bu da süreç ihlaline işaret edebilir.
Neden önemli?
Sorun yönetimi sürecini değişiklik yönetimi sürecine bağlar.
Nereden alınır?
PBM:Investigation Associations veya Relationship sekmesi
Örnekler
CRQ00000021345CRQ00000021346
|
|||
|
İnceleme çevrim süresi
InvestigationCycleTime
|
İncelemenin başlamasından kök nedenin belirlenmesine kadar geçen süre. | ||
|
Açıklama
Bu hesaplanan süre özniteliği, 'Investigation Commenced' etkinliği ile 'Root Cause Identified' etkinliği arasındaki zamanı ölçer. Sorun yönetimi sürecinde doğrudan değer yaratan temel süreyi gösterir. Bu metrik, 'Kök Neden İnceleme Çevrim Süresi' Dashboarduna veri sağlar. Yöneticilerin sorunların teknik karmaşıklığını ve inceleme ekiplerinin verimliliğini anlamasına yardımcı olur. Olağan dışı değerler (ör. çok kısa süreler) tahmine dayalı incelemelere, çok uzun süreler ise durmuş incelemelere işaret edebilir. Kuruluş, bu metriği 'Support Groups' ve 'Priorities' bazında karşılaştırarak sorunları daha hızlı teşhis etmek için hangi ekiplere daha iyi araçlar, eğitim veya tedarikçi desteği gerektiğini belirleyebilir.
Neden önemli?
Teknik inceleme aşamasının temel verimlilik metriğidir.
Nereden alınır?
Etkinlik zaman damgalarından hesaplanır.
Örnekler
4500000120000
|
|||
|
Yeniden atama sayısı
ReassignmentCount
|
Destek grubunun kaç kez değiştirildiği. | ||
|
Açıklama
Bu öznitelik, tek bir vaka için 'Assigned to Support Group' etkinliğinin kaç kez gerçekleştiğini sayar. Süreçteki sürtüşmeyi ve yönlendirme verimliliğini doğrudan ölçer. Bu öznitelik, 'Destek Grubuna Yeniden Atama Analizi' grafiğine veri sağlar. Yüksek değerler (gruplar arasında gidip gelme), ilk sınıflandırmanın yetersiz kaldığını veya karmaşık sorunların sorumluluğunun net olmadığını gösterir. Ayrıca çevrim süresinin uzayabileceğine dair erken bir işarettir. Yöneticiler bu veriyi eğitim fırsatlarını belirlemek için kullanır. Hizmet Masası 'Database' sorunlarını sürekli önce 'Network' ekibine atıyor ve 'Network' de bunları tekrar 'Database' ekibine gönderiyorsa yeniden atama sayısı yükselir. Bu durum, ilk teşhis için daha iyi yönergeler gerektiğini gösterir.
Neden önemli?
Süreçteki israfı, sürtüşmeyi ve sorumluluk eksikliğini ortaya çıkarır.
Nereden alınır?
Etkinlik geçmişinden hesaplanır.
Örnekler
015
|
|||
Problem Yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Çözüm doğrulandı
|
Kalıcı çözümün başarılı olduğunun doğrulandığı andır. Status alanının 'Solution Implemented' veya 'Completed' olarak değişmesinden çıkarımla belirlenir. | ||
|
Neden önemli?
'Sorun SLA hedeflerine uyum oranı' için kullanılır. Teknik çalışmanın tamamlandığını doğrular.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Solution Implemented' veya 'Completed'.
Kaydedin
Solution Implemented durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Değişiklik talebi başlatıldı
|
Infrastructure Change Request kaydının Problem Investigation kaydıyla ilişkilendirilmesidir. Uygulama aşamasının başladığını gösterir. | ||
|
Neden önemli?
'Kök nedenden değişiklik talebine kadar geçen süre' KPI’ı ve Problem Management ile Change Management süreçleri arasındaki kopuklukları belirlemek için gereklidir.
Nereden alınır?
PBM:Investigation_Associations tablosu veya 'Infrastructure Change ID' alanının doldurulması.
Kaydedin
PBM:Investigation_Associations tablosunda ilişki oluşturulduğunda kaydedilir
Olay türü
explicit
|
|||
|
Destek grubuna atandı
|
Sorun kaydının belirli bir teknik ekibe atanmasıdır. 'Assigned Group' alanındaki değişiklikler izlenerek kaydedilir. | ||
|
Neden önemli?
Devir teslimleri, kayıtların ekipler arasında gidip gelmesini ve 'İlk atamaya kadar geçen ortalama süre' KPI’ını ölçmek için gereklidir.
Nereden alınır?
PBM:Problem Investigation formundaki 'Assigned Group' alanının geçmişi veya denetim kaydı.
Kaydedin
Güncelleme öncesi ve sonrası 'Assigned Group' alanını karşılaştırın
Olay türü
inferred
|
|||
|
Geçici çözüm tanımlandı
|
Sorun kaydındaki Workaround alanına metin girilmesi veya bu metnin güncellenmesidir. Bu olay, geçici bir çözümün belgelendiğini gösterir. | ||
|
Neden önemli?
'Geçici çözümün yayımlanmasına kadar geçen süre' KPI’ını destekler ve olayın etkisini azaltmaya yönelik çalışmaları gösterir.
Nereden alınır?
PBM:Problem Investigation formundaki 'Workaround' metin alanında yapılan değişiklikler.
Kaydedin
Boş olmayan güncellemeleri bulmak için 'Workaround' alanının içeriğini karşılaştırın
Olay türü
inferred
|
|||
|
İnceleme başladı
|
Sorun kaydının etkin analiz aşamasına geçmesidir. Status alanı 'Under Investigation' olarak değiştiğinde bu geçiş çıkarımla belirlenir. | ||
|
Neden önemli?
Gerçek çalışma aşamasının başlangıcını belirtir ve 'İnceleme çevrim süresi' KPI’ının hesaplanmasını sağlar.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Under Investigation'.
Kaydedin
Under Investigation durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Kök neden belirlendi
|
Sorun kaydının, nedenin bilindiğini gösteren bir duruma geçtiği andır. Status alanı 'Root Cause Identified' olarak değiştiğinde bu geçiş çıkarımla belirlenir. | ||
|
Neden önemli?
'Kök neden inceleme çevrim süresi' Dashboardu için önemli bir kilometre taşıdır. Analizden çözüm geliştirme aşamasına geçildiğini gösterir.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Root Cause Identified'.
Kaydedin
Root Cause Identified durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Sorun kaydı iptal edildi
|
Sorun kaydının çözülmeden sonlandırılmasıdır. Status alanı 'Cancelled' veya 'Rejected' olduğunda kaydedilir. | ||
|
Neden önemli?
Boşa harcanan çabayı veya geçerli mükerrer kayıtları belirleyin. Alternatif bir bitiş noktasını gösterir.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Cancelled' veya 'Rejected'.
Kaydedin
Cancelled durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Sorun kaydı kapatıldı
|
Sorun kaydının idari olarak son kez kapatılmasıdır. Bu olay süreç örneğini sonlandırır. | ||
|
Neden önemli?
Standart Son Olay’dır. Çevrim süresinin tamamını analiz etmek ve 'Olay bağlantı yoğunluğu' hesaplamasını yapmak için gereklidir.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Closed'.
Kaydedin
Closed durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Sorun kaydı oluşturuldu
|
Sistemde Problem Investigation kaydının ilk kez oluşturulmasıdır. PBM:Problem Investigation formuna yeni bir kayıt kaydedildiğinde bu olay açıkça kaydedilir. | ||
|
Neden önemli?
Süreç örneğinin başlangıcını belirtir. Toplam çevrim sürelerini ve ilk yanıt metriklerini hesaplamak için gereklidir.
Nereden alınır?
PBM:Problem Investigation formundaki 'Submit Date' zaman damgası veya 'Status' = 'Draft' oluşturma kaydı.
Kaydedin
PBM:Problem Investigation kaydı oluşturulduğunda kaydedilir
Olay türü
explicit
|
|||
|
Bilinen hata kaydı oluşturuldu
|
Sorun incelemesiyle bağlantılı bir Known Error kaydı oluşturulmasıdır. Bu, ilişkili bir kayıt oluşturma olayıdır. | ||
|
Neden önemli?
Sorunun daha geniş kapsamda paylaşılmak ve uzun vadede izlenmek üzere resmîleştirildiğini gösterir.
Nereden alınır?
PBM:Problem Investigation ID ile bağlantılı PBM:Known Error kaydının oluşturulması.
Kaydedin
PBM:Known Error kaydı oluşturulduğunda kaydedilir
Olay türü
explicit
|
|||
|
Çözüm veritabanı güncellendi
|
Kalıcı bir çözümün önerildiğini veya belirlendiğini gösteren 'Solution Database' durumuna geçiştir. | ||
|
Neden önemli?
Uygulamaya geçilmeden önce çözümün tanımlanma sürecindeki ilerlemeyi izler.
Nereden alınır?
PBM:Problem Investigation formunda 'Status' alanı = 'Solution Database'.
Kaydedin
Solution Database durumuna geçişi görmek için Status alanını karşılaştırın
Olay türü
inferred
|
|||
|
Koordinatör yeniden atandı
|
Bir destek grubundaki Problem Coordinator’ın değişmesidir. 'Problem Coordinator' alanı izlenerek kaydedilir. | ||
|
Neden önemli?
İş yükü dağılımını ve kişilere bağlı kaynak darboğazlarını analiz etmeye yardımcı olur.
Nereden alınır?
PBM:Problem Investigation formundaki 'Problem Coordinator' alanının geçmişi.
Kaydedin
Güncelleme öncesi ve sonrası 'Problem Coordinator' alanını karşılaştırın
Olay türü
inferred
|
|||
|
Uygulama sonrası inceleme yapıldı
|
PIR aşamasının tamamlanmasıdır. PIR durumundan çıkış veya bağlantılı bir PIR Task’ın kapatılmasıyla kaydedilir. | ||
|
Neden önemli?
'Uygulama sonrası inceleme uyumluluğu' ve süreç kalitesi denetimlerini doğrudan destekler.
Nereden alınır?
PBM:Problem Investigation formundaki 'PIR Required' işareti veya bağlantılı 'PIR' türündeki Task’ın tamamlanması.
Kaydedin
PIR durumunun tamamlanmasından veya PIR Task’ın kapatılmasından çıkarılır
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Bu Templatei bugün BMC Helix ITSM verilerinize uygulayarak hizmetlerinizin istikrarını artırın. Kurulumla ilgili sorularınız varsa ekibimiz size yardımcı olabilir.
Problem Yönetimi darboğazlarını bugün giderin
Çevrim sürelerini %30 kısaltın ve hizmet istikrarını artırın.
Kredi kartı gerekmez. Kurulum dakikalar içinde tamamlanır.