Templat data pengelolaan masalah Anda
Templat data pengelolaan masalah Anda
- Atribut yang disarankan untuk analisis mendalam
- Tahapan proses yang perlu dicatat dalam event log
- Panduan teknis untuk ekstraksi data
Atribut pengelolaan masalah
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Tindakan atau perubahan status tertentu yang terjadi pada catatan masalah. | ||
|
Deskripsi
Atribut ini mencatat nama peristiwa atau transisi status dalam siklus manajemen masalah. Contohnya, 'Masalah Dicatat', 'Status Berubah menjadi Dalam Investigasi', atau 'Akar Penyebab Ditemukan'. Atribut ini penting untuk memetakan alur proses dan mengenali urutan langkah penyelesaian masalah. Dalam process mining, aktivitas ini menjadi simpul pada peta proses.
Mengapa ini penting
Menentukan langkah-langkah dalam peta proses dan memungkinkan analisis variasi proses.
Sumber data
Jira Changelog (History) atau transisi Status Issue
Contoh
Catatan masalah dibuatInvestigasi dimulaiAkar penyebab ditemukanSolusi sementara diperbaruiCatatan masalah ditutup
|
|||
|
Catatan masalah
ProblemKey
|
Pengenal unik yang diberikan kepada catatan masalah di Jira Service Management. | ||
|
Deskripsi
Atribut ini menjadi ID kasus utama untuk analisis process mining. Nilainya adalah kunci unik, misalnya PM-1001, yang dibuat Jira Service Management saat catatan masalah baru dibuat. Atribut ini digunakan untuk mengelompokkan semua aktivitas, perubahan status, dan pembaruan terkait ke dalam satu proses dari awal hingga akhir. Dengan menganalisisnya, Anda dapat melihat seluruh siklus hidup masalah, mulai dari deteksi awal, investigasi, hingga penutupan.
Mengapa ini penting
Kunci utama ini diperlukan untuk merekonstruksi alur proses dan melacak catatan masalah tertentu.
Sumber data
Tabel Issue, kolom 'Key' atau 'Issue Key'
Contoh
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Waktu data diekstrak atau terakhir diperbarui. | ||
|
Deskripsi
Menunjukkan kapan dataset terakhir disinkronkan dengan lingkungan Jira Service Management yang aktif. Dengan begitu, analis dapat mengetahui seberapa baru data tersebut. Informasi ini digunakan untuk memastikan analisis mencerminkan kondisi proses terkini dan mengidentifikasi kemungkinan keterlambatan data.
Mengapa ini penting
Memastikan data tetap baru dan membantu Anda memercayai hasil analisis.
Sumber data
Waktu ETL
Contoh
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Nama sistem asal data. | ||
|
Deskripsi
Menunjukkan sistem perangkat lunak tempat data proses diambil. Dalam konteks ini, nilainya selalu 'Jira Service Management'. Atribut ini berguna terutama di lingkungan dengan banyak sistem untuk membedakan sumber data. Namun, pada tampilan ini, fungsinya terutama sebagai penanda tetap asal-usul data.
Mengapa ini penting
Memberi konteks tentang asal data, terutama saat digabungkan dengan data IT Service Management lainnya.
Sumber data
Diisi secara tetap atau melalui konfigurasi sistem
Contoh
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
Stempel waktu
EventTimestamp
|
Tanggal dan waktu persis saat aktivitas terjadi. | ||
|
Deskripsi
Atribut ini mencatat waktu persis terjadinya aktivitas. Data ini digunakan untuk mengurutkan peristiwa secara kronologis dan menghitung durasi antar langkah. Stempel waktu yang akurat penting untuk menghitung waktu siklus, misalnya waktu dari 'Masalah Dicatat' hingga 'Akar Penyebab Ditemukan', serta menganalisis jumlah kasus yang ditangani dari waktu ke waktu.
Mengapa ini penting
Memungkinkan penghitungan semua KPI berbasis waktu dan pengurutan peristiwa dengan benar.
Sumber data
Tanggal pembuatan Jira Changelog atau tanggal pembuatan Issue
Contoh
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
Grup dukungan yang ditugaskan
SupportGroup
|
Tim atau grup teknis yang saat ini ditugaskan untuk menyelidiki masalah. | ||
|
Deskripsi
Menunjukkan tim yang bertanggung jawab atas catatan masalah saat suatu peristiwa terjadi. Di Jira Service Management, atribut ini biasanya dipetakan ke 'Component' atau kolom khusus seperti 'Support Group'. Atribut ini penting untuk dashboard 'Hambatan serah terima grup dukungan'. Analis dapat melihat perpindahan masalah antar tim dan mengetahui di tim mana masalah paling lama tertahan.
Mengapa ini penting
Penting untuk analisis proses lintas tim dan menemukan kendala antar tim.
Sumber data
Kolom issue 'Component' atau kolom khusus 'Support Group'
Contoh
Administrasi basis dataOperasional jaringanDukungan aplikasi tingkat 2
|
|||
|
Kategori akar penyebab
RootCauseCategory
|
Klasifikasi penyebab utama masalah. | ||
|
Deskripsi
Mengelompokkan kegagalan teknis atau proses yang menyebabkan masalah, seperti 'Bug perangkat lunak', 'Kesalahan manusia', atau 'Kerusakan perangkat keras'. Atribut ini biasanya berupa kolom khusus di Jira Service Management. Atribut ini mendukung dashboard 'Distribusi kategori akar penyebab' dan membantu menentukan investasi infrastruktur atau pelatihan yang dapat mencegah masalah berulang.
Mengapa ini penting
Penting untuk menemukan masalah sistemik dan menentukan langkah pencegahan.
Sumber data
Kolom khusus 'Root Cause' atau 'Root Cause Category'
Contoh
Bug perangkat lunakKesalahan konfigurasiMasalah kapasitasMasalah pemasok
|
|||
|
Pengguna
UserKey
|
ID unik atau nama pengguna yang melakukan aktivitas. | ||
|
Deskripsi
Mencatat identitas orang atau akun sistem yang bertanggung jawab menjalankan aktivitas tertentu. Misalnya, 'Assignee' yang memperbarui catatan atau 'Author' yang mengubah status. Data ini digunakan untuk menganalisis pemanfaatan sumber daya, menemukan hambatan saat pekerjaan berpindah antar pengguna, dan memastikan akuntabilitas dalam proses manajemen masalah.
Mengapa ini penting
Penting untuk menganalisis serah terima, pemisahan tugas, dan beban kerja sumber daya.
Sumber data
Kolom Jira 'author' di changelog atau kolom 'assignee' pada issue
Contoh
j.smithsystem_automationm.doe
|
|||
|
Prioritas
Priority
|
Tingkat kekritisan yang ditetapkan pada catatan masalah. | ||
|
Deskripsi
Menunjukkan tingkat urgensi dan dampak masalah, biasanya dari 'Rendah' hingga 'Kritis'. Kolom ini digunakan untuk mengelompokkan analisis dan memastikan masalah berprioritas tinggi diselesaikan sesuai target SLA. Analisis atribut ini membantu dashboard 'Kepatuhan SLA dan tren target' memastikan risiko bisnis kritis mendapat prioritas yang tepat.
Mengapa ini penting
Memungkinkan kinerja proses dikelompokkan berdasarkan tingkat kekritisan bisnis.
Sumber data
Kolom issue 'Priority'
Contoh
TertinggiTinggiSedangRendah
|
|||
|
Ringkasan masalah
ProblemSummary
|
Deskripsi singkat atau judul catatan masalah. | ||
|
Deskripsi
Berisi ringkasan utama catatan masalah. Meski berupa teks, informasi ini memberi konteks bagi analis yang meninjau kasus tertentu di alat process mining. Ringkasan ini juga memungkinkan pencarian kata kunci dan analisis kualitatif atas jenis masalah yang dicatat.
Mengapa ini penting
Memberi konteks yang mudah dipahami untuk ID kasus.
Sumber data
Kolom issue 'Summary'
Contoh
Waktu koneksi basis data habis di wilayah EULonjakan latensi layanan emailAntrean pemrosesan pesanan macet
|
|||
|
Dibuka kembali
IsReopened
|
Penanda yang menunjukkan apakah masalah dibuka kembali setelah ditutup. | ||
|
Deskripsi
Penanda boolean bernilai true jika status catatan masalah berubah dari tertutup menjadi terbuka. Informasi ini mendukung 'Analisis tingkat masalah yang dibuka kembali'. Tingkat pembukaan kembali yang tinggi dapat menunjukkan masalah pada kualitas perbaikan permanen atau prosedur verifikasi yang belum memadai.
Mengapa ini penting
Indikator kualitas untuk menilai efektivitas perbaikan.
Sumber data
Ditentukan dari perubahan status
Contoh
truefalse
|
|||
|
Jumlah insiden tertaut
LinkedIncidentCount
|
Jumlah insiden yang ditautkan ke catatan masalah ini. | ||
|
Deskripsi
Jumlah tiket insiden yang terkait dengan catatan masalah. Atribut ini mengukur dampak masalah terhadap pengguna. Atribut ini digunakan dalam KPI 'Kedalaman tautan insiden ke masalah' untuk memprioritaskan masalah yang menghasilkan tiket dukungan terbanyak.
Mengapa ini penting
Mengukur dampak bisnis berdasarkan jumlah insiden.
Sumber data
Jumlah tautan di tabel 'issuelinks' dengan jenis 'Problem/Incident'
Contoh
011550
|
|||
|
Kode penyelesaian
ResolutionCode
|
Kode yang menunjukkan cara masalah diselesaikan. | ||
|
Deskripsi
Menentukan hasil akhir catatan masalah, seperti 'Diperbaiki', 'Tidak akan diperbaiki', 'Duplikat', atau 'Tidak dapat direproduksi'. Kode ini digunakan untuk memisahkan masalah yang berhasil diselesaikan dari kasus yang ditutup karena alasan administratif. Dengan begitu, perhitungan KPI seperti 'Rata-rata waktu menemukan akar penyebab' tetap akurat.
Mengapa ini penting
Membedakan perbaikan yang efektif dari penutupan administratif.
Sumber data
Kolom issue 'Resolution'
Contoh
SelesaiTidak akan ditindaklanjutiDuplikatTidak dapat direproduksi
|
|||
|
Pelapor
ReporterName
|
Pengguna yang pertama kali mencatat masalah. | ||
|
Deskripsi
Menunjukkan orang yang membuat catatan masalah. Berbeda dari pengguna yang ditugaskan menangani masalah. Analisis pelapor membantu mengetahui dari mana masalah terdeteksi, misalnya oleh agen service desk atau administrator sistem. Informasi ini memberi konteks tambahan untuk analisis 'Proaktif vs. reaktif'.
Mengapa ini penting
Menunjukkan sumber masuknya laporan masalah.
Sumber data
Kolom issue 'Reporter'
Contoh
layanan_pemantauanketua_helpdeskadmin_jaringan
|
|||
|
Permintaan perubahan tertaut
LinkedChangeRequest
|
ID permintaan perubahan yang ditautkan ke masalah ini. | ||
|
Deskripsi
Menyimpan ID Change Request (RFC) yang dibuat untuk menerapkan perbaikan permanen. Tautan ini penting untuk dashboard 'Jeda inisiasi permintaan perubahan'. Tautan ini menghubungkan proses Problem Management dengan Change Management, sehingga analisis lintas proses dapat dilakukan.
Mengapa ini penting
Menghubungkan penyelidikan masalah dengan perbaikannya dalam proses Change Management.
Sumber data
Tautan issue dengan jenis 'is fixed by' atau yang serupa
Contoh
CR-404CHG-1099CR-5512
|
|||
|
Solusi sementara tersedia
WorkaroundDetails
|
Menunjukkan apakah solusi sementara untuk masalah telah didokumentasikan. | ||
|
Deskripsi
Mencatat apakah teks solusi sementara tersedia atau telah dipublikasikan. Informasi ini membantu organisasi memantau 'Kecepatan publikasi solusi sementara'. Analisis kolom ini menunjukkan seberapa cepat tim dapat memulihkan kestabilan layanan sebelum menemukan perbaikan permanen.
Mengapa ini penting
Penting untuk mengukur kecepatan pemberian solusi sementara bagi bisnis.
Sumber data
Kolom khusus 'Workaround'
Contoh
Mulai ulang layananHapus cache browserTidak ada solusi yang diberikan
|
|||
|
Status pelanggaran SLA
SlaBreachStatus
|
Menunjukkan apakah catatan masalah telah melampaui batas waktu perjanjian tingkat layanan. | ||
|
Deskripsi
Kolom boolean atau status yang menunjukkan apakah waktu penyelesaian melampaui target yang disepakati. Informasi ini membantu dashboard 'Kepatuhan SLA dan tren target'. Kolom ini menandai kasus yang dapat menimbulkan risiko kepatuhan atau denda bagi organisasi.
Mengapa ini penting
Penting untuk memantau kepatuhan dan kinerja.
Sumber data
Logika kolom SLA Jira Service Management
Contoh
TerpenuhiTerlampauiDijeda
|
|||
|
Sumber deteksi
DetectionSource
|
Cara masalah teridentifikasi, misalnya proaktif atau reaktif. | ||
|
Deskripsi
Menunjukkan sumber identifikasi masalah. Nilai yang umum antara lain 'Pemantauan proaktif', 'Insiden service desk', atau 'Pemberitahuan pemasok'. Atribut ini digunakan di dashboard 'Identifikasi proaktif vs. reaktif' untuk mengukur kematangan proses manajemen masalah.
Mengapa ini penting
Mengukur kematangan proses dan efektivitas sistem pemantauan.
Sumber data
Kolom khusus 'Source' atau 'Detection Source'
Contoh
Pemantauan proaktifEskalasi insidenPemberitahuan pemasok
|
|||
|
Tanggal pembuatan
CreatedDate
|
Tanggal catatan masalah dibuat. | ||
|
Deskripsi
Waktu masalah pertama kali dicatat di sistem. Stempel waktu peristiwa mencatat waktu aktivitas, sedangkan atribut ini biasanya digunakan untuk memfilter data secara umum, misalnya 'Tampilkan semua masalah yang dibuat pada kuartal pertama'. Tanggal ini menjadi acuan untuk analisis usia masalah.
Mengapa ini penting
Tanggal acuan untuk menganalisis usia masalah dan volume laporan masuk.
Sumber data
Kolom issue 'Created'
Contoh
2023-01-012023-06-15
|
|||
|
Tinjauan pascapenerapan dilakukan
ReviewStatus
|
Menunjukkan apakah Tinjauan Pascaimplementasi (PIR) telah dilakukan. | ||
|
Deskripsi
Mencatat apakah aktivitas atau penanda 'Tinjauan Pascaimplementasi' ada pada kasus. Informasi ini penting untuk dashboard 'Kepatuhan tinjauan pascaimplementasi'. Informasi ini membantu memastikan organisasi memenuhi persyaratan tata kelola untuk perbaikan berkelanjutan.
Mengapa ini penting
Metrik kepatuhan untuk pembelajaran organisasi.
Sumber data
Kolom khusus 'PIR Status' atau keberadaan aktivitas 'PIR'
Contoh
SelesaiMenungguTidak diperlukan
|
|||
Aktivitas pengelolaan masalah
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Akar penyebab ditemukan
|
Saat penyebab mendasar dicatat secara resmi. Peristiwa ini disimpulkan dari perubahan status menjadi 'Root Cause Identified' atau pengisian kolom 'Root Cause'. | ||
|
Mengapa ini penting
Tonggak penting yang mengakhiri tahap investigasi. Diperlukan untuk menghitung 'Rata-rata Waktu hingga Akar Penyebab Ditemukan'.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'Root Cause Identified' ATAU kolom 'Root Cause' diisi
Pengumpulan data
Bandingkan kolom status atau periksa apakah kolom telah diisi
Jenis peristiwa
inferred
|
|||
|
Catatan masalah dibuat
|
Peristiwa awal saat tiket masalah dibuat di sistem. Waktu pembuatannya tercatat secara eksplisit dalam riwayat tiket. | ||
|
Mengapa ini penting
Menandai awal siklus manajemen masalah dan memungkinkan analisis jumlah kasus. Penting untuk menghitung laju penyelesaian dan jumlah kasus masuk.
Sumber data
Tabel Jira Issue: stempel waktu Created Date atau tab History: peristiwa Issue Created
Pengumpulan data
Dicatat saat transaksi pembuatan tiket disimpan
Jenis peristiwa
explicit
|
|||
|
Catatan masalah ditutup
|
Akhir siklus hidup masalah. Tercatat secara eksplisit saat status berubah menjadi 'Closed'. | ||
|
Mengapa ini penting
Menandai akhir proses. Diperlukan untuk menghitung total waktu siklus dan tingkat penutupan.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'Closed'
Pengumpulan data
Dicatat saat status berubah menjadi Closed
Jenis peristiwa
explicit
|
|||
|
Ditugaskan ke grup dukungan
|
Penugasan catatan masalah kepada tim teknis atau grup dukungan tertentu. Perubahan ini dilacak melalui kolom khusus 'Support Group' atau kolom 'Assignee' jika grup tidak digunakan. | ||
|
Mengapa ini penting
Penting untuk menganalisis serah terima dan hambatan antar tim. Tingginya frekuensi perpindahan dapat menunjukkan ketidakefisienan dalam perutean.
Sumber data
Riwayat Jira Issue: kolom 'Support Group' atau 'Assignee' berubah
Pengumpulan data
Dicatat saat kolom penugasan berubah
Jenis peristiwa
explicit
|
|||
|
Insiden ditautkan ke masalah
|
Tindakan menautkan tiket insiden terkait ke catatan masalah. Tautan ini tercatat di tabel tautan tiket atau riwayat. | ||
|
Mengapa ini penting
Menentukan dampak dan cakupan masalah. Penting untuk KPI 'Kedalaman Tautan Insiden ke Masalah' dan penentuan prioritas berdasarkan dampak bisnis.
Sumber data
Tautan Jira Issue: tautan dibuat dengan jenis 'causes' atau 'relates to'
Pengumpulan data
Dicatat saat tautan tiket dibuat
Jenis peristiwa
explicit
|
|||
|
Investigasi dimulai
|
Status masalah berubah ke tahap investigasi aktif, misalnya 'Under Investigation' atau 'In Progress'. Ini menandai dimulainya pekerjaan aktif. | ||
|
Mengapa ini penting
Memulai penghitungan waktu siklus investigasi. Membantu membedakan waktu tunggu dalam antrean dari waktu analisis aktif.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'Under Investigation' atau 'In Progress'
Pengumpulan data
Bandingkan pembaruan kolom status
Jenis peristiwa
inferred
|
|||
|
Penyelesaian diverifikasi
|
Konfirmasi bahwa perbaikan berhasil menyelesaikan masalah. Disimpulkan dari transisi status menjadi 'Resolved' atau status khusus 'Verified'. | ||
|
Mengapa ini penting
Tahap pemeriksaan kualitas untuk memastikan perbaikan berhasil. Keterlambatan di sini menunjukkan hambatan dalam pengujian atau penerimaan pengguna.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'Resolved' atau 'Verified'
Pengumpulan data
Bandingkan pembaruan kolom status
Jenis peristiwa
inferred
|
|||
|
Solusi sementara diperbarui
|
Kolom teks 'Workaround' diisi atau diperbarui. Peristiwa ini menunjukkan bahwa perbaikan sementara telah didokumentasikan. | ||
|
Mengapa ini penting
Mengukur kecepatan pemberian solusi sementara kepada bisnis. Penting untuk KPI 'Waktu hingga Solusi Sementara Tersedia'.
Sumber data
Riwayat Jira Issue: kolom 'Workaround' berubah (tidak kosong)
Pengumpulan data
Dicatat saat kolom Workaround diubah
Jenis peristiwa
explicit
|
|||
|
Masalah dibuka kembali
|
Masalah beralih dari status 'Resolved' atau 'Closed' kembali ke status aktif. Ini menunjukkan perbaikan gagal atau penyelesaian ditolak. | ||
|
Mengapa ini penting
Metrik kualitas utama. Tingginya tingkat pembukaan kembali menunjukkan analisis akar penyebab atau pengujian yang kurang efektif.
Sumber data
Riwayat Jira Issue: status berubah dari 'Closed'/'Resolved' menjadi 'Open'/'In Progress'
Pengumpulan data
Bandingkan urutan kolom status
Jenis peristiwa
inferred
|
|||
|
Perbaikan permanen diterapkan
|
Transisi yang menunjukkan bahwa solusi telah diterapkan. Biasanya disimpulkan dari perubahan status menjadi 'Implementing' atau 'Fixed'. | ||
|
Mengapa ini penting
Menandai berakhirnya pekerjaan perbaikan teknis. Digunakan untuk mengukur waktu siklus penerapan.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'Implemented', 'Pending Verification', atau 'Fixed'
Pengumpulan data
Bandingkan pembaruan kolom status
Jenis peristiwa
inferred
|
|||
|
Permintaan perubahan ditautkan
|
Permintaan Perubahan (RFC) ditautkan ke catatan masalah. Ini menandai dimulainya proses perbaikan permanen. | ||
|
Mengapa ini penting
Mengukur jeda antara penemuan penyebab dan dimulainya perbaikan. Mendukung KPI 'Keterlambatan Transisi ke Manajemen Perubahan'.
Sumber data
Tautan Jira Issue: tautan dibuat dengan jenis 'is fixed by' atau ditautkan ke jenis tiket 'Change'
Pengumpulan data
Dicatat saat tautan ke tiket jenis Change dibuat
Jenis peristiwa
explicit
|
|||
|
Prioritas masalah diubah
|
Pembaruan kolom Priority pada catatan masalah. Perubahan ini diketahui dengan memantau riwayat untuk melihat perubahan pada kolom 'Priority'. | ||
|
Mengapa ini penting
Menunjukkan eskalasi atau penurunan tingkat penanganan masalah. Analisis ini membantu menilai ketepatan triase awal dan lamanya masalah berprioritas tinggi tertahan.
Sumber data
Riwayat Jira Issue: kolom 'Priority' berubah dari nilai lama ke nilai baru
Pengumpulan data
Dicatat saat kolom Priority diperbarui
Jenis peristiwa
explicit
|
|||
|
SLA terlampaui
|
Peristiwa yang menunjukkan bahwa waktu penyelesaian masalah melewati batas Service Level Agreement yang ditetapkan. Dihitung dengan membandingkan tanggal target SLA dengan tanggal penyelesaian. | ||
|
Mengapa ini penting
Penting untuk pelaporan kepatuhan. Membantu menemukan prioritas atau kategori yang paling sering tidak memenuhi target.
Sumber data
Log SLA Jira Service Management: 'Time to Resolution' > Target, atau dihitung
Pengumpulan data
Ambil dari data kolom SLA atau bandingkan Due Date dengan Resolution Date
Jenis peristiwa
calculated
|
|||
|
Tinjauan pascapenerapan
|
Tinjauan yang dilakukan setelah perbaikan diterapkan. Tercatat melalui perubahan status menjadi 'In Review' atau pembaruan kolom khusus PIR. | ||
|
Mengapa ini penting
Aktivitas kepatuhan untuk memastikan pelajaran yang diperoleh dicatat. Mendukung analisis 'Kepatuhan Tinjauan Pascapenerapan'.
Sumber data
Riwayat Jira Issue: status berubah menjadi 'In Review' ATAU kolom 'PIR Notes' diperbarui
Pengumpulan data
Bandingkan kolom status atau pembaruan kolom PIR
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Ubah data pengelolaan masalah Anda menjadi wawasan yang dapat ditindaklanjuti. Unduh panduan atau hubungi tim dukungan kami untuk memulai process mining.
Optimalkan alur pengelolaan masalah Anda sekarang
Kurangi waktu siklus hingga 30% dan jaga stabilitas lingkungan TI Anda.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.