Templat Data Pengelolaan Insiden
Templat Data Pengelolaan Insiden
Ini template data umum kami untuk process mining Pengelolaan insiden. Gunakan template khusus sistem untuk mendapatkan panduan yang lebih terarah.
Pilih sistem tertentu- Struktur data umum untuk berbagai sistem pengelolaan insiden
- Atribut dan aktivitas yang disarankan untuk analisis menyeluruh
- Panduan ekstraksi data, termasuk contoh khusus sistem
Atribut Pengelolaan Insiden
| Nama | Deskripsi | ||
|---|---|---|---|
| ID Insiden IncidentId | Pengenal unik untuk setiap insiden. ID ini menjadi kunci utama untuk melacak insiden sepanjang siklusnya. | ||
| Deskripsi ID Insiden adalah kode alfanumerik unik yang membedakan satu insiden dari insiden lainnya di dalam sistem. ID ini dibuat saat insiden baru dicatat dan tetap sama hingga insiden diarsipkan secara permanen atau dihapus. Dalam process mining, ID Insiden menjadi dasar analisis dan berfungsi sebagai ID Kasus. ID ini membantu perangkat lunak menggabungkan semua peristiwa, perubahan status, dan aktivitas terkait menjadi satu rangkaian proses. Dengan mengelompokkan semua peristiwa berdasarkan ID Insiden yang sama, analis dapat memetakan perjalanan setiap insiden dari laporan awal hingga penyelesaian dan penutupan. Mengapa ini penting ID ini penting untuk menghubungkan semua aktivitas dan peristiwa terkait, sehingga siklus insiden dari awal hingga akhir dapat direkonstruksi untuk process mining. Sumber data Ini adalah kunci utama untuk sebuah insiden dan biasanya terdapat di bagian header atau catatan utama pada setiap tabel atau objek insiden. Contoh INC0010032TICKET-84321789456123 | |||
| Nama Aktivitas ActivityName | Nama aktivitas bisnis, peristiwa, atau perubahan status tertentu yang terjadi selama siklus insiden. | ||
| Deskripsi Nama Aktivitas menjelaskan langkah atau tugas tertentu dalam proses manajemen insiden. Aktivitas ini membentuk peta proses dan dapat mencakup peristiwa sistem otomatis, seperti 'Pelanggaran SLA Terdeteksi', atau tindakan manual pengguna, seperti 'Agen Ditugaskan' atau 'Solusi Sementara Diberikan'. Atribut ini menjadi dasar analisis process mining. Nama Aktivitas menentukan simpul dalam grafik proses, sehingga analis dapat melihat alur kerja, menemukan jalur yang umum, mengidentifikasi hambatan, dan menganalisis penyimpangan dari prosedur standar. Tingkat perincian dan kejelasan nama aktivitas berpengaruh langsung pada kualitas dan kedalaman wawasan yang dapat diperoleh. Mengapa ini penting Atribut ini menentukan langkah-langkah dalam proses, sehingga alur siklus insiden dapat divisualisasikan dan dianalisis. Sumber data Biasanya diperoleh dari gabungan log peristiwa, jejak audit, catatan perubahan status, atau kolom deskripsi tugas di sistem manajemen insiden. Contoh Insiden dibuatGrup ditetapkanInsiden DiselesaikanStatus berubah menjadi menunggu | |||
| Stempel Waktu Peristiwa EventTimestamp | Tanggal dan waktu tepat saat aktivitas atau peristiwa tertentu terjadi pada sebuah insiden. | ||
| Deskripsi Stempel Waktu Peristiwa menunjukkan saat tepat suatu aktivitas berlangsung. Setiap aktivitas dalam siklus insiden perlu memiliki stempel waktu agar urutan peristiwa dapat diketahui. Atribut ini penting untuk analisis process mining berbasis waktu. Dengan atribut ini, Anda dapat menghitung waktu siklus antaraktivitas, durasi setiap langkah, dan total waktu penyelesaian insiden. Analisis stempel waktu membantu organisasi menemukan hambatan, mengukur kepatuhan terhadap SLA, dan memahami perubahan kinerja proses dari waktu ke waktu. Atribut ini juga menjadi dasar penghitungan KPI, seperti Rata-rata Waktu Penyelesaian. Mengapa ini penting Atribut ini menunjukkan urutan kronologis peristiwa. Urutan tersebut penting untuk menghitung durasi, menemukan hambatan, dan menganalisis kinerja proses dari waktu ke waktu. Sumber data Tersedia di log peristiwa, tabel riwayat audit, atau sebagai kolom 'terakhir diubah' maupun 'tanggal dibuat' pada catatan terkait. Contoh 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui dari sistem sumber. | ||
| Deskripsi Stempel waktu Pembaruan Data Terakhir menunjukkan kapan data terakhir diekstrak atau disinkronkan dari sistem sumber. Kolom metadata ini menunjukkan seberapa baru data yang dianalisis. Dalam analisis process mining, atribut ini membantu Anda memahami seberapa mutakhir wawasan yang dihasilkan. Anda dapat mengetahui apakah data yang dilihat merupakan informasi terkini atau rekam dari waktu sebelumnya. Konteks ini penting untuk pemantauan operasional dan memastikan keputusan didasarkan pada data yang masih relevan. Mengapa ini penting Atribut ini menunjukkan seberapa baru data, sehingga analis dapat mengetahui kemutakhiran analisis proses. Sumber data Nilai ini biasanya dibuat dan dicatat pada setiap baris selama proses ekstraksi dan transformasi data (ETL). Contoh 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
| Sistem Sumber SourceSystem | Nama atau pengenal sistem tempat data insiden diambil. | ||
| Deskripsi Atribut Sistem Sumber menunjukkan asal data. Jika organisasi menggunakan beberapa alat ITSM atau sistem terintegrasi, kolom ini membantu membedakan catatan dari tiap sumber. Atribut ini tidak digunakan langsung untuk menggambar peta proses, tetapi berguna untuk validasi dan tata kelola data. Analis dapat melacak asal data, memahami kemungkinan perbedaan antar sistem, dan membagi analisis berdasarkan sumber. Misalnya, proses manajemen insiden di ServiceNow dan Jira dapat dibandingkan dalam organisasi yang sama. Mengapa ini penting Atribut ini memberi konteks tentang asal data, yang penting untuk validasi data, pemecahan masalah, dan analisis perbandingan di lingkungan dengan banyak sistem. Sumber data Biasanya berupa nilai tetap yang ditambahkan saat data diekstrak atau kolom yang tersedia di tabel sistem sumber. Contoh ServiceNowJira Service ManagementBMC HelixZendesk | |||
| Agen yang Ditugaskan AssignedAgent | Agen dukungan atau pengguna tertentu yang ditugaskan menangani insiden. | ||
| Deskripsi Agen yang Ditugaskan menunjukkan orang tertentu yang bertanggung jawab atas sebuah insiden. Grup yang Ditugaskan menunjukkan timnya, sedangkan agen adalah orang yang menangani penyelesaian. Atribut ini memungkinkan analisis kinerja dan beban kerja yang lebih terperinci. Dengan melacak penugasan pada tingkat agen, manajer dapat menilai produktivitas individu, menemukan kebutuhan pelatihan, dan memastikan pembagian pekerjaan yang seimbang. Dalam process mining, atribut ini dapat mengungkap pola penugasan ulang yang rumit dan tidak terlihat pada tingkat grup, serta membantu memahami kontribusi tiap orang terhadap waktu penyelesaian. Mengapa ini penting Atribut ini memungkinkan analisis terperinci atas beban kerja, kinerja, dan pola penugasan ulang individu di dalam atau antar tim. Sumber data Kolom ini terdapat pada catatan utama insiden dan diperbarui saat agen mengambil alih tanggung jawab atau ditugaskan menangani insiden. Contoh John SmithJane Doeagent.12345Emily Jones | |||
| Grup yang Ditugaskan AssignedGroup | Tim dukungan, antrean, atau grup yang saat ini bertanggung jawab menangani insiden. | ||
| Deskripsi Grup yang Ditugaskan menunjukkan tim yang bertanggung jawab atas insiden pada waktu tertentu. Insiden sering dialihkan antargrup, seperti Service Desk Level 1, tim Jaringan Level 2, atau tim Dukungan Aplikasi Level 3. Atribut ini penting untuk menganalisis serah terima dan beban kerja. process mining dapat menggunakan data ini untuk memvisualisasikan perpindahan insiden antar tim, mengukur waktu tunggu di antrean setiap tim, dan menemukan hambatan akibat penugasan ulang yang sering. Atribut ini membantu menjawab pertanyaan tentang efisiensi dan kolaborasi tim, serta menjadi dasar bagi dasbor Analisis Serah Terima dan Penugasan Ulang. Mengapa ini penting Atribut ini penting untuk menganalisis serah terima antar tim, mengukur waktu antrean, serta memahami kinerja dan pembagian beban kerja tiap tim. Sumber data Informasi ini biasanya tersimpan pada catatan insiden dan diperbarui setiap kali insiden ditugaskan ke tim baru. Contoh Service DeskOperasional JaringanAdministrasi Basis DataDukungan Aplikasi Tingkat 2 | |||
| Kategori Insiden IncidentCategory | Klasifikasi insiden, yang sering disusun secara hierarkis, misalnya Perangkat keras > Laptop > Baterai. | ||
| Deskripsi Kategori Insiden menyediakan cara terstruktur untuk mengelompokkan insiden berdasarkan jenisnya. Kolom ini biasanya memiliki hierarki yang memungkinkan klasifikasi lebih terperinci, sehingga insiden dapat dikelompokkan secara logis untuk pelaporan dan analisis. Kategorisasi penting untuk analisis akar masalah dan tren. Dengan menganalisis peta proses berdasarkan kategori, organisasi dapat menemukan masalah berulang dan pola yang terkait dengan jenis insiden tertentu. Misalnya, proses penyelesaian insiden 'Perangkat Lunak' mungkin sangat berbeda dari insiden 'Perangkat Keras'. Data ini mendukung KPI seperti Akurasi Kategorisasi Awal dan Tingkat Insiden Berulang. Mengapa ini penting Atribut ini penting untuk analisis akar masalah, menemukan tren insiden berulang, dan memahami cara penanganan berbagai jenis masalah. Sumber data Ini adalah kumpulan kolom standar, yang sering kali wajib diisi pada catatan insiden untuk keperluan klasifikasi. Contoh Perangkat Lunak | Aplikasi | Masalah LoginPerangkat Keras | Printer | Tidak MeresponsJaringan | Wi-Fi | Koneksi Lambat | |||
| Metode Penyelesaian ResolutionMethod | Kode, kategori, atau deskripsi yang menunjukkan cara insiden akhirnya diselesaikan. | ||
| Deskripsi Metode Penyelesaian menjelaskan hasil insiden dan cara penyelesaiannya. Isinya dapat berupa kode standar atau uraian bebas tentang tindakan yang dilakukan. Contohnya, 'Edukasi pengguna', 'Patch perangkat lunak diterapkan', 'Tidak ditemukan kerusakan', atau 'Insiden duplikat'. Atribut ini memberi konteks penting tentang akhir proses. Dalam process mining, analisis insiden berdasarkan metode penyelesaian membantu memahami efektivitas berbagai solusi. Analisis ini dapat menyoroti kasus yang ditutup tanpa perbaikan nyata atau menemukan pola penyelesaian umum untuk kategori insiden tertentu. Pola tersebut dapat digunakan untuk membangun basis pengetahuan dan meningkatkan tingkat penyelesaian pada kontak pertama. Mengapa ini penting Atribut ini memberi gambaran tentang cara masalah diselesaikan. Informasi ini penting untuk menemukan peluang otomatisasi, meningkatkan basis pengetahuan, dan menentukan kebutuhan pelatihan. Sumber data Biasanya diisi oleh agen dukungan saat status insiden diubah menjadi 'Resolved' atau 'Closed'. Contoh Diselesaikan oleh Service DeskTidak Ditemukan KerusakanDuplikatPembaruan Perangkat Lunak Diterapkan | |||
| Prioritas Priority | Tingkat prioritas insiden yang menentukan urgensi dan urutan penyelesaiannya. | ||
| Deskripsi Prioritas membantu menentukan tingkat kepentingan insiden dan kecepatan respons yang diperlukan. Prioritas sering ditentukan berdasarkan dampak dan urgensi insiden. Tingkatannya biasanya berkisar dari kritis hingga rendah. Dalam process mining, analisis insiden berdasarkan prioritas membantu Anda memahami cara proses menangani tingkat urgensi yang berbeda. Analis dapat membandingkan waktu penyelesaian insiden berprioritas tinggi dan rendah untuk melihat apakah SLA terpenuhi dan sumber daya dialokasikan dengan tepat. Analisis ini membantu menjawab pertanyaan seperti, 'Apakah insiden paling kritis benar-benar ditangani paling cepat?' Mengapa ini penting Atribut ini memungkinkan analisis kinerja proses berdasarkan tingkat urgensi, sehingga Anda dapat memeriksa apakah insiden kritis ditangani lebih cepat daripada insiden lainnya. Sumber data Tersedia sebagai kolom standar pada catatan utama insiden. Nilainya dapat ditetapkan secara manual atau dihitung otomatis berdasarkan dampak dan urgensi. Contoh 1 - Kritis2 - Tinggi3 - Sedang4 - Rendah | |||
| Saluran Pelaporan ReportingChannel | Cara atau saluran yang digunakan untuk melaporkan insiden, seperti email, telepon, atau portal layanan mandiri. | ||
| Deskripsi Saluran Pelaporan menunjukkan sumber laporan insiden. Atribut ini mencatat cara pengguna menghubungi tim dukungan, baik melalui kontak langsung seperti telepon maupun secara otomatis melalui peringatan pemantauan sistem. Analisis proses berdasarkan saluran pelaporan dapat menunjukkan perbedaan efisiensi yang penting. Misalnya, insiden yang dilaporkan melalui portal layanan mandiri mungkin lebih cepat diselesaikan karena informasinya sering kali lebih terstruktur sejak awal. Analisis ini membantu organisasi mengoptimalkan saluran dukungan dan mendorong penggunaan cara yang lebih efisien. Mengapa ini penting Atribut ini membantu menganalisis efisiensi dan jalur penyelesaian insiden berdasarkan sumbernya, sehingga dapat menjadi dasar strategi saluran dan alokasi sumber daya. Sumber data Informasi ini biasanya dicatat secara otomatis atau dipilih oleh agen saat insiden dibuat. Contoh EmailTeleponPortal Layanan MandiriPeringatan Sistem | |||
| Status Insiden IncidentStatus | Kondisi insiden saat ini atau pada waktu tertentu dalam siklusnya, seperti 'New', 'In Progress', atau 'Closed'. | ||
| Deskripsi Status Insiden menunjukkan tahap yang dicapai insiden pada waktu tertentu. Status ini memberi gambaran umum tentang posisi insiden dalam proses penyelesaian. Status yang umum antara lain baru, ditugaskan, sedang dikerjakan, tertunda, diselesaikan, dan ditutup. Atribut ini menjadi dasar analisis proses karena perubahan status sering menentukan aktivitas dalam peta proses. Dengan menganalisis waktu yang dihabiskan pada setiap status, Anda dapat menemukan hambatan, misalnya insiden yang terlalu lama berada dalam status 'Pending'. Status ini juga digunakan untuk menghitung jumlah insiden terbuka dan melacak kemajuan penyelesaian. Mengapa ini penting Status ini penting untuk memahami kemajuan insiden dan sering digunakan untuk membentuk aktivitas dalam peta proses. Analisis waktu pada setiap status membantu menemukan keterlambatan. Sumber data Biasanya tersedia sebagai kolom utama pada catatan insiden atau dalam log riwayat insiden. Contoh BaruSedang DikerjakanMenunggu PelangganDiselesaikanDitutup | |||
| Tingkat Keparahan Severity | Ukuran dampak insiden terhadap bisnis, yang menunjukkan seberapa besar pengaruhnya terhadap pengguna atau layanan. | ||
| Deskripsi Tingkat Keparahan menunjukkan besarnya dampak insiden terhadap bisnis. Atribut ini menjawab seberapa serius masalahnya, terlepas dari urgensinya. Misalnya, gangguan pada seluruh sistem termasuk insiden dengan tingkat keparahan tinggi, sedangkan bug kecil pada tampilan termasuk tingkat keparahan rendah. Analisis insiden berdasarkan tingkat keparahan membantu organisasi memahami jenis masalah yang paling mengganggu. process mining dapat menunjukkan apakah insiden dengan tingkat keparahan tinggi mengikuti jalur penyelesaian yang berbeda dan lebih ringkas. Atribut ini penting untuk analisis akar masalah dan menentukan prioritas sumber daya dalam pengelolaan masalah secara proaktif, agar insiden paling serius tidak terulang. Mengapa ini penting Atribut ini membantu mengelompokkan insiden untuk melihat apakah masalah berdampak besar diselesaikan dengan cara berbeda atau lebih efisien daripada masalah berdampak kecil. Sumber data Kolom standar pada catatan insiden, yang sering digunakan bersama urgensi untuk menentukan prioritas. Contoh 1 - Tinggi2 - Sedang3 - RendahKritis | |||
| Jumlah Penugasan Ulang ReassignmentCount | Jumlah total insiden ditugaskan ulang ke agen atau grup lain. | ||
| Deskripsi Jumlah Penugasan Ulang mencatat berapa kali insiden berpindah tangan selama siklusnya. Jumlah yang tinggi sering menunjukkan proses yang tidak efisien, pengalihan awal yang keliru, atau kurangnya pengetahuan di tim dukungan. Atribut ini berguna untuk analisis process mining. process mining dapat memvisualisasikan penugasan ulang, tetapi jumlah yang sudah dihitung memudahkan penyaringan dan pengukuran KPI. Atribut ini digunakan langsung dalam dasbor Analisis Serah Terima dan Penugasan Ulang, serta membantu menemukan kasus 'pingpong' saat tiket bolak-balik antar tim. Akibatnya, waktu penyelesaian bertambah dan pengguna merasa frustrasi. Mengapa ini penting Metrik ini mengukur langsung ketidakefisienan proses. Jumlah yang tinggi sering berkaitan dengan waktu penyelesaian yang lebih lama dan menunjukkan masalah pada pengalihan atau kemampuan tim. Sumber data Sering tersedia sebagai kolom penghitung standar pada catatan insiden. Jika tidak tersedia, jumlahnya dapat dihitung dari perubahan penugasan dalam log audit insiden. Contoh 0135 | |||
| Layanan Terdampak AffectedService | Layanan bisnis, aplikasi, atau item konfigurasi (CI) yang terdampak oleh insiden. | ||
| Deskripsi Layanan Terdampak menghubungkan insiden dengan komponen tertentu dalam infrastruktur TI, seperti aplikasi bisnis, server, atau perangkat jaringan. Informasi ini sering terhubung dengan Basis Data Manajemen Konfigurasi (CMDB). Atribut ini memberi konteks bisnis yang penting untuk insiden. Dalam process mining, atribut ini memungkinkan analisis keandalan layanan atau aset tertentu. Organisasi dapat mengetahui layanan yang paling sering menimbulkan insiden, menganalisis proses penyelesaiannya, dan memprioritaskan pengelolaan masalah untuk meningkatkan kestabilan layanan bisnis yang penting. Atribut ini membantu memahami dampak insiden TI terhadap bisnis secara lebih luas. Mengapa ini penting Atribut ini menghubungkan insiden dengan layanan bisnis atau komponen TI tertentu, sehingga Anda dapat menganalisis layanan yang paling sering mengalami masalah dan dampaknya. Sumber data Biasanya ditautkan dari Basis Data Manajemen Konfigurasi (CMDB) atau dipilih dari daftar katalog layanan pada formulir insiden. Contoh Layanan EmailKeuangan SAP ERPVPN PerusahaanSRV-SQL-01 | |||
| Pelapor Requester | Pengguna, karyawan, atau sistem yang pertama kali melaporkan insiden. | ||
| Deskripsi Pelapor adalah orang yang mengalami masalah dan memulai laporan insiden. Pelapor dapat berupa karyawan internal atau pelanggan eksternal. Atribut ini juga dapat mencatat departemen atau organisasi pelapor. Analisis insiden berdasarkan pelapor atau departemennya membantu menemukan kelompok pengguna yang mengalami lebih banyak masalah. Hal ini dapat menunjukkan kebutuhan pelatihan atau masalah lingkungan di lokasi tertentu. Dalam process mining, atribut ini memberikan sudut pandang yang berfokus pada pengguna untuk memahami pengalaman berbagai kelompok pengguna dalam proses dukungan. Mengapa ini penting Atribut ini memungkinkan analisis yang berfokus pada pengguna, sehingga Anda dapat mengetahui apakah pengguna, departemen, atau lokasi tertentu melaporkan insiden dalam jumlah yang jauh lebih banyak. Sumber data Kolom standar pada catatan insiden, biasanya diisi dengan nama pengguna yang membuat tiket atau yang diwakilinya. Contoh Alice JohnsonDepartemen Penjualanb.williamsCustomer-XYZ Corp | |||
| Status SLA SlaStatus | Menunjukkan apakah insiden memenuhi target service level agreement (SLA), berisiko tidak tercapai, atau telah melampauinya. | ||
| Deskripsi Status SLA menunjukkan kinerja insiden dibandingkan dengan target waktu yang telah ditetapkan, seperti waktu respons atau waktu penyelesaian. Status yang umum antara lain 'Sedang Diproses', 'Berisiko', atau 'Terlampaui'. Atribut ini mengukur kualitas layanan secara langsung dan menjadi masukan penting untuk dashboard Ringkasan Kinerja SLA. Dalam process mining, atribut ini membantu membandingkan alur proses insiden yang melampaui SLA dengan yang tidak. Perbandingan ini membantu menemukan aktivitas, keterlambatan, atau siklus pengerjaan ulang yang paling sering menyebabkan kegagalan SLA, sehingga perbaikan proses dapat diarahkan ke titik yang tepat. Mengapa ini penting Atribut ini mengukur kinerja terhadap target secara langsung. Analisis insiden yang melampaui SLA membantu menemukan kegagalan proses yang menurunkan kualitas layanan. Sumber data Biasanya, kolom ini dihitung di dalam alat ITSM dan diperbarui secara dinamis berdasarkan prioritas serta usia insiden, dan aturan SLA yang ditetapkan. Contoh Sedang DikerjakanDijedaTerlampauiBerisiko | |||
Aktivitas Pengelolaan Insiden
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Grup ditetapkan | Menandai penetapan awal insiden kepada grup atau tim dukungan tertentu untuk diselidiki. Ini adalah serah terima resmi pertama dan awal alur kerja penyelesaian. | ||
| Mengapa ini penting Ini adalah tahap penting dalam pengarahan insiden. Keterlambatan penetapan atau pengarahan yang keliru dapat memperpanjang waktu penyelesaian dan menyebabkan serah terima yang tidak perlu antar tim. Sumber data Peristiwa ini disimpulkan dari log audit dengan mencari entri pertama saat kolom 'Assignment Group' atau 'Support Team' diisi. Pengumpulan data Temukan stempel waktu saat kolom 'Assignment Group' pertama kali diisi dalam riwayat insiden. Jenis peristiwa inferred | |||
| Insiden dibuat | Aktivitas ini menandai pembuatan resmi catatan insiden di sistem. Inilah awal siklus insiden, saat laporan awal dari pengguna atau alat pemantauan dicatat. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam proses. Menganalisis waktu dari pembuatan insiden hingga pencapaian tahap lain penting untuk mengukur waktu penyelesaian secara keseluruhan dan menemukan keterlambatan di tahap awal. Sumber data Biasanya, peristiwa ini diambil dari stempel waktu pembuatan pada tabel insiden atau tiket utama di sistem sumber. Pengumpulan data Gunakan stempel waktu 'create_date' atau 'submitted_on' dari catatan insiden utama. Jenis peristiwa explicit | |||
| Insiden Dibuka Kembali | Terjadi saat insiden yang sebelumnya telah diselesaikan kembali ke status aktif. Biasanya, pengguna melaporkan bahwa masalah muncul lagi atau solusi yang diberikan tidak efektif. | ||
| Mengapa ini penting Tingkat pembukaan kembali yang tinggi menunjukkan masalah pada kualitas penyelesaian, analisis akar masalah yang belum tuntas, atau penutupan yang terlalu dini. Ini metrik penting untuk menganalisis pekerjaan ulang. Sumber data Disimpulkan dari riwayat status saat status insiden berubah dari 'Resolved' atau 'Closed' kembali ke status aktif, seperti 'In Progress'. Pengumpulan data Deteksi perubahan status dari status selesai ke status terbuka, lalu catat stempel waktu perubahan tersebut. Jenis peristiwa inferred | |||
| Insiden Diselesaikan | Aktivitas ini menandakan bahwa solusi telah diterapkan dan layanan diperkirakan sudah pulih bagi pengguna. Ini merupakan tonggak penting yang biasanya menghentikan penghitungan waktu penyelesaian SLA. | ||
| Mengapa ini penting Ini menjadi titik akhir utama untuk mengukur waktu penyelesaian. Jeda antara tahap ini dan penutupan akhir penting untuk menganalisis keterlambatan konfirmasi pengguna atau kebijakan penutupan otomatis. Sumber data Peristiwa ini hampir selalu tercatat secara eksplisit saat agen mengubah status insiden menjadi 'Resolved' atau 'Solved'. Pengumpulan data Gunakan stempel waktu dari log audit saat status insiden diperbarui menjadi 'Resolved'. Jenis peristiwa explicit | |||
| Insiden Ditutup | Aktivitas terakhir dalam siklus insiden. Pada tahap ini, catatan insiden resmi ditutup dan menjadi arsip historis yang hanya dapat dibaca. Penutupan sering terjadi secara otomatis setelah insiden berada dalam status 'Resolved' selama jangka waktu tertentu. | ||
| Mengapa ini penting Tahap ini menandai akhir siklus insiden. Dengan menganalisis waktu sejak insiden dibuat hingga ditutup, Anda dapat melihat durasi proses secara menyeluruh, termasuk masa administrasi setelah penyelesaian. Sumber data Diambil dari perubahan status eksplisit menjadi 'Closed' dalam log riwayat insiden, yang mencatat stempel waktu akhir. Pengumpulan data Gunakan stempel waktu dari log audit saat status insiden diperbarui menjadi 'Closed'. Jenis peristiwa explicit | |||
| Pelanggaran SLA terdeteksi | Peristiwa hasil perhitungan yang terjadi saat waktu respons atau penyelesaian insiden melampaui target dalam Service Level Agreement (SLA). Peristiwa ini bukan tindakan manual pengguna, melainkan terjadi karena waktu yang berlalu. | ||
| Mengapa ini penting Pelanggaran SLA merupakan KPI utama. Menganalisis kapan dan mengapa pelanggaran terjadi sangat penting untuk meningkatkan layanan dan memenuhi kewajiban kontrak. Sumber data Peristiwa ini tidak tercatat langsung di log, tetapi dihitung dengan membandingkan stempel waktu peristiwa dengan tenggat target SLA yang tersimpan pada catatan insiden. Pengumpulan data Bandingkan stempel waktu penyelesaian dengan 'Tanggal Jatuh Tempo SLA'. Jika penyelesaian terjadi setelah tanggal tersebut, catat peristiwa pelanggaran pada stempel waktu tenggat SLA. Jenis peristiwa calculated | |||
| Penyelidikan dimulai | Menunjukkan bahwa agen yang ditugaskan mulai menangani insiden secara aktif. Biasanya, status berubah dari 'Assigned' atau 'New' menjadi 'In Progress'. | ||
| Mengapa ini penting Tahap ini menandai berakhirnya waktu tunggu awal dan dimulainya pekerjaan aktif. Mengukur waktu hingga aktivitas ini membantu memahami kapasitas agen dan keterlambatan respons. Sumber data Biasanya, peristiwa ini disimpulkan dari perubahan status dalam log riwayat insiden. Pengumpulan data Temukan stempel waktu saat status insiden pertama kali berubah menjadi 'In Progress', 'Work in Progress', atau status aktif serupa. Jenis peristiwa inferred | |||
| Agen ditetapkan | Aktivitas ini menandai saat agen tertentu mengambil alih atau diberi tanggung jawab atas insiden. Tanggung jawab beralih dari tingkat tim ke individu. | ||
| Mengapa ini penting Melacak penetapan agen membantu menganalisis beban kerja dan kinerja individu, serta menemukan hambatan saat insiden menunggu agen yang tersedia. Sumber data Dicatat dengan melacak perubahan pada kolom 'Assignee' atau 'Assigned To' di log audit insiden. Pengumpulan data Gunakan stempel waktu dari log audit saat kolom 'Assignee' pertama kali diisi atau diubah ke pengguna baru. Jenis peristiwa explicit | |||
| Insiden dialihkan | Menunjukkan pemindahan insiden dari satu grup dukungan atau agen ke grup atau agen lain. Serah terima ini biasanya terjadi saat tim awal tidak dapat menyelesaikan masalah dan diperlukan keahlian berbeda. | ||
| Mengapa ini penting Pengalihan yang sering menjadi tanda kuat adanya proses yang tidak efisien, pengarahan awal yang keliru, atau kesenjangan pengetahuan dalam tim. Menganalisis serah terima ini penting untuk memperlancar proses penyelesaian. Sumber data Disimpulkan dari log audit dengan mendeteksi perubahan pada kolom 'Assignment Group' atau 'Assignee' setelah penetapan awal. Pengumpulan data Catat peristiwa baru setiap kali kolom 'Assignment Group' berubah setelah pertama kali diisi. Jenis peristiwa inferred | |||
| Insiden dikategorikan | Menunjukkan klasifikasi insiden, termasuk penetapan kategori, jenis, dan item. Ini adalah tahap triase penting untuk mengarahkan insiden dan menentukan prosedur penyelesaian yang tepat. | ||
| Mengapa ini penting Kategorisasi yang keliru dapat menyebabkan keterlambatan, pengalihan, dan laporan yang tidak akurat. Analisis aktivitas ini membantu menilai kualitas triase awal dan dampaknya terhadap efisiensi penyelesaian. Sumber data Peristiwa ini biasanya disimpulkan dari log audit atau tabel riwayat dengan mencari waktu pertama kali kolom terkait kategorisasi diisi. Pengumpulan data Temukan pembaruan pertama pada kolom seperti 'Category', 'Subcategory', atau 'Configuration Item' setelah insiden dibuat. Jenis peristiwa inferred | |||
| Pekerjaan dilanjutkan | Menandai saat insiden yang ditangguhkan kembali ditangani. Ini biasanya terjadi setelah informasi yang diperlukan diterima, sehingga agen dukungan dapat melanjutkan pekerjaan. | ||
| Mengapa ini penting Aktivitas ini penting untuk mengukur durasi waktu tunggu eksternal secara akurat. Jeda antara 'Pending' dan 'Resumed' menunjukkan berapa lama proses terhenti karena faktor di luar tim. Sumber data Disimpulkan dari riwayat status insiden saat status berubah dari 'Pending' kembali menjadi 'In Progress' atau status aktif lainnya. Pengumpulan data Catat stempel waktu saat status insiden berubah dari status 'pending' kembali ke status aktif. Jenis peristiwa inferred | |||
| Prioritas insiden ditetapkan | Aktivitas ini terjadi saat prioritas insiden ditetapkan, biasanya berdasarkan dampak dan urgensinya. Tingkat prioritas menentukan target waktu respons dan penyelesaian sesuai Service Level Agreement (SLA). | ||
| Mengapa ini penting Prioritas secara langsung memengaruhi alokasi sumber daya dan urutan penanganan insiden. Analisis tahap ini membantu memastikan insiden kritis ditangani lebih dahulu dan SLA terpenuhi. Sumber data Peristiwa ini dicatat dengan memantau jejak audit untuk melihat perubahan pada kolom 'Priority' atau 'Severity'. Pengumpulan data Gunakan stempel waktu dari log audit yang terkait dengan pembaruan kolom 'Priority'. Jenis peristiwa explicit | |||
| Solusi sementara diberikan | Menandakan bahwa solusi sementara telah disampaikan kepada pengguna untuk memulihkan fungsi layanan. Solusi ini mengurangi dampak terhadap bisnis sambil menyiapkan perbaikan permanen. | ||
| Mengapa ini penting Memberikan solusi sementara merupakan langkah penting dalam menangani insiden besar. Dengan mencatatnya, Anda dapat mengukur waktu hingga dampak insiden teratasi secara terpisah dari waktu hingga perbaikan permanen selesai. Sumber data Peristiwa ini dapat dicatat melalui status atau penanda khusus. Namun, biasanya peristiwa disimpulkan dari catatan agen atau log komunikasi dengan menganalisis kata kunci. Pengumpulan data Temukan peristiwa ini melalui status khusus seperti 'Workaround Provided' atau dengan mencari kata kunci seperti 'workaround' atau 'temporary fix' dalam komentar agen. Jenis peristiwa inferred | |||
| Status berubah menjadi menunggu | Terjadi saat penanganan insiden dihentikan sementara, biasanya sambil menunggu informasi dari pengguna, vendor, atau pihak eksternal lainnya. Dalam status ini, jam SLA biasanya dihentikan sementara. | ||
| Mengapa ini penting Menganalisis waktu dalam status menunggu membantu menemukan ketergantungan pada pihak eksternal dan sumber keterlambatan. Waktu tunggu yang terlalu lama dapat menyamarkan ketidakefisienan internal dan membuat metrik waktu penyelesaian tidak akurat. Sumber data Disimpulkan dari riwayat status insiden saat status berubah menjadi 'Pending', 'On Hold', atau 'Awaiting User'. Pengumpulan data Catat stempel waktu setiap kali status insiden berubah menjadi status 'pending' yang telah ditentukan. Jenis peristiwa inferred | |||
Panduan Ekstraksi
Metode ekstraksi berbeda-beda untuk setiap sistem. Untuk petunjuk lengkap,
baca panduan ETL kami atau pilih proses dan sistem tertentu.
Siap Memulai?
Mulai tingkatkan proses pengelolaan insiden Anda hari ini. Pilih panduan ekstraksi khusus sistem di bawah ini, atau gunakan templat umum ini untuk mulai membuat log peristiwa dan menganalisis proses.
Selesaikan Insiden Lebih Cepat, Mulai Perubahan Sekarang
Temukan hambatan, kurangi waktu henti, dan tingkatkan efisiensi tim.
Tidak perlu kartu kredit, penyiapan hanya 5 menit