Templat Data Pengelolaan Permintaan Layanan

BMC Helix ITSM
Templat Data Pengelolaan Permintaan Layanan

Templat Data Pengelolaan Permintaan Layanan

Templat ini merangkum atribut data penting yang perlu dikumpulkan dan aktivitas utama yang perlu dilacak dalam proses pengelolaan permintaan layanan. Templat ini juga memuat panduan praktis untuk mengekstrak data dari BMC Helix ITSM secara efisien. Gunakan sumber daya ini untuk menyederhanakan persiapan data dan memulai inisiatif process mining dengan yakin.
  • Atribut yang disarankan untuk dikumpulkan
  • Aktivitas utama yang perlu dilacak
  • Panduan ekstraksi data dari BMC Helix ITSM
Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Atribut Pengelolaan Permintaan Layanan

Kolom data ini penting untuk membuat log peristiwa yang lengkap dan menganalisis proses pengelolaan permintaan layanan secara mendalam.
5 Wajib 6 Disarankan 9 Opsional
Nama Deskripsi
Aktivitas
ActivityName
Nama peristiwa atau tugas tertentu yang terjadi pada suatu waktu dalam siklus permintaan layanan.
Deskripsi

Atribut ini menjelaskan langkah atau perubahan status tertentu dalam proses permintaan layanan, seperti 'Permintaan sedang ditinjau', 'Pemenuhan sedang berlangsung', atau 'Permintaan layanan diselesaikan'. Setiap aktivitas mewakili satu peristiwa dalam perjalanan permintaan layanan dari awal hingga akhir.

Menganalisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu menemukan peta proses, mengidentifikasi hambatan, dan menelaah variasi proses. Memahami aktivitas yang terjadi, urutannya, dan frekuensinya sangat penting untuk memperbaiki proses.

Mengapa ini penting

Aktivitas membentuk bagian-bagian utama dalam peta proses. Dengan melacaknya, Anda dapat memvisualisasikan dan menganalisis alur proses serta melihat bagaimana pekerjaan benar-benar dilakukan.

Sumber data

Biasanya, data ini diperoleh dari perubahan kolom 'Status' dan 'Status Reason' pada formulir 'SRM:Request' atau log aplikasi pemenuhan terkait (misalnya, Incident atau Work Order).

Contoh
Permintaan menunggu persetujuanPemenuhan sedang berlangsungPermintaan layanan diselesaikanPermintaan layanan ditutup
ID Permintaan Layanan
ServiceRequestId
Pengenal unik untuk setiap permintaan layanan, yang menjadi kunci utama untuk melacak seluruh siklusnya.
Deskripsi

ID Permintaan Layanan mengidentifikasi setiap permintaan layanan yang diajukan oleh pengguna atau sistem secara unik. ID ini menjadi penghubung utama bagi semua peristiwa berikutnya, mulai dari pencatatan awal hingga penutupan akhir. Dengan begitu, perjalanan setiap permintaan layanan dapat dianalisis secara menyeluruh.

Dalam process mining, ID ini penting untuk menyusun kembali urutan aktivitas setiap kasus. Alat dapat mengelompokkan semua peristiwa terkait, seperti 'Permintaan diajukan', 'Permintaan ditugaskan', dan 'Permintaan layanan ditutup', ke dalam satu instans proses. Pengelompokan ini menjadi dasar analisis proses.

Mengapa ini penting

Ini adalah pengenal utama kasus. Tanpanya, perjalanan permintaan layanan dari awal hingga akhir tidak dapat dilacak, sehingga penemuan dan analisis proses tidak mungkin dilakukan.

Sumber data

Biasanya, ini adalah kolom 'InstanceId' atau 'Request Number' pada formulir 'SRM:Request' di BMC Helix ITSM.

Contoh
SR000010572931SR000010572932SR000010572933
Waktu mulai
EventStartTime
Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu dimulai.
Deskripsi

Atribut ini mencatat tanggal dan waktu yang tepat saat aktivitas dimulai. Setiap peristiwa dalam log, mulai dari pengajuan awal hingga penutupan akhir, harus memiliki waktu mulai agar urutan proses dapat diketahui.

Stempel waktu ini penting untuk semua analisis process mining berbasis waktu. Data ini digunakan untuk menghitung waktu siklus, durasi aktivitas, waktu tunggu antar langkah, dan kepatuhan SLA. Data ini juga membantu menemukan hambatan dan menganalisis kinerja proses dari waktu ke waktu.

Mengapa ini penting

Waktu mulai menunjukkan urutan kronologis peristiwa. Informasi ini penting untuk menghitung durasi proses, menemukan keterlambatan, dan memahami lini masa proses.

Sumber data

Data ini sesuai dengan kolom stempel waktu di log audit atau tabel riwayat status yang terkait dengan formulir 'SRM:Request', seperti 'Submit Date' untuk peristiwa awal.

Contoh
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Pembaruan data terakhir
LastDataUpdate
Stempel waktu saat data proses terakhir kali diperbarui dari sistem sumber.
Deskripsi

Atribut ini menunjukkan tanggal dan waktu ekstraksi data terbaru dari BMC Helix ITSM. Informasi ini memberi konteks tentang kebaruan data yang sedang dianalisis dan periode yang tercakup dalam analisis.

Metadata ini penting untuk setiap dasbor atau analisis process mining. Pengguna dapat mengetahui apakah insight didasarkan pada data yang hampir real-time atau rekam data historis. Hal ini memengaruhi validitas dan relevansi kesimpulan.

Mengapa ini penting

Informasi ini memberi tahu pengguna seberapa baru data yang tersedia. Hal ini penting saat mengambil keputusan berdasarkan informasi kinerja proses terkini.

Sumber data

Stempel waktu ini dibuat dan ditambahkan selama proses ekstraksi dan pemuatan data.

Contoh
2024-05-21T08:00:00Z
Sistem sumber
SourceSystem
Mengidentifikasi sistem tempat data diekstrak.
Deskripsi

Atribut ini menunjukkan asal data proses. Untuk tampilan ini, nilainya ditetapkan secara tetap menjadi 'BMC Helix ITSM' untuk menunjukkan bahwa semua peristiwa terkait permintaan layanan berasal dari sistem tersebut.

Di lingkungan dengan beberapa sistem terintegrasi, kolom ini penting untuk memahami asal-usul data dan membaginya berdasarkan sumber. Kolom ini memastikan data tetap jelas dan dapat ditelusuri, terutama saat menggabungkan data dari berbagai platform.

Mengapa ini penting

Atribut ini memberikan konteks tentang asal data, yang penting untuk tata kelola data, penelusuran, dan pemecahan masalah di lingkungan dengan banyak sistem.

Sumber data

Nilai tetap ini ditambahkan saat proses ekstraksi dan transformasi data, bukan berasal dari kolom di BMC Helix ITSM.

Contoh
BMC Helix ITSM
Jenis layanan
ServiceType
Kategori atau jenis layanan yang diminta pengguna.
Deskripsi

Jenis layanan mengelompokkan permintaan berdasarkan kebutuhannya, misalnya 'Permintaan perangkat lunak baru', 'Atur ulang kata sandi', atau 'Orientasi karyawan baru'. Atribut ini menjadi dimensi utama untuk memfilter dan mengelompokkan data proses.

Dalam analisis proses, atribut ini digunakan untuk membandingkan kinerja berbagai jenis permintaan. Anda dapat menjawab pertanyaan seperti, 'Jenis layanan apa yang paling lama diselesaikan?' atau 'Jenis layanan apa yang paling sering dikerjakan ulang?' Data ini penting untuk dasbor Waktu Penyelesaian dan Kepatuhan SLA.

Mengapa ini penting

Atribut ini membantu mengelompokkan permintaan layanan untuk membandingkan alur proses, menemukan masalah khusus pada jenis tertentu, dan menentukan perbaikan yang sesuai.

Sumber data

Data ini sering ditemukan di kolom 'Title' atau kolom kategorisasi pada formulir 'SRM:Request', berdasarkan layanan yang dipilih dari katalog.

Contoh
Permintaan perangkat keras baruPermintaan akses perangkat lunakPenyiapan akses VPN
Petugas yang ditugaskan
AssignedAgent
Pengguna yang saat ini ditugaskan untuk menangani permintaan layanan.
Deskripsi

Atribut ini mengidentifikasi petugas IT atau staf dukungan yang bertanggung jawab atas permintaan pada waktu tertentu. Perubahan nilai selama siklus permintaan menunjukkan adanya serah terima atau penugasan ulang.

Atribut ini penting untuk menganalisis kinerja petugas dan beban kerja. Anda dapat melacak jumlah permintaan yang ditangani setiap petugas, rata-rata waktu penyelesaian, dan frekuensi penugasan ulang. Data ini mendukung pengelolaan sumber daya dan membantu menemukan kebutuhan pelatihan.

Mengapa ini penting

Melacak petugas yang ditugaskan penting untuk menganalisis serah terima, mengukur kinerja individu, dan memahami pembagian beban kerja di seluruh tim dukungan.

Sumber data

Data ini sesuai dengan kolom 'Assignee' atau 'Assigned To' pada catatan pemenuhan (misalnya, Work Order atau Incident) yang terkait dengan permintaan layanan.

Contoh
Bob SmithAlice JohnsonCharlie Brown
Prioritas
Priority
Tingkat prioritas permintaan layanan yang menunjukkan dampak dan urgensinya bagi bisnis.
Deskripsi

Prioritas menentukan urutan dan kecepatan penanganan permintaan. Nilai yang umum digunakan antara lain 'Kritis', 'Tinggi', 'Sedang', dan 'Rendah'. Penetapan prioritas biasanya mempertimbangkan dampak permintaan terhadap bisnis dan tingkat urgensinya.

Analisis berdasarkan prioritas penting untuk menilai apakah permintaan berprioritas tinggi diproses lebih cepat daripada permintaan berprioritas rendah. Prioritas menjadi dimensi utama dalam dasbor waktu penyelesaian dan kepatuhan SLA. Data ini membantu memastikan sumber daya dialokasikan sesuai kebutuhan bisnis yang paling mendesak.

Mengapa ini penting

Atribut ini membantu menilai apakah proses sudah memprioritaskan pekerjaan dengan tepat dan memenuhi tingkat layanan yang diharapkan untuk permintaan dengan dampak bisnis yang berbeda.

Sumber data

Ini adalah kolom 'Priority' pada formulir 'SRM:Request'.

Contoh
KritisTinggiSedangRendah
Status permintaan
RequestStatus
Status permintaan layanan saat peristiwa terjadi, seperti 'In Progress', 'Pending', atau 'Closed'.
Deskripsi

Atribut ini mencatat status permintaan layanan pada berbagai tahap siklusnya. Status memberikan konteks untuk setiap aktivitas dan sering menjadi sumber untuk menentukan nilai atribut 'Aktivitas'.

Analisis berdasarkan status membantu Anda memahami berapa lama permintaan berada dalam status tertentu, seperti 'Pending Customer' atau 'Waiting for Approval'. Informasi ini penting untuk menemukan hambatan dan keterlambatan akibat ketergantungan eksternal atau antrean internal. Data ini mendukung dasbor Identifikasi Hambatan.

Mengapa ini penting

Atribut ini memberikan gambaran status permintaan, sehingga Anda dapat menganalisis waktu dalam status menunggu dibandingkan dengan status aktif. Informasi ini penting untuk menemukan hambatan.

Sumber data

Ini adalah kolom 'Status' pada formulir 'SRM:Request'. Nilai historisnya dapat ditemukan di log audit.

Contoh
PerencanaanSedang berlangsungTertundaDiselesaikanDitutup
Tim yang ditugaskan
AssignedTeam
Grup atau tim dukungan yang saat ini ditugaskan untuk menangani permintaan layanan.
Deskripsi

Atribut ini menunjukkan kelompok fungsi yang bertanggung jawab menangani permintaan, seperti 'Help Desk', 'Tim Jaringan', atau 'Administrasi Database'. Perubahan pada kolom ini menandakan perpindahan tanggung jawab antar tim.

Analisis berdasarkan tim yang ditugaskan membantu menemukan hambatan di tingkat tim, menganalisis serah terima antar tim, dan menilai efisiensi berbagai kelompok dukungan. Atribut ini penting untuk dasbor Analisis Pengerjaan Ulang dan Pengalihan Permintaan serta Efisiensi Triage. Dari sini, Anda dapat melihat pola penyaluran pekerjaan di seluruh organisasi.

Mengapa ini penting

Atribut ini membantu menganalisis alur proses antar kelompok fungsi, menemukan penyaluran yang tidak efisien, dan mengukur kinerja tiap tim.

Sumber data

Atribut ini sesuai dengan kolom 'Assigned Group' pada catatan pemenuhan, seperti Work Order atau Incident, yang terkait dengan permintaan layanan.

Contoh
Meja layananDukungan InfrastrukturDukungan Aplikasi Tingkat 2
Waktu selesai
EventEndTime
Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu selesai.
Deskripsi

Waktu selesai menandai berakhirnya suatu aktivitas. Banyak aktivitas dalam sistem ITSM berupa perubahan status yang terjadi seketika, tetapi sebagian aktivitas memiliki durasi yang dapat diukur. Waktu selesai memungkinkan durasi aktivitas tersebut dihitung dengan tepat.

Dalam analisis, waktu selesai digunakan bersama waktu mulai untuk menghitung waktu pemrosesan setiap aktivitas. Dengan begitu, Anda dapat mengetahui tugas tertentu yang paling banyak menyita waktu, bukan hanya waktu tunggu di antaranya.

Mengapa ini penting

Data ini memungkinkan penghitungan waktu pemrosesan aktivitas. Informasi tersebut penting untuk menemukan langkah yang tidak efisien dan memahami penggunaan waktu oleh sumber daya.

Sumber data

Nilai ini dapat diperoleh dari data yang ada. Waktu selesai suatu aktivitas sering kali sama dengan waktu mulai aktivitas berikutnya dalam kasus yang sama. Untuk aktivitas terakhir, nilainya dapat menggunakan stempel waktu penyelesaian atau penutupan.

Contoh
2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
Departemen Pemohon
RequestorDepartment
Departemen atau unit bisnis pengguna yang mengajukan permintaan.
Deskripsi

Atribut ini menunjukkan departemen organisasi dari orang yang meminta layanan, seperti 'Keuangan', 'Sumber Daya Manusia', atau 'TI'. Informasi ini biasanya diambil dari profil pengguna di sistem.

Dengan mengelompokkan analisis proses berdasarkan departemen, Anda dapat mengetahui kebutuhan dan pola permintaan tiap departemen, serta menemukan peluang untuk pelatihan atau perbaikan layanan yang lebih terarah. Anda juga dapat menjawab pertanyaan seperti, 'Apakah departemen Keuangan mengalami waktu tunggu yang lebih lama untuk permintaannya?'.

Mengapa ini penting

Atribut ini memungkinkan analisis penggunaan layanan dan kinerja proses berdasarkan unit bisnis, sehingga masalah atau tren khusus di tiap departemen dapat terlihat.

Sumber data

Informasi ini biasanya diambil dari profil pengguna yang tercantum pada pengguna 'Requested For' di formulir 'SRM:Request'.

Contoh
KeuanganPenjualanSumber Daya ManusiaTeknologi Informasi
Jumlah Serah Terima
HandoffCount
Jumlah total pengalihan permintaan layanan antar agen atau tim.
Deskripsi

Metrik hasil perhitungan ini menghitung berapa kali 'AssignedAgent' atau 'AssignedTeam' berubah untuk satu permintaan layanan. Jumlah serah terima yang tinggi dapat menandakan proses yang terpecah-pecah, rendahnya penyelesaian pada kontak pertama, atau penyaluran yang tidak efisien.

Atribut ini menjadi dasar KPI Rata-Rata Serah Terima Agen per Permintaan dan digunakan dalam dasbor Pengerjaan Ulang dan Pengalihan Permintaan. Analisis kasus dengan jumlah serah terima tinggi dapat mengungkap peluang untuk memperbaiki triage, memberikan pelatihan yang lebih baik, atau menyederhanakan proses penyelesaian agar keterlambatan berkurang dan kepuasan pelanggan meningkat.

Mengapa ini penting

Atribut ini mengukur fragmentasi proses dan beban komunikasi. Jumlah serah terima yang tinggi sering berkaitan dengan waktu penyelesaian yang lebih lama dan efisiensi proses yang lebih rendah.

Sumber data

Metrik ini dihitung dengan menghitung jumlah nilai berbeda pada atribut 'AssignedAgent' atau 'AssignedTeam' untuk setiap ID Permintaan Layanan yang unik.

Contoh
0135
Kanal Pengajuan
SubmissionChannel
Metode atau kanal yang digunakan untuk mengajukan permintaan layanan.
Deskripsi

Atribut ini mencatat cara permintaan layanan diajukan, misalnya melalui portal layanan mandiri, email, panggilan telepon ke service desk, atau peringatan sistem otomatis. Kanal yang berbeda dapat menghasilkan variasi proses dan waktu penyelesaian yang berbeda.

Analisis proses berdasarkan kanal pengajuan dapat mengungkap ketidakefisienan atau praktik yang baik pada metode penerimaan tertentu. Misalnya, permintaan melalui portal layanan mandiri mungkin lebih cepat diselesaikan karena data awalnya lebih lengkap, sedangkan permintaan melalui email mungkin memerlukan triage manual lebih lanjut.

Mengapa ini penting

Atribut ini membantu Anda memahami pengaruh metode penerimaan terhadap efisiensi proses, kualitas data, dan waktu siklus secara keseluruhan. Dengan begitu, Anda dapat melakukan perbaikan yang tepat pada kanal tertentu.

Sumber data

Informasi ini sering kali dapat diketahui dari kolom seperti 'Client Type' atau 'Reported Source' pada formulir 'SRM:Request' atau tiket pemenuhan terkait.

Contoh
Portal layanan mandiriEmailTeleponDibuat oleh Sistem
Kategori Penyelesaian
ResolutionCategory
Pengelompokan solusi yang diberikan untuk menyelesaikan permintaan.
Deskripsi

Atribut ini mengelompokkan cara permintaan diselesaikan secara terstruktur, seperti 'Perbaikan Perangkat Lunak', 'Pelatihan Pengguna', atau 'Koreksi Data'. Atribut ini menjelaskan jenis penyelesaian secara lebih rinci daripada kode penutupan biasa.

Atribut ini penting untuk dasbor Akurasi Kategori Penyelesaian. Anda dapat membandingkannya dengan jenis layanan awal untuk memeriksa konsistensi. Analisis kategori penyelesaian membantu menemukan tren masalah dan mendukung penanganan masalah secara proaktif, misalnya ketika banyak permintaan diselesaikan melalui pelatihan pengguna.

Mengapa ini penting

Atribut ini memberi gambaran tentang jenis solusi yang diberikan. Anda dapat menggunakannya untuk menemukan tren masalah berulang dan peluang penanganan masalah secara proaktif atau pelatihan pengguna.

Sumber data

Informasi ini termasuk dalam kolom pengelompokan operasional dan produk pada tiket pemenuhan, yang sering diberi label 'Resolution Category'.

Contoh
Administrasi AkunKerusakan Perangkat KerasPembaruan Perangkat LunakInformasi diberikan
Kode Penutupan
CloseCode
Kode yang menunjukkan hasil akhir atau alasan permintaan layanan ditutup.
Deskripsi

Kode Penutupan menyediakan cara standar untuk mengelompokkan penyelesaian permintaan layanan. Contohnya termasuk 'Diselesaikan oleh Service Desk', 'Dibatalkan oleh Pengguna', atau 'Permintaan Duplikat'.

Analisis kode penutupan membantu Anda memahami hasil permintaan yang umum terjadi. Kode ini dapat menyoroti masalah, seperti banyaknya permintaan yang dibatalkan pengguna, yang mungkin menandakan proses terlalu lama, atau banyaknya permintaan duplikat, yang bisa menunjukkan masalah sistem atau komunikasi. Atribut ini mendukung dasbor Akurasi Kategori Penyelesaian.

Mengapa ini penting

Atribut ini menyediakan data terstruktur tentang hasil permintaan, sehingga Anda dapat menganalisis efektivitas penyelesaian serta alasan permintaan tidak selesai atau dibatalkan.

Sumber data

Informasi ini biasanya terdapat pada kolom 'Resolution' atau 'Closure Code' di tiket pemenuhan yang terkait dengan permintaan layanan.

Contoh
BerhasilDibatalkan oleh PenggunaTidak Lagi DiperlukanPenyelesaian Otomatis
Mengalami Eskalasi
IsEscalated
Penanda boolean yang menunjukkan apakah permintaan layanan telah dieskalasikan.
Deskripsi

Penanda ini bernilai true jika permintaan layanan mengalami eskalasi fungsional atau hierarkis. Eskalasi biasanya terjadi ketika permintaan tidak berjalan sesuai harapan, berisiko melewati batas SLA, atau memerlukan persetujuan maupun tindakan dari pihak yang lebih berwenang.

Atribut ini penting untuk dasbor Analisis Efisiensi Eskalasi Permintaan. Anda dapat memfilter dan menganalisis jalur proses permintaan yang dieskalasikan untuk memahami pemicunya, waktu penyelesaian setelah eskalasi, dan efektivitas proses eskalasi.

Mengapa ini penting

Atribut ini membantu memisahkan dan menganalisis permintaan yang memerlukan eskalasi. Dengan begitu, Anda dapat menemukan kelemahan dalam proses standar atau pemicu masalah yang kompleks.

Sumber data

Informasi ini biasanya tidak tersedia dalam satu kolom. Nilainya diturunkan dengan memeriksa aktivitas terkait eskalasi di log audit atau perubahan prioritas maupun penugasan yang mengikuti protokol eskalasi.

Contoh
truefalse
Pengerjaan Ulang
IsRework
Penanda boolean yang menunjukkan apakah permintaan layanan mengalami pengerjaan ulang, misalnya kembali ke tahap sebelumnya.
Deskripsi

Penanda ini menunjukkan permintaan layanan yang mengalami pengulangan atau pengerjaan ulang dalam alur proses. Misalnya, permintaan yang berpindah dari 'Pemenuhan Sedang Berlangsung' kembali ke 'Permintaan Sedang Ditinjau' dianggap mengalami pengerjaan ulang. Definisi tepatnya bergantung pada logika proses bisnis.

Atribut ini mendukung langsung dasbor Analisis Pengerjaan Ulang dan Pengalihan Permintaan serta KPI Tingkat Pengerjaan Ulang Permintaan. Anda dapat mengukur frekuensi pengerjaan ulang dan menganalisis penyebab umumnya, seperti penilaian awal yang keliru atau informasi yang tidak lengkap, yang membuat proses menjadi tidak efisien.

Mengapa ini penting

Atribut ini mengukur ketidakefisienan proses dengan menandai kasus yang menyimpang dari alur normal. Dengan begitu, Anda dapat menemukan akar penyebab pengulangan dan pekerjaan yang harus dilakukan kembali.

Sumber data

Atribut ini dihitung dari urutan aktivitas dalam log peristiwa. Logika khusus diperlukan untuk mendeteksi perpindahan mundur dalam alur proses.

Contoh
truefalse
SLA Terlampaui
IsSlaBreached
Penanda boolean yang menunjukkan apakah permintaan layanan diselesaikan setelah tanggal target SLA.
Deskripsi

Penanda hasil perhitungan ini bernilai true jika stempel waktu penyelesaian akhir permintaan layanan melewati 'Tanggal Target SLA'. Penanda ini memberikan hasil sederhana berupa ya atau tidak untuk kinerja SLA setiap permintaan.

Atribut ini penting untuk dasbor Ikhtisar Kepatuhan SLA dan KPI Tingkat Kepatuhan SLA. Anda dapat menggabungkannya dengan mudah untuk menghitung tingkat kepatuhan keseluruhan, lalu memfilter permintaan yang melewati batas SLA dan membandingkan karakteristik prosesnya dengan permintaan yang patuh. Analisis ini membantu menemukan akar penyebab kegagalan SLA.

Mengapa ini penting

Atribut ini menyederhanakan analisis kinerja SLA dengan mengubah perbandingan stempel waktu menjadi penanda boolean. Dengan begitu, tingkat kepatuhan mudah diukur dan ditampilkan.

Sumber data

Ini adalah kolom hasil perhitungan. Logikanya: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false.

Contoh
truefalse
Tanggal Target SLA
SlaTargetDate
Tanggal dan waktu batas penyelesaian permintaan layanan sesuai Service Level Agreement (SLA).
Deskripsi

Tanggal Target SLA adalah stempel waktu hasil perhitungan yang menunjukkan batas waktu penyelesaian permintaan layanan. Tanggal ini ditentukan berdasarkan aturan perjanjian layanan, yang biasanya mempertimbangkan faktor seperti prioritas dan jenis permintaan.

Atribut ini menjadi dasar bagi dasbor Ikhtisar Kepatuhan SLA. Waktu penyelesaian aktual diukur terhadap tanggal target ini. Dengan membandingkan 'EventEndTime' pada aktivitas penyelesaian terakhir dengan tanggal target, Anda dapat mengetahui apakah komitmen layanan telah dipenuhi.

Mengapa ini penting

Atribut ini menjadi tolok ukur utama untuk menilai kinerja layanan terhadap komitmen, sehingga penting untuk memantau dan melaporkan kepatuhan SLA.

Sumber data

Tanggal ini dihitung dan disimpan oleh modul Service Level Management (SLM). Anda dapat menemukannya pada formulir SLM terkait yang terhubung dengan permintaan layanan.

Contoh
2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
Wajib Disarankan Opsional

Aktivitas Pengelolaan Permintaan Layanan

Catat langkah proses dan tonggak utama ini dalam log peristiwa agar proses dapat ditemukan dan divisualisasikan dengan akurat.
6 Disarankan 8 Opsional
Aktivitas Deskripsi
Pemenuhan sedang berlangsung
Petugas atau tim yang ditugaskan mulai mengerjakan permintaan layanan. Ini menandakan permintaan telah keluar dari antrean dan mulai ditangani.
Mengapa ini penting

Menandai dimulainya pekerjaan pemenuhan yang memberikan nilai. Analisis waktu yang dihabiskan pada tahap ini membantu memahami produktivitas sumber daya dan kompleksitas pemenuhan.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request menjadi 'In Progress'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'In Progress'.

Jenis peristiwa inferred
Permintaan ditugaskan
Permintaan layanan telah ditugaskan kepada petugas atau tim pemenuhan tertentu yang bertanggung jawab menyelesaikan pekerjaan. Ini menandai akhir tahap pemilahan.
Mengapa ini penting

Tahap ini penting untuk mengukur waktu pemilahan dan menganalisis beban kerja petugas. Penugasan ulang yang sering dapat menunjukkan masalah perutean atau kesenjangan keterampilan.

Sumber data

Peristiwa ini dapat dicatat secara langsung dari log audit kolom 'Assigned Group' atau 'Assignee' pada SRM:Request atau formulir aplikasi pemenuhan terkait (misalnya, WOI:WorkOrder).

Pengumpulan data

Stempel waktu dari log audit yang menunjukkan pertama kalinya kolom 'Assignee' diisi dengan nilai yang tidak kosong.

Jenis peristiwa explicit
Permintaan layanan diajukan
Aktivitas ini menandai pembuatan dan pengajuan permintaan layanan baru oleh pengguna. Aktivitas tercatat saat entri baru dibuat di formulir SRM:Request dengan status awal, biasanya 'Submitted'.
Mengapa ini penting

Ini adalah titik awal setiap kasus permintaan layanan. Data ini penting untuk mengukur durasi seluruh siklus dan menganalisis volume permintaan yang masuk.

Sumber data

Peristiwa ini disimpulkan dari stempel waktu pembuatan dan status awal (misalnya, 'Submitted') pada catatan di formulir SRM:Request.

Pengumpulan data

Temukan stempel waktu pembuatan ID Permintaan Layanan baru di formulir SRM:Request saat statusnya 'Submitted'.

Jenis peristiwa inferred
Permintaan layanan dibatalkan
Pemohon atau meja layanan menarik permintaan layanan sebelum pemenuhan selesai. Ini merupakan status akhir bagi permintaan tersebut.
Mengapa ini penting

Melacak pembatalan membantu menemukan pola, seperti pengguna mengajukan permintaan yang keliru atau tidak lagi membutuhkan layanan. Temuan ini dapat menjadi masukan untuk memperbaiki katalog layanan.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request menjadi 'Canceled'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'Canceled'.

Jenis peristiwa inferred
Permintaan layanan diselesaikan
Pemenuhan permintaan layanan telah selesai dan hasilnya telah disampaikan kepada pemohon. Permintaan menunggu konfirmasi akhir atau akan ditutup otomatis setelah jangka waktu tertentu.
Mengapa ini penting

Tahap penting yang menandai akhir siklus pemberian layanan. Ini menjadi titik akhir utama untuk mengukur waktu penyelesaian dan kepatuhan SLA.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request menjadi 'Resolved' atau 'Completed'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'Resolved' atau 'Completed'.

Jenis peristiwa inferred
Permintaan layanan ditutup
Permintaan layanan ditutup secara resmi dan dipindahkan ke status arsip yang hanya dapat dibaca. Ini terjadi setelah permintaan selesai dan masa konfirmasi berakhir.
Mengapa ini penting

Aktivitas ini menandai akhir proses. Jeda antara 'Resolved' dan 'Closed' dapat menunjukkan inefisiensi dalam prosedur penutupan.

Sumber data

Disimpulkan dari perubahan status terakhir pada formulir SRM:Request menjadi 'Closed'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'Closed'.

Jenis peristiwa inferred
Informasi diminta dari pengguna
Petugas pemenuhan membutuhkan informasi tambahan dari pemohon agar dapat melanjutkan pekerjaan. Permintaan biasanya ditempatkan dalam status 'Pending'.
Mengapa ini penting

Aktivitas ini penting untuk menghitung 'Waktu tunggu informasi eksternal' dan mengetahui seberapa sering permintaan terhenti karena informasi yang tidak lengkap.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request menjadi 'Pending' dengan alasan status seperti 'Customer Hold' atau 'Awaiting Information'.

Pengumpulan data

Stempel waktu perubahan status menjadi 'Pending' beserta alasan status tertentu.

Jenis peristiwa inferred
Penyelesaian dikonfirmasi pengguna
Pemohon secara aktif mengonfirmasi bahwa layanan telah diberikan dengan memuaskan dan permintaan sudah selesai. Konfirmasi ini sering memicu penutupan akhir permintaan.
Mengapa ini penting

Memberikan tanda yang jelas tentang kepuasan pelanggan dan secara resmi mengakhiri interaksi layanan. Tahap ini membedakan penyelesaian proses dari penerimaan oleh pelanggan.

Sumber data

Peristiwa ini mungkin tercatat dalam log kerja atau catatan aktivitas SRM:Request saat pengguna memberikan konfirmasi melalui portal atau email. Konfirmasi tidak selalu tercatat sebagai status tersendiri.

Pengumpulan data

Periksa log kerja (SRM:WorkInfo) untuk menemukan entri yang menunjukkan konfirmasi pengguna atau penyelesaian survei.

Jenis peristiwa explicit
Permintaan dilanjutkan kembali
Permintaan layanan keluar dari status tertunda atau menunggu, biasanya setelah pengguna memberikan informasi yang dibutuhkan. Petugas pemenuhan kembali mengerjakan permintaan tersebut.
Mengapa ini penting

Menandai akhir masa tunggu, sehingga waktu tunggu eksternal dan dampaknya terhadap kepatuhan SLA dapat diukur dengan tepat.

Sumber data

Disimpulkan saat status SRM:Request berubah dari 'Pending' kembali menjadi 'In Progress'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah dari 'Pending' menjadi 'In Progress'.

Jenis peristiwa inferred
Permintaan disetujui
Permintaan layanan telah disetujui secara resmi oleh pihak yang berwenang, sehingga proses pemenuhan dapat dilanjutkan. Peristiwa ini biasanya terjadi setelah status 'Waiting for Approval'.
Mengapa ini penting

Menandai akhir subproses persetujuan. Ini menjadi tolok ukur penting untuk melacak durasi persetujuan dan dampaknya terhadap waktu penyelesaian secara keseluruhan.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request dari 'Waiting Approval' ke status berikutnya, seperti 'Planning' atau 'In Progress'. Keputusan persetujuan dicatat dalam formulir persetujuan terkait.

Pengumpulan data

Stempel waktu perubahan status dari 'Waiting Approval' setelah keputusan persetujuan diberikan.

Jenis peristiwa inferred
Permintaan ditolak
Permintaan layanan ditolak saat tahap persetujuan. Ini merupakan status akhir yang menghentikan proses sebelum pemenuhan dimulai.
Mengapa ini penting

Analisis permintaan yang ditolak dapat mengungkap masalah pada alasan pengajuan, kriteria kelayakan, atau kebijakan persetujuan.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request menjadi 'Rejected'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'Rejected'.

Jenis peristiwa inferred
Permintaan menunggu persetujuan
Permintaan layanan telah dikirim kepada pemberi persetujuan atau kelompok persetujuan yang ditunjuk dan menunggu keputusan sebelum pemenuhan dapat dimulai. Tahap ini umum untuk permintaan yang melibatkan biaya atau hak akses.
Mengapa ini penting

Aktivitas ini memisahkan keterlambatan terkait persetujuan, sehingga Anda dapat menganalisis durasi siklus persetujuan dan menemukan hambatan dalam alur persetujuan.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request ke nilai seperti 'Waiting Approval'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'Waiting Approval'.

Jenis peristiwa inferred
Permintaan sedang ditinjau
Meja layanan sedang meninjau dan memilah permintaan untuk menentukan jenisnya, prioritasnya, serta tim yang tepat untuk memenuhinya. Tahap ini biasanya ditandai dengan perubahan status pada catatan permintaan.
Mengapa ini penting

Melacak aktivitas ini membantu mengukur efisiensi pemilahan dan menemukan keterlambatan antara pengajuan dan penugasan. Data ini penting untuk KPI 'Rata-rata waktu pemilahan'.

Sumber data

Disimpulkan dari perubahan status pada formulir SRM:Request ke nilai seperti 'In Review' atau 'Planning'.

Pengumpulan data

Stempel waktu peristiwa pembaruan saat kolom 'Status' pada SRM:Request berubah menjadi 'In Review'.

Jenis peristiwa inferred
Solusi diterapkan
Petugas telah menyelesaikan pekerjaan teknis yang diperlukan untuk memenuhi permintaan layanan. Permintaan kini siap dikonfirmasi kepada pengguna sebelum diselesaikan secara resmi.
Mengapa ini penting

Aktivitas ini membedakan penyelesaian pekerjaan teknis dari penyelesaian resmi, sehingga keterlambatan antara pekerjaan selesai dan konfirmasi pengguna dapat diketahui.

Sumber data

Peristiwa ini dapat disimpulkan dari perubahan status pada tiket pemenuhan di sistem backend (misalnya, status Work Order menjadi 'Completed') sebelum SRM:Request induk ditandai 'Resolved'.

Pengumpulan data

Stempel waktu saat tiket backend (Work Order, Incident, dan sebagainya) yang terhubung ke SRM:Request ditandai selesai.

Jenis peristiwa inferred
Disarankan Opsional

Panduan Ekstraksi

Cara mengambil data dari BMC Helix ITSM

Siap Memulai?

Gunakan templat ini untuk menyederhanakan pengumpulan data dan memulai perjalanan process mining dengan yakin. Mulailah mengoptimalkan pengelolaan permintaan layanan Anda hari ini!

Tingkatkan efisiensi pengelolaan permintaan layanan sekarang

Capai otomatisasi 70%, atasi pemenuhan yang lambat, dan tingkatkan kepuasan pengguna.

Mulai uji coba gratis

Tidak perlu kartu kredit. Anda bisa mulai dalam hitungan menit.