Templat data pengelolaan insiden Anda
Templat data pengelolaan insiden Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data dari Jira Service Management
Atribut pengelolaan insiden
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa atau perubahan status tertentu yang terjadi pada insiden. | ||
|
Deskripsi
Aktivitas menunjukkan langkah atau peristiwa tertentu dalam siklus penanganan insiden, seperti 'Insiden Dibuat', 'Insiden Ditugaskan', atau 'Penyelesaian Diusulkan'. Data ini biasanya diambil dari perubahan status atau pembaruan tertentu yang tercatat dalam riwayat atau changelog masalah di Jira. process mining menganalisis urutan dan durasi aktivitas untuk mengungkap alur proses yang sebenarnya, hambatan, dan penyimpangan.
Mengapa ini penting
Aktivitas menjadi dasar peta proses dan membantu memvisualisasikan serta menganalisis siklus penanganan insiden.
Sumber data
Diambil dari riwayat masalah dan changelog Jira, termasuk perubahan status dan pembaruan kolom penting.
Contoh
Insiden ditugaskanInvestigasi dimulaiInsiden terselesaikan
|
|||
|
ID insiden
IncidentId
|
Pengenal unik untuk setiap tiket insiden di Jira Service Management. | ||
|
Deskripsi
Incident ID, yang sering disebut Issue Key di Jira, menjadi pengenal unik utama untuk setiap insiden yang dilaporkan. ID ini menghubungkan semua aktivitas, komentar, dan perubahan status terkait, sejak insiden dibuat hingga ditutup. Dalam process mining, ID ini penting untuk menyusun kembali siklus hidup setiap insiden dari awal hingga akhir, sehingga seluruh proses dapat dianalisis.
Mengapa ini penting
ID ini menjadi pengenal utama untuk menghubungkan semua peristiwa terkait ke dalam satu kasus, sehingga menjadi dasar analisis process mining.
Sumber data
Ini adalah kolom 'Key' standar untuk suatu masalah di Jira Service Management (misalnya, 'ITSM-123').
Contoh
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Waktu mulai
EventTimestamp
|
Tanggal dan waktu tepat saat aktivitas terjadi. | ||
|
Deskripsi
Atribut ini mencatat stempel waktu setiap aktivitas dalam siklus penanganan insiden. Data ini penting untuk menghitung durasi, waktu siklus, dan waktu tunggu antar langkah proses. Stempel waktu yang akurat mendukung analisis kinerja terperinci, pemantauan SLA, dan identifikasi hambatan. Semua metrik kinerja, seperti waktu penyelesaian dan durasi diagnosis, dihitung dari stempel waktu ini.
Mengapa ini penting
Stempel waktu diperlukan untuk menghitung semua metrik berbasis waktu, memahami durasi proses, dan menemukan hambatan kinerja.
Sumber data
Ini adalah tanggal 'created' yang tercatat pada setiap entri di changelog atau riwayat masalah Jira.
Contoh
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan data terakhir kali diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat waktu terakhir dataset diperbarui. Informasi ini membantu siapa pun yang menganalisis proses mengetahui seberapa baru data yang digunakan. Hal ini sangat penting untuk dashboard pemantauan berkelanjutan, yang memerlukan informasi terbaru agar keputusan dapat diambil tepat waktu. Biasanya, nilainya sama untuk semua peristiwa dalam satu batch ekstraksi data.
Mengapa ini penting
Memberi tahu pengguna seberapa baru data yang digunakan, hal penting untuk menjaga relevansi dan akurasi analisis.
Sumber data
Ini adalah stempel waktu saat data diekstrak, yang ditambahkan selama proses transformasi data.
Contoh
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data diambil. | ||
|
Deskripsi
Atribut ini menunjukkan asal data, dalam hal ini Jira Service Management. Atribut ini berguna saat data dari beberapa sistem digabungkan untuk memberikan gambaran proses secara menyeluruh. Dengan mencantumkan sistem sumber, asal-usul data tetap jelas dan masalah kualitas atau ekstraksi data lebih mudah ditelusuri. Untuk model ini, nilainya tetap.
Mengapa ini penting
Memberi konteks penting tentang asal data dan memastikan data mudah ditelusuri, terutama saat menganalisis beberapa sistem.
Sumber data
Nilai ini tetap dan perlu ditambahkan saat proses ekstraksi data.
Contoh
Jira Service ManagementJira Cloud
|
|||
|
Grup penugasan
AssignmentGroup
|
Tim atau grup yang bertanggung jawab menangani insiden. | ||
|
Deskripsi
Assignment Group menunjukkan tim yang ditugaskan menangani insiden. Tim ini bisa berupa tingkat dukungan seperti 'L1 Helpdesk', tim khusus seperti 'Network Operations', atau tim pengembangan. Menganalisis perpindahan antargrup penugasan membantu memahami eskalasi dan perpindahan tugas dalam proses. Analisis ini juga membantu mengukur kinerja tim, menemukan hambatan di tingkat tim, dan melihat ketergantungan antar tim.
Mengapa ini penting
Penting untuk menganalisis kinerja tim, jumlah pekerjaan yang diselesaikan, dan alur kerja antar tingkat dukungan atau grup khusus.
Sumber data
Biasanya diterapkan sebagai kolom khusus di Jira, seperti 'Team' atau 'Assignment Group'. Terkadang, nilainya dapat diambil dari Jira Components atau Project Roles.
Contoh
Dukungan tingkat 1Tim infrastrukturAdministrator basis data
|
|||
|
Petugas yang ditugaskan
Assignee
|
Pengguna yang saat ini ditugaskan menangani insiden. | ||
|
Deskripsi
Assignee adalah agen atau pengguna yang bertanggung jawab menangani insiden pada waktu tertentu. Melacak perubahan assignee penting untuk menganalisis perpindahan tugas, memahami pembagian beban kerja, dan mengetahui siapa saja yang terlibat dalam langkah proses tertentu. Atribut ini membantu menjawab pertanyaan tentang kinerja individu dan alokasi sumber daya dalam tim dukungan.
Mengapa ini penting
Membantu melacak beban kerja individu, menemukan hambatan yang terkait dengan agen tertentu, dan menganalisis dampak perpindahan tugas terhadap waktu penyelesaian.
Sumber data
Kolom 'Assignee' standar pada masalah Jira.
Contoh
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Prioritas
Priority
|
Tingkat prioritas insiden yang menunjukkan seberapa mendesak penyelesaiannya. | ||
|
Deskripsi
Prioritas menentukan seberapa cepat insiden perlu ditangani. Biasanya, prioritas ditetapkan berdasarkan dampak dan urgensi, serta berpengaruh langsung pada target SLA. Analisis insiden berdasarkan prioritas membantu mengetahui apakah insiden berprioritas tinggi ditangani lebih cepat daripada yang berprioritas rendah, dan apakah prioritas diterapkan secara konsisten. Ini dimensi penting untuk memfilter dan membandingkan kinerja proses.
Mengapa ini penting
Penting untuk menganalisis kinerja SLA dan memastikan sumber daya dialokasikan dengan tepat untuk insiden paling kritis.
Sumber data
Kolom 'Priority' standar pada masalah Jira.
Contoh
TertinggiTinggiSedangRendah
|
|||
|
Status
Status
|
Tahap insiden saat ini dalam siklus penanganannya. | ||
|
Deskripsi
Kolom Status menunjukkan keadaan insiden saat ini dalam workflow yang ditetapkan, seperti 'Open', 'In Progress', 'Pending Customer', atau 'Resolved'. Perubahan status menjadi sumber utama untuk membuat log aktivitas bagi process mining. Menganalisis waktu yang dihabiskan pada setiap status merupakan langkah penting untuk menemukan hambatan dan memahami tahap yang paling banyak menyita waktu.
Mengapa ini penting
Menunjukkan langsung perkembangan insiden dan menjadi sumber utama untuk mengenali langkah proses serta waktu tunggu.
Sumber data
Kolom 'Status' standar pada masalah Jira.
Contoh
Sedang berlangsungMenunggu pelangganTerselesaikanDitutup
|
|||
|
Tanggal dibuat
CreatedDate
|
Tanggal dan waktu saat insiden pertama kali dibuat di sistem. | ||
|
Deskripsi
Atribut ini menandai awal resmi siklus penanganan insiden. Stempel waktu ini menjadi acuan untuk menghitung metrik keseluruhan, seperti total waktu penyelesaian. Tanggal pembuatan tidak berubah untuk setiap insiden dan menjadi titik awal kasus dalam analisis process mining.
Mengapa ini penting
Menjadi titik awal untuk menghitung waktu siklus dari awal hingga akhir dan mengukur SLA.
Sumber data
Kolom 'Created' standar pada masalah Jira.
Contoh
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Tanggal penyelesaian
ResolutionDate
|
Tanggal dan waktu saat insiden ditandai sebagai terselesaikan. | ||
|
Deskripsi
Atribut ini mencatat stempel waktu saat insiden pertama kali dipindahkan ke status terselesaikan. Waktu ini menandai akhir tahap pengerjaan aktif dan menjadi titik akhir untuk menghitung waktu penyelesaian. Membandingkan tanggal penyelesaian dengan tanggal pembuatan memberikan ukuran utama efisiensi proses. Data ini juga menjadi bagian penting dalam menentukan kepatuhan SLA.
Mengapa ini penting
Menandai akhir proses penyelesaian, sehingga total waktu siklus dan kinerja SLA dapat dihitung.
Sumber data
Kolom 'Resolved' standar pada masalah Jira.
Contoh
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
ID masalah tertaut
LinkedProblemId
|
Pengenal tiket masalah yang ditautkan ke insiden ini. | ||
|
Deskripsi
Insiden yang merupakan gejala dari masalah mendasar yang lebih besar sering ditautkan ke tiket Problem. Kolom ini menyimpan ID Problem terkait. Menganalisis tautan ini membantu memahami hubungan antara insiden dan masalah, mengukur efektivitas proses pengelolaan masalah, serta menemukan insiden berulang yang memerlukan perbaikan permanen.
Mengapa ini penting
Menghubungkan insiden dengan masalah yang mendasarinya, sehingga organisasi dapat menganalisis seberapa efektif akar masalah ditangani untuk mencegah insiden berulang.
Sumber data
Informasi ini tersimpan di bagian 'Issue Links' pada masalah Jira.
Contoh
PROB-123PROB-456Tidak ada
|
|||
|
Jenis masalah
IssueType
|
Jenis masalah, seperti Insiden, Permintaan Layanan, atau Masalah. | ||
|
Deskripsi
Jira menggunakan Issue Types untuk membedakan berbagai jenis pekerjaan. Dalam penanganan insiden, jenis utamanya adalah 'Incident', tetapi jenis lain seperti 'Sub-task' mungkin juga relevan. Atribut ini penting untuk memfilter dataset agar hanya mencakup insiden, sehingga analisis process mining berfokus pada proses yang tepat.
Mengapa ini penting
Memastikan analisis hanya mencakup insiden dan memisahkannya dari jenis pekerjaan lain, seperti permintaan layanan atau perubahan.
Sumber data
Kolom 'Issue Type' standar pada masalah Jira.
Contoh
InsidenBantuan TIBug
|
|||
|
Jenis permintaan pelanggan
CustomerRequestType
|
Jenis permintaan tertentu yang diajukan pelanggan melalui portal layanan. | ||
|
Deskripsi
Kolom ini mengelompokkan permintaan dari sudut pandang pelanggan, sesuai pilihan yang tersedia di portal Jira Service Management (misalnya, 'Laporkan masalah sistem'). Kolom ini memberikan kategori yang mudah dipahami pelanggan dan dapat berbeda dari 'Issue Type' internal. Analisis atribut ini dapat menunjukkan cara pelanggan memahami dan melaporkan masalah, sehingga membantu meningkatkan desain portal dan layanan yang ditawarkan.
Mengapa ini penting
Memberikan gambaran kategori insiden dari sudut pandang pelanggan, berguna untuk menganalisis permintaan dan meningkatkan pengalaman pelanggan.
Sumber data
Kolom 'Customer Request Type' khusus untuk proyek Jira Service Management.
Contoh
Dapatkan bantuan TI > Laporkan masalah sistemEmail > Permintaan akses
|
|||
|
Jumlah perpindahan tugas
HandoffCount
|
Berapa kali insiden dialihkan ke grup atau pengguna lain. | ||
|
Deskripsi
Metrik hasil perhitungan ini menghitung berapa kali kolom 'Assignee' atau 'AssignmentGroup' berubah selama siklus penanganan insiden. Jumlah perpindahan tugas yang tinggi sering menunjukkan proses yang tidak efisien, masalah yang tidak terselesaikan saat kontak pertama, atau kesenjangan pengetahuan, sehingga waktu penyelesaian menjadi lebih lama. Menganalisis KPI ini membantu menyederhanakan proses penugasan dan meningkatkan kolaborasi tim.
Mengapa ini penting
Mengukur hambatan dan inefisiensi proses akibat pengalihan tugas, sehingga peluang perbaikan proses dapat ditemukan.
Sumber data
Dihitung dengan menghitung perubahan pada kolom 'Assignee' atau 'AssignmentGroup' di changelog masalah.
Contoh
015
|
|||
|
Kategori akar masalah
RootCauseCategory
|
Klasifikasi penyebab utama insiden. | ||
|
Deskripsi
Atribut ini mencatat penyebab utama insiden, seperti 'Kesalahan Perangkat Lunak', 'Kerusakan Perangkat Keras', atau 'Kesalahan Pengguna'. Biasanya, nilainya diisi setelah penyelidikan dan penting untuk pengelolaan masalah yang efektif serta pencegahan insiden di masa mendatang. Menganalisis kategori akar masalah membantu menemukan kelemahan sistemik dan menentukan prioritas perbaikan. Banyaknya akar masalah yang 'Tidak Diketahui' dapat menandakan perlunya proses penyelidikan yang lebih baik.
Mengapa ini penting
Mendukung analisis akar masalah dan membantu organisasi beralih dari pendekatan reaktif ke proaktif dengan menemukan serta menangani sumber insiden.
Sumber data
Hampir selalu berupa kolom khusus di Jira. Nama dan pilihannya sangat bergantung pada konfigurasi organisasi.
Contoh
Kesalahan konfigurasiGangguan jaringanBug perangkat lunak
|
|||
|
Komponen
Component
|
Sistem, aplikasi, atau bagian infrastruktur yang terdampak insiden. | ||
|
Deskripsi
Components adalah bagian-bagian dalam proyek Jira yang digunakan untuk mengelompokkan masalah, misalnya 'Antarmuka Pengguna', 'Basis Data', atau 'API'. Menganalisis insiden berdasarkan komponen membantu menemukan bagian sistem yang paling sering bermasalah. Informasi ini berguna untuk analisis akar masalah dan dapat membantu menentukan prioritas perbaikan layanan atau pengurangan utang teknis.
Mengapa ini penting
Memungkinkan pemfilteran dan analisis berdasarkan produk atau bagian sistem yang terdampak, sehingga area teknologi yang sering bermasalah dapat ditemukan.
Sumber data
Kolom 'Components' standar pada masalah Jira.
Contoh
Layanan autentikasiDasbor pelaporanAplikasi seluler
|
|||
|
Mengalami pengerjaan ulang
IsRework
|
Penanda yang menunjukkan apakah insiden perlu dikerjakan ulang, misalnya karena dibuka kembali. | ||
|
Deskripsi
Atribut boolean hasil perhitungan ini menandai insiden yang kembali ke tahap sebelumnya dalam proses, biasanya karena dibuka kembali setelah dinyatakan terselesaikan. Siklus pengerjaan ulang menjadi sumber inefisiensi dan ketidakpuasan pelanggan. Penanda ini memudahkan penghitungan tingkat pengerjaan ulang dan membantu analisis mencari tahu mengapa insiden tidak berhasil diselesaikan dengan benar pada upaya pertama.
Mengapa ini penting
Menandai insiden yang memerlukan pengerjaan berulang untuk menyoroti masalah kualitas dan inefisiensi proses, serta mendukung analisis pengerjaan ulang.
Sumber data
Dihitung dengan mendeteksi urutan perubahan status tertentu di log peristiwa, seperti 'Resolved' -> 'Reopened'.
Contoh
truefalse
|
|||
|
Pelanggaran SLA
SlaBreach
|
Penanda yang menunjukkan apakah waktu penyelesaian insiden melampaui target SLA. | ||
|
Deskripsi
Atribut boolean hasil perhitungan ini menunjukkan apakah insiden melanggar SLA 'Time to Resolution'. Nilainya true jika 'IncidentResolutionCycleTime' lebih besar daripada 'TimeToResolutionTarget'. Penanda ini memudahkan analisis dan visualisasi, serta memungkinkan pemfilteran dan penghitungan untuk memperoleh KPI Tingkat Pelanggaran SLA secara keseluruhan. Ini adalah ukuran hasil utama untuk dashboard Pemantauan Kinerja SLA.
Mengapa ini penting
Memberikan hasil yang jelas, ya atau tidak, untuk kinerja SLA. Dengan begitu, tingkat pelanggaran mudah dihitung dan area bermasalah dapat ditemukan.
Sumber data
Dihitung dengan rumus ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Contoh
truefalse
|
|||
|
Pelapor
Reporter
|
Pengguna yang pertama kali membuat atau melaporkan insiden. | ||
|
Deskripsi
Reporter adalah orang, biasanya pengguna akhir atau sistem lain, yang pertama kali mencatat insiden. Menganalisis insiden berdasarkan pelapor dapat membantu menemukan pengguna atau departemen yang sering mengalami masalah. Analisis ini juga dapat menunjukkan pola komunikasi, terutama saat meninjau aktivitas seperti 'Menunggu Pelanggan' dan 'Pelanggan Membalas'.
Mengapa ini penting
Membantu menganalisis sumber insiden, menemukan pola pada pengguna atau departemen tertentu, dan memahami keterlambatan interaksi dengan pelanggan.
Sumber data
Kolom 'Reporter' standar pada masalah Jira.
Contoh
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Penyelesaian
Resolution
|
Hasil akhir atau alasan insiden dinyatakan selesai. | ||
|
Deskripsi
Kolom Resolution menjelaskan alasan insiden dipindahkan ke status terselesaikan. Contoh nilai penyelesaian yang umum adalah 'Fixed', 'Duplicate', 'Won't Do', atau 'Cannot Reproduce'. Menganalisis sebaran jenis penyelesaian dapat memberi gambaran tentang kualitas laporan yang masuk dan efektivitas proses penyelesaian. Misalnya, banyak penyelesaian 'Duplicate' dapat menandakan masalah pada tahap pembuatan atau triase insiden.
Mengapa ini penting
Memberi konteks tentang hasil penanganan insiden, membantu mengelompokkan penyelesaian, dan menemukan pola penutupan insiden.
Sumber data
Kolom 'Resolution' standar pada masalah Jira. Kolom ini biasanya diisi saat masalah berpindah ke kategori status 'Done'.
Contoh
SelesaiDiperbaikiDuplikatTidak akan diperbaiki
|
|||
|
Target waktu penyelesaian
TimeToResolutionTarget
|
Durasi target SLA untuk menyelesaikan insiden. | ||
|
Deskripsi
Atribut ini menetapkan batas waktu yang diharapkan untuk menyelesaikan insiden berdasarkan prioritas atau jenisnya. Nilai ini menjadi patokan untuk membandingkan waktu penyelesaian aktual dan menentukan kepatuhan SLA. Biasanya, nilainya ditetapkan secara dinamis berdasarkan aturan yang mempertimbangkan prioritas, tingkat keparahan, atau jenis masalah. Atribut ini menjadi dasar dashboard pemantauan kinerja SLA.
Mengapa ini penting
Menjadi patokan untuk mengukur kepatuhan SLA dan dasar KPI Tingkat Pelanggaran SLA Insiden.
Sumber data
Nilai ini diambil dari konfigurasi SLA di Jira Service Management. Tentukan sasaran yang sesuai, misalnya 'Time to resolution'.
Contoh
4 jam8 jam3 hari
|
|||
|
Tingkat keparahan
Severity
|
Ukuran dampak insiden terhadap bisnis. | ||
|
Deskripsi
Severity menunjukkan besarnya dampak insiden terhadap bisnis, mulai dari gangguan yang dialami satu pengguna hingga sistem penting yang tidak berfungsi. Priority menentukan urutan pekerjaan, sedangkan Severity menunjukkan dampak keseluruhan terhadap bisnis. Analisis berdasarkan tingkat keparahan membantu memahami kinerja proses untuk insiden yang paling berdampak pada bisnis. Atribut ini sering dipadukan dengan Priority agar analisis lebih terperinci.
Mengapa ini penting
Menunjukkan dampak terhadap bisnis dan membantu memusatkan analisis pada insiden yang paling mengganggu operasional bisnis.
Sumber data
Biasanya berupa kolom khusus di Jira karena bukan kolom standar sistem. Periksa konfigurasi proyek Jira Service Management.
Contoh
KritisBesarKecilSangat ringan
|
|||
Aktivitas pengelolaan insiden
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Insiden dialihkan
|
Terjadi saat insiden dialihkan dari satu agen atau grup ke agen atau grup lain setelah penugasan awal. Peristiwa ini disimpulkan dari setiap perubahan pada kolom 'Petugas' atau 'Grup yang Ditugaskan'. | ||
|
Mengapa ini penting
Pelacakan pengalihan penting untuk menganalisis perpindahan penanganan. Pengalihan yang sering biasanya menandakan inefisiensi proses, kesenjangan pengetahuan, atau perutean awal yang keliru, sehingga penyelesaian tertunda.
Sumber data
Disimpulkan dari riwayat masalah dengan mendeteksi setiap pembaruan pada kolom 'Petugas' setelah kolom tersebut pertama kali diisi. Setiap perubahan dihitung sebagai peristiwa pengalihan.
Pengumpulan data
Temukan perubahan berikutnya pada kolom 'Petugas' setelah penugasan awal.
Jenis peristiwa
inferred
|
|||
|
Insiden dibuat
|
Menandai awal resmi siklus insiden, saat laporan insiden dikirim dan masalah baru dibuat di Jira. Peristiwa ini tercatat secara eksplisit ketika masalah baru bertipe 'Insiden' dimasukkan ke sistem. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses. Mengukur waktu dari aktivitas ini hingga penyelesaian menjadi dasar untuk menghitung waktu siklus keseluruhan dan kepatuhan SLA.
Sumber data
Peristiwa ini tercatat secara eksplisit dari stempel waktu 'dibuat' pada masalah insiden di Jira. Pembuatan masalah juga tercatat dalam riwayatnya.
Pengumpulan data
Gunakan stempel waktu pembuatan masalah.
Jenis peristiwa
explicit
|
|||
|
Insiden ditutup
|
Menunjukkan penutupan administratif akhir tiket insiden setelah insiden diselesaikan dan diverifikasi. Peristiwa ini disimpulkan dari perubahan status menjadi 'Ditutup'. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir proses. Analisis waktu antara 'Terselesaikan' dan 'Ditutup' dapat menunjukkan penundaan dalam penyelesaian administrasi atau proses konfirmasi pengguna.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Peristiwa ini menunjukkan stempel waktu saat status berubah menjadi status akhir 'Ditutup'.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Ditutup'.
Jenis peristiwa
inferred
|
|||
|
Insiden terselesaikan
|
Aktivitas ini menandai konfirmasi bahwa insiden berhasil diselesaikan dan layanan telah pulih. Biasanya, aktivitas ini bertepatan dengan perubahan status menjadi 'Terselesaikan'. | ||
|
Mengapa ini penting
Ini adalah tonggak keberhasilan utama dalam proses. Durasi hingga titik ini menjadi KPI yang paling umum, yaitu waktu penyelesaian (TTR).
Sumber data
Disimpulkan dari perubahan status menjadi 'Terselesaikan'. Dalam banyak alur kerja, peristiwa ini sama dengan 'Penyelesaian diusulkan' dan menandai titik utama penyelesaian.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Terselesaikan'.
Jenis peristiwa
inferred
|
|||
|
Investigasi dimulai
|
Menunjukkan bahwa agen yang ditugaskan mulai aktif mendiagnosis insiden. Peristiwa ini biasanya disimpulkan saat status masalah insiden berubah dari 'Terbuka' atau 'Baru' menjadi 'Sedang Berlangsung'. | ||
|
Mengapa ini penting
Tonggak penting ini menandai dimulainya upaya penyelesaian secara aktif. Mengukur waktu hingga aktivitas ini membantu menemukan penundaan awal dalam antrean dan masalah ketersediaan sumber daya.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Stempel waktu peristiwa adalah saat status berubah ke kondisi yang menandakan pekerjaan aktif, seperti 'Sedang Berlangsung'.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Sedang Berlangsung'.
Jenis peristiwa
inferred
|
|||
|
Menunggu pelanggan
|
Menandai saat tim dukungan menunggu informasi atau tindakan dari pelanggan. Peristiwa ini disimpulkan dari perubahan status ke status tunggu khusus, seperti 'Menunggu pelanggan'. | ||
|
Mengapa ini penting
Memisahkan waktu 'ditangguhkan' ini penting untuk mengukur SLA secara akurat karena waktu tersebut sering tidak dihitung dalam waktu penyelesaian. Data ini juga membantu menganalisis keterlambatan respons pelanggan.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Peristiwa ini terjadi saat status berubah menjadi 'Menunggu pelanggan' atau status serupa.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Menunggu pelanggan'.
Jenis peristiwa
inferred
|
|||
|
Penyelesaian diusulkan
|
Aktivitas ini menunjukkan bahwa solusi telah ditemukan dan diterapkan, sementara insiden menunggu konfirmasi atau validasi akhir. Peristiwa ini disimpulkan dari perubahan status menjadi 'Terselesaikan'. | ||
|
Mengapa ini penting
Tonggak penting ini menandai berakhirnya pekerjaan aktif tim dukungan. Peristiwa ini sering kali menghentikan penghitungan waktu SLA.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Stempel waktu peristiwa adalah saat status berubah menjadi 'Terselesaikan' atau status yang setara.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Terselesaikan'.
Jenis peristiwa
inferred
|
|||
|
Dieskalasikan ke tim spesialis
|
Menunjukkan bahwa insiden dieskalasikan ke tim spesialis, misalnya Tingkat 2 atau tim Pengembangan, untuk mendapatkan dukungan lanjutan. Peristiwa ini disimpulkan dari perubahan pada kolom khusus 'Tim Dukungan' atau pengalihan tertentu. | ||
|
Mengapa ini penting
Menunjukkan insiden yang memerlukan keahlian khusus dan melacak perpindahan antarlevel dukungan. Informasi ini membantu menemukan hambatan di tim spesialis dan menganalisis pola eskalasi.
Sumber data
Disimpulkan dari riwayat masalah dengan melacak perubahan pada kolom khusus yang menunjukkan tim yang ditugaskan, atau dengan menemukan perubahan 'Petugas' kepada anggota grup spesialis yang diketahui.
Pengumpulan data
Deteksi perubahan pada kolom khusus 'Tim yang Ditugaskan' atau perubahan petugas tertentu.
Jenis peristiwa
inferred
|
|||
|
Ditautkan ke tiket masalah
|
Terjadi saat insiden ditautkan ke masalah bertipe 'Masalah' untuk analisis akar penyebab. Peristiwa ini tercatat secara eksplisit saat tautan 'berkaitan dengan' atau 'disebabkan oleh' dibuat ke masalah bertipe Masalah. | ||
|
Mengapa ini penting
Pelacakan tautan ini penting untuk memahami seberapa efektif organisasi beralih dari mitigasi insiden ke analisis dan pencegahan akar penyebab.
Sumber data
Peristiwa ini tercatat secara eksplisit dalam riwayat tautan masalah. Setiap pembuatan tautan memiliki stempel waktu dan dapat difilter untuk tautan ke masalah bertipe 'Masalah'.
Pengumpulan data
Gunakan stempel waktu pembuatan tautan ke masalah bertipe 'Masalah'.
Jenis peristiwa
explicit
|
|||
|
Insiden dibuka kembali
|
Menunjukkan bahwa insiden yang sebelumnya telah diselesaikan diaktifkan kembali karena masalah muncul lagi atau perbaikannya tidak efektif. Peristiwa ini disimpulkan saat status berubah dari 'Terselesaikan' atau 'Ditutup' kembali ke status terbuka. | ||
|
Mengapa ini penting
Insiden yang dibuka kembali menjadi ukuran langsung kualitas penyelesaian dan indikator utama pengerjaan ulang. Analisis peristiwa ini membantu menemukan penutupan terlalu dini dan solusi yang tidak efektif.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Peristiwa ini tercatat saat status berubah dari status akhir seperti 'Terselesaikan' atau 'Ditutup' kembali menjadi 'Terbuka' atau 'Sedang Berlangsung'.
Pengumpulan data
Deteksi perubahan status dari 'Terselesaikan' atau 'Ditutup' ke status terbuka.
Jenis peristiwa
inferred
|
|||
|
Insiden ditugaskan
|
Aktivitas ini menandai penugasan awal insiden kepada agen atau grup dukungan untuk ditangani. Peristiwa ini tercatat saat kolom 'Petugas' atau 'Grup yang Ditugaskan' pertama kali diisi. | ||
|
Mengapa ini penting
Mengukur waktu respons dan penugasan awal, yang merupakan komponen penting dalam metrik SLA. Data ini membantu menemukan penundaan sebelum investigasi aktif dimulai.
Sumber data
Disimpulkan dari riwayat masalah dengan menemukan perubahan pertama pada kolom 'Petugas' yang nilai sebelumnya adalah 'Belum Ditugaskan'.
Pengumpulan data
Temukan pembaruan pertama pada kolom 'Petugas' di riwayat masalah.
Jenis peristiwa
inferred
|
|||
|
Komentar ditambahkan
|
Menunjukkan peristiwa komunikasi atau pencatatan saat pengguna menambahkan komentar pada tiket insiden. Peristiwa ini tercatat secara eksplisit setiap kali komentar dikirim. | ||
|
Mengapa ini penting
Analisis frekuensi komentar dapat memberikan wawasan tentang pola komunikasi, efektivitas kolaborasi, dan kompleksitas insiden. Analisis ini juga dapat menunjukkan insiden yang memerlukan komunikasi berlebihan.
Sumber data
Peristiwa ini tercatat secara eksplisit. Jira menyimpan setiap komentar beserta stempel waktu dan penulisnya, yang dapat diakses melalui riwayat komentar masalah atau API.
Pengumpulan data
Gunakan stempel waktu setiap komentar yang ditambahkan ke masalah.
Jenis peristiwa
explicit
|
|||
|
Pelanggan merespons
|
Menunjukkan bahwa pelanggan telah memberikan informasi yang diminta sehingga penanganan insiden dapat dilanjutkan. Peristiwa ini disimpulkan saat status berubah dari 'Menunggu pelanggan' kembali ke status aktif. | ||
|
Mengapa ini penting
Aktivitas ini menandai berakhirnya penundaan yang disebabkan oleh pelanggan. Analisis durasi antara 'Menunggu pelanggan' dan peristiwa ini menunjukkan rata-rata waktu respons pelanggan.
Sumber data
Disimpulkan dari riwayat perubahan status masalah. Peristiwa ini terjadi saat status berubah dari 'Menunggu pelanggan' menjadi status seperti 'Sedang Berlangsung', sering kali setelah pelanggan menambahkan komentar.
Pengumpulan data
Deteksi perubahan status dari 'Menunggu pelanggan' menjadi 'Sedang Berlangsung'.
Jenis peristiwa
inferred
|
|||
|
Prioritas insiden ditetapkan
|
Menunjukkan penetapan prioritas dan/atau tingkat keparahan insiden, yang menentukan urgensi dan dampaknya terhadap bisnis. Biasanya, peristiwa ini disimpulkan dari pengisian atau pembaruan pertama kolom 'Prioritas' atau 'Tingkat Keparahan' setelah insiden dibuat. | ||
|
Mengapa ini penting
Pelacakan penentuan prioritas membantu menilai apakah insiden dievaluasi dengan cepat dan konsisten. Penundaan pada langkah ini dapat langsung memengaruhi perhitungan SLA dan alokasi sumber daya.
Sumber data
Disimpulkan dari log riwayat masalah yang mencatat perubahan pada semua kolom. Cari pembaruan pertama pada kolom 'Prioritas' atau kolom khusus 'Tingkat Keparahan' setelah masalah dibuat.
Pengumpulan data
Temukan perubahan pertama pada kolom 'Prioritas' di riwayat masalah.
Jenis peristiwa
inferred
|
|||
|
Solusi sementara diberikan
|
Menunjukkan penerapan perbaikan sementara untuk memulihkan layanan sambil menyiapkan solusi permanen. Peristiwa ini dapat disimpulkan dari perubahan status atau komentar tertentu. | ||
|
Mengapa ini penting
Mengukur waktu yang diperlukan untuk memberikan solusi sementara menjadi indikator penting kecepatan pemulihan layanan. Pengukuran ini membantu membedakan mitigasi sementara dari penyelesaian permanen.
Sumber data
Peristiwa ini biasanya disimpulkan. Contohnya, status berubah menjadi 'Solusi sementara diberikan' atau komentar publik ditambahkan dengan kata kunci tertentu seperti 'solusi sementara'.
Pengumpulan data
Temukan perubahan status tertentu atau kata kunci dalam komentar.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi data
Siap memulai?
Gunakan templat data ini untuk meningkatkan pengelolaan insiden, menemukan inefisiensi, dan mempercepat penyelesaian. Mulai optimalkan proses Anda hari ini.
Optimalkan pengelolaan insiden dan selesaikan insiden lebih cepat
Kurangi MTTR hingga 35% dan tingkatkan kepuasan pengguna dengan proses yang lebih sederhana.
Tidak perlu kartu kredit • Siap digunakan dalam 5 menit