Templat Data Pengelolaan Permintaan Layanan
Templat Data Pengelolaan Permintaan Layanan
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data dari BMC Helix ITSM
Atribut Pengelolaan Permintaan Layanan
| 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
|
|||
Aktivitas Pengelolaan Permintaan Layanan
| 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
|
|||
Panduan Ekstraksi
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.
Tidak perlu kartu kredit. Anda bisa mulai dalam hitungan menit.