Problem yönetimi Veri Templateiniz
Problem yönetimi Veri Templateiniz
- Kök neden analizi için önerilen öznitelikler
- Temel süreç aşamaları ve etkinlikler
- ServiceNow verilerini çıkarmak için adım adım yönergeler
Problem yönetimi öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
|
Aktivite
Activity
|
Problem kaydı üzerinde gerçekleştirilen belirli olay veya işlem. | ||
|
Açıklama
Problem kaydının yaşam döngüsü boyunca gerçekleşen farklı adımları veya durum değişikliklerini ifade eder. Örnekler arasında 'Problem Kaydı Oluşturuldu', 'Kök Neden Belirlendi' ve 'Destek Grubuna Atandı' yer alır. Bu öznitelik, süreç haritasını oluşturmak ve olayların sırasını görselleştirmek için gereklidir.
Neden önemli?
Süreç haritasındaki düğümleri tanımlar; iş akışını ve süreç varyantlarını görselleştirmenizi sağlar.
Nereden alınır?
'sys_audit' ve 'sys_history_line' tablolarından veya 'problem' tablosundaki durum değişikliklerinden elde edilir
Örnekler
Sorun kaydı oluşturulduAnaliz TamamlandıDurum Kapalı olarak değiştirildi
|
|||
|
Olay zaman damgası
EventTime
|
Bir etkinliğin gerçekleştiği kesin tarih ve saat. | ||
|
Açıklama
Sistemde bir değişikliğin veya işlemin kaydedildiği zaman damgasını tutar. Etkinlikleri kronolojik sıraya koymak ve süreç adımları arasındaki çevrim süresi ile teslim süresi gibi süre metriklerini hesaplamak için temel veridir.
Neden önemli?
Olayları sıralamak ve zamana dayalı tüm KPI’ları hesaplamak için gereklidir.
Nereden alınır?
ServiceNow denetim/geçmiş tablolarındaki 'sys_created_on' alanı
Örnekler
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
Sorun kaydı
ProblemNumber
|
Sorun kaydının benzersiz tanımlayıcısı. | ||
|
Açıklama
ServiceNow içindeki belirli bir problem kaydına atanan benzersiz alfasayısal anahtar (ör. PRB000123). Bu tanımlayıcı, ilk kaydın açılmasından kök neden analizine ve kaydın kapatılmasına kadar tüm süreç etkinliklerini birbirine bağlar. Process Mining analizinde Vaka kimliği olarak kullanılır ve problemin çözüm sürecinin baştan sona yeniden oluşturulmasını sağlar.
Neden önemli?
Benzersiz vakaları ayırt etmek ve ilgili olayları süreç grafiğinde gruplandırmak için kullanılan birincil anahtardır.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'number' alanı
Örnekler
PRB004512PRB009823PRB001122
|
|||
|
Kaynak sistem
SourceSystem
|
Verinin geldiği sistemin adı. | ||
|
Açıklama
Problem yönetimi verilerinin alındığı ServiceNow örneğini veya ortamını belirtir. Veri soyunu izlemek ve analizde sisteme özgü farklılıkları ele almak için özellikle birden fazla sistemin kullanıldığı ortamlarda yararlıdır.
Neden önemli?
Özellikle birden fazla ITSM aracından gelen veriler birleştirildiğinde, verinin kaynağını anlamaya yardımcı olur.
Nereden alınır?
Veri çıkarımı sırasında sabit olarak atanır (ör. 'ServiceNow Production')
Örnekler
ServiceNow ProdServiceNow EMEA
|
|||
|
Son veri güncellemesi
LastDataUpdate
|
Verinin çıkarıldığı veya son kez yenilendiği zaman damgası. | ||
|
Açıklama
Analizde kullanılan veri setinin güncelliğini gösterir. Analistlerin gerçek zamanlı veriye mi yoksa geçmiş bir anın görüntüsüne mi baktığını anlamasına yardımcı olur. Açık vakaların durumunu doğru yorumlamak için bu bilgi önemlidir.
Neden önemli?
Operasyon raporlarının doğru olması için verinin ne kadar güncel olduğunu gösterir.
Nereden alınır?
ETL işleminin yürütüldüğü andaki sistem saati
Örnekler
2023-11-01T12:00:00Z
|
|||
|
Atanan kullanıcı
AssignedTo
|
Problem üzerinde çalışmakla görevlendirilen kişi. | ||
|
Açıklama
Problem kaydından şu anda sorumlu olan kullanıcıyı belirtir. Bu özniteliği analiz ederek iş yükünün dağılımını, bireysel performansı ve kaynak düzeyindeki olası darboğazları anlayabilirsiniz.
Neden önemli?
Kaynak verimliliğini ve kişilerin iş yükünü analiz etmek için temel veridir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'assigned_to' alanı
Örnekler
Alice SmithBob JonesSistem yöneticisi
|
|||
|
Destek grubu
AssignmentGroup
|
Problemin çözümünden sorumlu teknik ekip. | ||
|
Açıklama
Probleme atanmış destek grubunu veya ekibi belirtir. Bu öznitelik, ekipler arasındaki devir teslimleri izlemek ve kurumsal siloları belirlemek için 'Destek grubu yeniden atama analizi' Dashboardında kullanılır.
Neden önemli?
Bölümler arasındaki darboğazları belirlemek ve devir teslim verimliliğini analiz etmek için önemlidir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'assignment_group' alanı
Örnekler
Ağ operasyonlarıVeritabanı yöneticileriHizmet Masası
|
|||
|
İlişkili olay sayısı
RelatedIncidentCount
|
Bu problem kaydıyla bağlantılı olayların sayısı. | ||
|
Açıklama
Problemle ilişkili olayları sayarak problemin etkisini ölçer. Bu alandaki yüksek değerler, özellikle Bilinen Hatalar için, 'Bilinen hata ve olayların tekrarlanması' Dashboardına veri sağlar.
Neden önemli?
Problemin kullanıcılar üzerindeki etkisinin boyutunu ölçer.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'related_incidents' alanı (alan adı değişebilir) veya bağlantılı kayıtların sayısı
Örnekler
1501200
|
|||
|
Kök neden kategorisi
RootCauseCategory
|
Belirlenen kök nedenin sınıflandırması. | ||
|
Açıklama
Problemin altında yatan nedeni Yazılım hatası, İnsan hatası veya Donanım arızası gibi kategorilere ayırır. Bu öznitelik, 'Kök neden sınıflandırma doğruluğu' Dashboardına veri sağlar ve sistem genelindeki arıza örüntülerini belirlemeye yardımcı olur.
Neden önemli?
Stratejik iyileştirmelere yön vermek için arıza örüntülerini analiz etmenizi sağlar.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'rca_category' veya 'u_root_cause_category' alanı
Örnekler
Yazılım hatasıYapılandırma hatasıTedarikçi sorunu
|
|||
|
Öncelik
Priority
|
Problem kaydına atanan öncelik düzeyi. | ||
|
Açıklama
Genellikle etki ve aciliyet temelinde hesaplanan problemin önemini ve ne kadar acil olduğunu gösterir. Bu öznitelik, analizi kritiklik düzeyine göre gruplandırmanızı ve 'SLA ihlali ve öncelik izleme' Dashboardını desteklemenizi sağlar.
Neden önemli?
Süreç performansını iş açısından kritiklik düzeyine göre gruplandırmanızı sağlar.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'priority' alanı
Örnekler
1 - Kritik2 - Yüksek3 - Orta
|
|||
|
Problem durumu
ProblemState
|
Problem kaydının yaşam döngüsündeki durumu. | ||
|
Açıklama
Problem kaydının Açık, Kök neden analizi, Çözüm üzerinde çalışılıyor veya Kapalı gibi mevcut aşamasını gösterir. 'Yaşlanan problem kayıtlarının yaşlandırma analizi' kapsamında birikmiş işlerin dağılımını filtrelemek ve anlamak için temel veridir.
Neden önemli?
Açık ve kapalı vakaları filtrelemek için kullanılan temel durum göstergesidir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'state' alanı
Örnekler
YeniDeğerlendirKök neden analiziÇözüldü
|
|||
|
Yeniden atama sayısı
ReassignmentCount
|
Problemin gruplar arasında kaç kez yeniden atandığı. | ||
|
Açıklama
Atama grubunun ne sıklıkla değiştiğini sayar. 'Problem kaydının yeniden atanma sayısı' KPI’ının doğrudan veri kaynağıdır ve kayıtların ekipler arasında gidip geldiği 'pinpon' durumlarını belirlemeye yardımcı olur.
Neden önemli?
Süreçteki aksaklıkları ve sorumluluğun net olmadığını doğrudan gösterir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'reassignment_count' alanı
Örnekler
0312
|
|||
|
Beklemede geçen süre
PendingDuration
|
Problemin askıya alınmış veya beklemede olduğu toplam süre. | ||
|
Açıklama
'Tedarikçi bekleniyor' veya 'Beklemede' gibi durumlarda geçen süreleri toplar. 'Beklemede durumu ve bekleme süresi analizi' metriği, kurum içi işlem süresini dış kaynaklı gecikmelerden ayırmak için kullanılır.
Neden önemli?
Ekip verimsizliğini dış bağımlılıklardan ayırır.
Nereden alınır?
Hesaplama: Durum = Beklemede/Bekletildi olan aralıkların süreleri toplamı
Örnekler
5 gün0 dakika
|
|||
|
Bilinen hata mı
IsKnownError
|
Problemin Bilinen Hata olarak sınıflandırılıp sınıflandırılmadığını gösteren işaret. | ||
|
Açıklama
Problem kaydının Bilinen Hata’ya dönüştürülüp dönüştürülmediğini veya bu şekilde işaretlenip işaretlenmediğini belirtir. Bilgi yönetimi sürecinin etkili olup olmadığını görmek için 'Bilinen hata ve olayların tekrarlanması' analizinde kullanılır.
Neden önemli?
Devam eden incelemeler ile geçici çözümü bulunan ve kabul edilmiş kusurları birbirinden ayırır.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'known_error' alanı
Örnekler
truefalse
|
|||
|
Çözüm taslağı hazırlama süresi
SolutionDraftingTime
|
Kök nedenin belirlenmesiyle çözüm önerisinin sunulması arasındaki süre. | ||
|
Açıklama
Neden belirlendikten sonra çözümün geliştirildiği tasarım aşamasının süresini izler. 'Çözüm taslağı hazırlama ve düzeltmeyi uygulama' Dashboardını destekler.
Neden önemli?
'Düzeltme tasarımı' aşamasının performansını ayrı olarak ölçer.
Nereden alınır?
Hesaplama: 'Önerilen çözüm taslağı hazırlandı' zaman damgası eksi 'Kök neden belirlendi' zaman damgası
Örnekler
2 gün4 saat
|
|||
|
Değişiklik talebi numarası
ChangeRequestNumber
|
Problemi çözmek için başlatılan değişiklik talebinin tanımlayıcısı. | ||
|
Açıklama
Problem kaydını bir Değişiklik Yönetimi kaydına (RFC) bağlar. 'Değişiklik talebi geçiş verimliliği' Dashboardı, problem teşhisi ile altyapı değişikliğinin uygulanması arasındaki devir teslim hızını ölçmek için bu bağlantıdan yararlanır.
Neden önemli?
Problem yönetiminden değişiklik yönetimine geçişi izler.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'rfc' alanı
Örnekler
CHG003001CHG004552
|
|||
|
Geçici çözüm yayımlandı
WorkaroundPublished
|
Geçici çözümün belgelenip paylaşılmadığını gösterir. | ||
|
Açıklama
Geçici bir çözümün belirlenip Bilgi Bankası’nda veya Bilinen Hatalar Veritabanı’nda yayımlanıp yayımlanmadığını gösteren bir boole değeri veya durum işaretidir. 'Geçici çözüm yayımlama performansı' Dashboardını destekler.
Neden önemli?
Nihai çözüm bulunmadan önce iş üzerindeki etkinin ne kadar hızlı azaltıldığını ölçmek için önemlidir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'work_around' alanı (metin bulunması) veya belirli bir durum
Örnekler
truefalse
|
|||
|
İş hizmeti
BusinessService
|
Problemden etkilenen üst düzey iş hizmeti. | ||
|
Açıklama
Teknik bileşen yerine iş birimlerine sunulan hizmeti (ör. 'Bordro hizmeti', 'Müşteri portalı') ifade eder. Paydaşlara yönelik raporlamada iş odaklı bir görünüm sağlar.
Neden önemli?
Teknik problemleri iş değer akışlarıyla ilişkilendirir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'business_service' alanı
Örnekler
İnternet bankacılığıDahili e-posta
|
|||
|
PIR sonucu
PostImplementationReviewResult
|
Uygulama sonrası incelemenin sonucu veya tamamlanma durumu. | ||
|
Açıklama
PIR sonucunu veya durumunu (ör. Tamamlandı, Gerekli değil, Beklemede) tutar. Önemli problemlerin incelendiğinden emin olmak için 'Uygulama sonrası inceleme uyumluluğu' Dashboardında kullanılır.
Neden önemli?
Önemli olaylardan ders çıkarıldığını izleyen kalite kontrol metriği.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'pir_state' alanı veya benzer bir özel alan
Örnekler
TamamlandıMuaf tutulduBeklemede
|
|||
|
SLA son tarihi
SlaDueDate
|
SLA kapsamında problemin çözülmesi gereken hedef tarih ve saat. | ||
|
Açıklama
Hizmet seviyesi anlaşmalarını karşılamak için problemin çözülmesi gereken zamanı gösteren zaman damgası. 'SLA ihlali ve öncelik izleme' Dashboardının temel verisidir ve uyumluluk oranlarının hesaplanmasında kullanılır.
Neden önemli?
SLA ihlali durumunu hesaplamak için temel alınır.
Nereden alınır?
Problem kaydıyla bağlantılı ServiceNow 'task_sla' tablosu
Örnekler
2023-12-31T17:00:00Z
|
|||
|
Yapılandırma öğesi
ConfigurationItem
|
Problemden etkilenen belirli varlık veya hizmet. | ||
|
Açıklama
Problem kaydıyla bağlantılı Yapılandırma Öğesini (CI) belirtir. Bu veriyi analiz ederek problemleri belirli donanım, yazılım veya hizmetlerle ilişkilendirebilir ve 'Kök neden sınıflandırma doğruluğu' Dashboardını destekleyebilirsiniz.
Neden önemli?
Süreç sorunlarını belirli fiziksel veya mantıksal varlıklarla ilişkilendirir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'cmdb_ci' alanı
Örnekler
SAP ERP Server 01Exchange e-posta hizmetiOracle DB Prod
|
|||
Problem yönetimi etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
|
Değişiklik talebi başlatıldı
|
Bir Değişiklik Talebinin (RFC) Sorun Kaydıyla ilişkilendirilmesidir. Uygulama için Sorun Yönetiminden Değişiklik Yönetimine devir teslimi gösterir. | ||
|
Neden önemli?
Değişiklik Talebi Geçiş Verimliliği Dashboardu için önemlidir. Düzeltmenin bulunmasıyla değişiklik sürecinin başlatılması arasındaki gecikmeleri belirler.
Nereden alınır?
'problem' tablosundaki 'rfc' referans alanının doldurulmasını izleyen ServiceNow 'sys_audit' tablosu.
Kaydedin
Create Normal Change işlemi yürütüldüğünde kaydedilir
Olay türü
explicit
|
|||
|
Destek grubuna atandı
|
Sorun kaydının incelenmek üzere belirli bir teknik ekibe yönlendirilmesidir. Bu etkinlik, sorumluluğun nasıl aktarıldığını izler ve devir teslimleri analiz etmek için önemlidir. | ||
|
Neden önemli?
Ekipler arasındaki gidip gelmeleri ve darboğazları belirlemek için Destek Grubu Yeniden Atama Analizi Dashboardu açısından gereklidir.
Nereden alınır?
'assignment_group' alanındaki değişiklikleri izleyen ServiceNow 'sys_audit' veya 'sys_history_line' tablosu.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Geçici çözüm belirlendi
|
Sorun kaydındaki 'Workaround' alanına metin girilmesidir. Analistin geçici çözümü belgelediği anı kaydeder. | ||
|
Neden önemli?
Teknik çözümün ilk kez ne zaman bilindiğini belirleyerek Geçici Çözüm Yayımlama Performansı Dashboardunu destekler.
Nereden alınır?
'fieldname' değeri 'workaround' olan ServiceNow 'sys_audit' tablosu.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
İnceleme başladı
|
Sorun kaydının durumunun 'New' değerinden 'Assess' veya 'Root Cause Analysis' değerine geçmesidir. Bir analistin sorun üzerinde çalışmaya başladığını gösterir. | ||
|
Neden önemli?
İlk kuyrukta bekleme süresinin sonunu ve etkin inceleme aşamasının başlangıcını gösterir, Beklemedeki Durum analizini destekler.
Nereden alınır?
'state' alanındaki değişiklikleri izleyen ServiceNow 'sys_audit' tablosu (yapılandırmaya bağlı olarak değer 102 veya 103 olabilir).
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Kalıcı düzeltme uygulandı
|
Sorunun Çözüldü olarak işaretlendiği andır. Bu işlem genellikle ilişkili Değişiklik Talebinin kapatılmasıyla tetiklenir ve teknik çalışmanın tamamlandığını gösterir. | ||
|
Neden önemli?
Etkin düzeltme döngüsünün sonunu belirler. SLA’ya göre toplam çözüm süresini hesaplamak için kullanılır.
Nereden alınır?
'Resolved' durumuna geçişi gösteren ServiceNow 'sys_audit' tablosundaki 'state' alanı (genellikle 106 değeri).
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Kök neden belirlendi
|
'Root Cause' kodlarının doldurulduğu veya durumun 'Fix in Progress' değerine geçtiği noktadır. Sorunun başarıyla teşhis edildiğini gösterir. | ||
|
Neden önemli?
Kök Nedene Ulaşma Ortalama Süresini hesaplar ve Kök Neden İnceleme Çevrim Süresi Dashboardunu destekler. Sürecin önemli bir kilometre taşıdır.
Nereden alınır?
'root_cause' kategori alanındaki değişiklikleri veya 'Fix in Progress' durumuna geçişi izleyen ServiceNow 'sys_audit' tablosu.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Sorun kaydı kapatıldı
|
Kaydın etkin olmadığı son yaşam döngüsü olayıdır. Bundan sonra başka bir çalışma beklenmez. | ||
|
Neden önemli?
Süreç örneğinin kesin bitiş noktasıdır. Toplam çevrim süresini hesaplamak için gereklidir.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'closed_at' alanı veya 'Closed' durumuna geçiş.
Kaydedin
Close Problem işlemi yürütüldüğünde kaydedilir
Olay türü
explicit
|
|||
|
Sorun kaydı oluşturuldu
|
ServiceNow sisteminde sorun kaydının ilk kez oluşturulmasıdır. Sorun yönetimi yaşam döngüsünü başlatır ve kayıtların bekleme süresini ölçmek için başlangıç zaman damgasını belirler. | ||
|
Neden önemli?
Tüm çevrim süresi hesaplamaları ve SLA ölçümleri için başlangıç zamanını belirler. Gelen sorun incelemelerinin hacmini saptamak için temel alınır.
Nereden alınır?
ServiceNow 'problem' tablosundaki 'sys_created_on' alanı.
Kaydedin
New Record işlemi yürütüldüğünde kaydedilir
Olay türü
explicit
|
|||
|
Çözüm doğrulandı
|
Çözümün etkili olduğunun doğrulandığı bir kontrol adımıdır. Sürecin olgunluğuna bağlı olarak belirli bir durum veya onay kutusu olabilir. | ||
|
Neden önemli?
Kayıt kapatılmadan önce kalite kontrolü yapılmasını sağlar. Bu adımın atlanması Süreç Sapması analizine olanak tanır.
Nereden alınır?
ServiceNow 'sys_audit' tablosu. Durum değişikliği ('Resolved' -> 'Closed') veya yapılandırılmışsa 'u_resolution_verified' alanı kullanılabilir.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Değerlendirme reddedildi
|
Sorun geçerli bir sorun olmadığı için değerlendirme aşamasında sorun kaydı önceki bir duruma döndürülür veya iptal edilir. | ||
|
Neden önemli?
Olayların yanlışlıkla sorun olarak sınıflandırıldığı süreçteki gereksiz işleri belirler.
Nereden alınır?
'Assess' durumundan 'Closed/Cancelled' veya 'New' durumuna geçişi gösteren ServiceNow 'sys_audit' tablosundaki 'state' alanı.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Durum Fix in Progress olarak değişti
|
Kayıt, düzeltmenin geliştirildiğini veya devreye alındığını gösteren bir duruma geçer. Bu aşamada genellikle Değişiklik Yönetimi beklenir. | ||
|
Neden önemli?
Etkin inceleme süresini 'değişiklik bekleme' süresinden ayırarak darboğaz analizini ayrıntılandırır.
Nereden alınır?
'Fix in Progress' durumuna geçişi gösteren ServiceNow 'sys_audit' tablosundaki 'state' alanı (genellikle 104 değeri).
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Geçici çözüm yayımlandı
|
'Communicate Workaround' işleminin yürütülmesidir. Bu işlem, geçici çözümü ilgili olaylara iletir veya bir Bilinen Hata makalesi oluşturur. Yalnızca geçici çözüm metnini girmekten farklıdır. | ||
|
Neden önemli?
Bilgi paylaşımının hızını ölçmek için önemlidir. Buradaki gecikmeler, tekrarlanan olayların sayısını doğrudan etkiler.
Nereden alınır?
ServiceNow 'sys_journal_field' tablosu veya belirli UI Action günlükleri kullanılabilir. 'Known Error' türünde bir 'kb_knowledge' kaydı oluşturulmuşsa bu da çıkarım için kullanılabilir.
Kaydedin
Communicate Workaround işlemi yürütüldüğünde kaydedilir
Olay türü
explicit
|
|||
|
Önerilen çözümün taslağı hazırlandı
|
'Fix Notes' veya 'Resolution Code' alanlarına veri girilmesidir. Analistin nedeni anlamaktan kalıcı çözümü tasarlamaya geçtiğini gösterir. | ||
|
Neden önemli?
Tasarım aşamasının süresini ayrı olarak ölçerek Çözüm Taslağı ve Düzeltme Uygulama Dashboardunu destekler.
Nereden alınır?
'fix_notes' alanındaki güncellemeleri izleyen ServiceNow 'sys_audit' tablosu.
Kaydedin
Durum alanını önceki ve sonraki değerleriyle karşılaştırın
Olay türü
inferred
|
|||
|
Uygulama sonrası değerlendirme tamamlandı
|
PIR görevinin tamamlanması veya PIR işaretinin ayarlanmasıdır. Önemli sorunlar için geriye dönük analiz yapıldığını doğrular. | ||
|
Neden önemli?
Uygulama Sonrası Değerlendirme Uyumluluğu Dashboardunu doğrudan destekler. Yüksek öncelikli sorunlarda bu etkinliğin bulunmaması, uyumluluk sorunu olduğunu gösterir.
Nereden alınır?
ServiceNow 'problem_task' tablosundaki PIR türündeki kaydın kapatılması veya 'problem' tablosundaki 'pir_state' alanının değiştirilmesi.
Kaydedin
X alanını Y alanıyla karşılaştırarak türetin
Olay türü
inferred
|
|||
Veri çıkarma rehberleri
Başlamaya hazır mısınız?
Tam Templatei indirin ve problem yönetimi verilerinizi bugün uygulanabilir içgörülere dönüştürmeye başlayın. Process Mining yolculuğunuzun her adımında ekibimiz size destek olur.
Daha hızlı çözüm için problem yönetiminizi şimdi iyileştirin
Process Mining ile inceleme döngüsü sürenizi %30 kısaltın
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.