Templat data pengelolaan permintaan layanan
Templat data pengelolaan permintaan layanan
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas utama untuk penemuan proses
- Panduan mengambil data dari sistem sumber
Atribut pengelolaan permintaan layanan
| Nama | Deskripsi | ||
|---|---|---|---|
|
ID Permintaan Layanan
ServiceRequestID
|
Pengenal unik untuk setiap permintaan layanan. | ||
|
Deskripsi
Service Request ID 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.
Mengapa ini penting
Ini adalah pengenal kasus utama yang menghubungkan semua aktivitas terkait ke dalam satu rangkaian proses, sehingga proses dapat dianalisis dari awal hingga akhir.
Sumber data
Ini adalah kunci utama objek bisnis Service Request, yang sering ditemukan sebagai ServiceReqNumber pada tabel ServiceReq.
Contoh
SR-0012345SR-0012346SR-0012347
|
|||
|
Nama aktivitas
ActivityName
|
Nama peristiwa atau tugas yang terjadi pada titik tertentu dalam siklus permintaan layanan. | ||
|
Deskripsi
Atribut ini menjelaskan langkah atau perubahan status tertentu dalam proses permintaan layanan, seperti 'Permintaan diajukan untuk persetujuan' atau 'Permintaan layanan diselesaikan'. Menganalisis urutan dan frekuensi aktivitas menjadi dasar untuk memahami alur proses, menemukan hambatan, dan mengidentifikasi penyimpangan dari prosedur standar.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam peta proses, sehingga alur proses dapat divisualisasikan dan dianalisis, termasuk untuk menemukan pengerjaan ulang, hambatan, dan penyimpangan.
Sumber data
Biasanya diambil dari perubahan status, entri jurnal, atau deskripsi peristiwa dalam log audit Ivanti Service Manager.
Contoh
Permintaan layanan dibuatPermintaan disetujuiPermintaan layanan diselesaikanPermintaan layanan ditutup
|
|||
|
Waktu peristiwa
EventTime
|
Stempel waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi. | ||
|
Deskripsi
Waktu peristiwa, yang juga dikenal sebagai waktu mulai, adalah tanggal dan waktu tepat saat aktivitas dicatat dalam sistem. Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menjadi dasar semua analisis process mining berbasis waktu, seperti penghitungan waktu siklus, waktu tunggu, dan durasi aktivitas.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis dan menghitung semua metrik durasi, yang menjadi dasar analisis kinerja.
Sumber data
Ditemukan dalam log audit, entri jurnal (misalnya Journal.CreatedDateTime), atau rekaman perubahan status yang terkait dengan Service Request.
Contoh
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu pembaruan data terbaru dari sistem sumber. | ||
|
Deskripsi
Atribut ini menunjukkan tanggal dan waktu terakhir data diekstrak dari Ivanti Service Manager. Informasi ini menjelaskan seberapa baru data yang dianalisis, periode yang dicakup, dan kapan pembaruan berikutnya dapat diharapkan.
Mengapa ini penting
Memberi tahu pengguna seberapa baru data yang tersedia. Informasi ini penting agar keputusan didasarkan pada data kinerja proses terkini.
Sumber data
Nilai ini dibuat dan dicantumkan pada dataset saat data diekstrak.
Contoh
2024-05-20T12:00:00Z2024-05-21T12:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan asal data proses. Untuk tampilan ini, nilainya akan tetap sama, yang menandakan bahwa semua data berasal dari Ivanti Service Manager. Informasi ini penting jika data digabungkan dari beberapa sistem, agar asal dan konteks data tetap jelas.
Mengapa ini penting
Atribut ini memberikan konteks penting tentang asal data, sehingga analisis dapat dikaitkan dengan sistem sumber yang tepat, terutama di lingkungan yang menggunakan beberapa sistem.
Sumber data
Biasanya berupa nilai tetap yang ditambahkan saat ekstraksi data untuk menandai asal dataset.
Contoh
Ivanti Service Manager
|
|||
|
Agen yang ditugaskan
AssignedAgent
|
Pengguna atau agen yang ditugaskan untuk menangani permintaan layanan. | ||
|
Deskripsi
Agen yang ditugaskan adalah orang yang bertanggung jawab menangani permintaan layanan. Atribut ini memungkinkan analisis pada tingkat individu, yang berguna untuk mengelola kinerja, menyeimbangkan beban kerja, dan menemukan kebutuhan pelatihan. Mencatat perpindahan tugas antar agen penting untuk menghitung KPI seperti 'Rata-rata penugasan ulang per permintaan' dan memahami inefisiensi proses.
Mengapa ini penting
Atribut ini membantu menganalisis beban kerja, kinerja, dan pola penugasan ulang setiap individu. Pola tersebut dapat menunjukkan masalah pelatihan, keterampilan, atau penentuan penugasan awal.
Sumber data
Biasanya terdapat di kolom seperti 'Owner' pada objek Service Request. Nilainya dapat berubah setiap kali permintaan dialihkan, jadi perubahan perlu dicatat dalam log peristiwa.
Contoh
Alice JohnsonBob WilliamsCharlie BrownDiana Prince
|
|||
|
Batas waktu SLA
SLADeadline
|
Waktu batas penyelesaian permintaan layanan. | ||
|
Deskripsi
Batas waktu SLA adalah tanggal dan waktu yang dihitung sebagai tenggat penyelesaian permintaan layanan sesuai Perjanjian Tingkat Layanan. Target ini biasanya ditentukan berdasarkan faktor seperti prioritas dan jenis permintaan. Kepatuhan SLA diukur dengan membandingkan waktu penyelesaian aktual dengan tenggat tersebut.
Mengapa ini penting
Batas waktu ini menjadi tolok ukur untuk menilai kinerja aktual. Informasi ini mendukung penghitungan tingkat kepatuhan SLA dan membantu menemukan permintaan yang berisiko terlambat.
Sumber data
Di Ivanti, nilai ini sering berupa kolom hasil perhitungan yang tersimpan di kolom terkait Perjanjian Tingkat Layanan atau Penawaran, seperti 'ResolutionTargetDateTime'.
Contoh
2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
|
|||
|
Jenis permintaan layanan
ServiceRequestType
|
Klasifikasi atau kategori permintaan layanan. | ||
|
Deskripsi
Atribut ini mengelompokkan permintaan layanan, misalnya 'Permintaan perangkat keras', 'Instalasi perangkat lunak', atau 'Pengaturan ulang kata sandi'. Atribut ini penting untuk analisis karena tim dapat membandingkan kinerja proses, waktu siklus, dan kepatuhan SLA untuk berbagai jenis layanan. Memahami perbedaannya membantu tim menyesuaikan perbaikan proses dan mengalokasikan sumber daya dengan lebih tepat.
Mengapa ini penting
Dengan mengelompokkan proses berdasarkan jenis permintaan, Anda dapat menganalisisnya secara terarah dan mengetahui apakah jenis permintaan tertentu lebih sering mengalami keterlambatan, pengerjaan ulang, atau pelanggaran SLA.
Sumber data
Kemungkinan berupa kolom pada objek bisnis Service Request, yang sering bernama 'Service' atau 'Category'. Lihat dokumentasi Ivanti Service Manager untuk mengetahui nama kolom spesifik, seperti 'SvcReqTmplLink_Category'.
Contoh
Permintaan perangkat keras baruAkses perangkat lunakPerubahan akunPermintaan informasi
|
|||
|
Prioritas
Priority
|
Tingkat prioritas yang diberikan pada permintaan layanan. | ||
|
Deskripsi
Prioritas menunjukkan tingkat urgensi permintaan layanan, biasanya dengan skala seperti 'Rendah', 'Sedang', 'Tinggi', dan 'Kritis'. Atribut ini penting untuk menilai apakah proses mempercepat penanganan permintaan berprioritas tinggi. Analisis biasanya membandingkan waktu siklus dan kepatuhan SLA pada setiap tingkat prioritas untuk memastikan aturan prioritas berjalan sesuai tujuan.
Mengapa ini penting
Atribut ini penting untuk menilai efektivitas strategi penentuan prioritas dan memastikan permintaan berprioritas tinggi diselesaikan lebih cepat daripada permintaan berprioritas rendah.
Sumber data
Kolom standar pada objek Service Request, biasanya bernama 'Priority'.
Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
|
|||
|
Status permintaan layanan
ServiceRequestStatus
|
Status permintaan layanan saat peristiwa terjadi. | ||
|
Deskripsi
Atribut ini mencatat status permintaan layanan, seperti 'Dicatat', 'Sedang diproses', 'Menunggu', 'Diselesaikan', atau 'Ditutup'. Perubahan status sering menjadi penanda aktivitas dalam log proses. Dengan menganalisis waktu yang dihabiskan pada setiap status, Anda dapat menemukan hambatan, misalnya permintaan yang terlalu lama berstatus 'Menunggu'.
Mengapa ini penting
Atribut ini menunjukkan status permintaan pada waktu tertentu. Informasi ini penting untuk menghitung waktu dalam status tertentu dan menemukan proses yang terhenti.
Sumber data
Kolom standar pada objek Service Request, biasanya bernama 'Status'.
Contoh
DicatatAktifMenunggu pelangganDipenuhiDitutup
|
|||
|
Status SLA
SLAStatus
|
Menunjukkan apakah permintaan layanan diselesaikan sebelum tenggat SLA. | ||
|
Deskripsi
Atribut turunan ini menandai setiap permintaan layanan sebagai 'Terpenuhi' atau 'Dilanggar', berdasarkan perbandingan waktu penyelesaian dengan tenggat SLA. Atribut ini menjadi dasar dashboard 'Kinerja kepatuhan SLA' dan KPI 'Tingkat kepatuhan Perjanjian Tingkat Layanan'. Logikanya membandingkan ResolutionDateTime dengan SLADeadline untuk setiap kasus.
Mengapa ini penting
Atribut ini mengukur kinerja terhadap komitmen layanan secara langsung. Informasi ini penting untuk menilai kualitas layanan dan menjaga kepercayaan pengguna.
Sumber data
Hitung dengan membandingkan 'ResolutionDateTime' dengan 'SLADeadline'. Jika ResolutionDateTime <= SLADeadline, statusnya 'Terpenuhi'. Jika tidak, statusnya 'Dilanggar'.
Contoh
TerpenuhiDilanggar
|
|||
|
Tim yang ditugaskan
AssignedTeam
|
Tim atau grup dukungan yang saat ini ditugaskan untuk menangani permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan tim yang bertanggung jawab menangani permintaan layanan pada waktu tertentu. Analisis perpindahan tugas antar tim, waktu penanganan oleh setiap tim, dan jumlah permintaan yang ditangani tiap tim penting untuk memahami pembagian beban kerja, menemukan hambatan, dan menilai kinerja tim. Informasi ini juga mendukung dashboard kepatuhan SLA dan beban kerja agen.
Mengapa ini penting
Atribut ini mencatat tanggung jawab dan perpindahan tugas. Dengan begitu, Anda dapat menganalisis keterlambatan antar tim, keseimbangan beban kerja, dan tim yang menjadi hambatan dalam proses.
Sumber data
Informasi ini biasanya tersimpan di kolom seperti 'OwnerTeam' pada objek Service Request atau di catatan penugasan terkait.
Contoh
Meja layanan TIOperasional jaringanDukungan SDMPengelolaan fasilitas
|
|||
|
Waktu akhir peristiwa
EventEndTime
|
Waktu yang menunjukkan kapan suatu aktivitas selesai. | ||
|
Deskripsi
Waktu akhir peristiwa menandai selesainya suatu aktivitas. Selisih antara Waktu Peristiwa (mulai) dan Waktu Akhir Peristiwa menunjukkan lama pengerjaan aktivitas tersebut. Informasi ini penting untuk mengetahui langkah mana yang paling banyak menyita waktu, sehingga hambatan dan peluang perbaikan dapat ditemukan.
Mengapa ini penting
Informasi ini memungkinkan Anda menghitung durasi setiap aktivitas, yang penting untuk menemukan hambatan proses dan tugas yang memakan waktu lama.
Sumber data
Kolom ini mungkin tidak tersedia secara terpisah. Biasanya, nilainya sama dengan waktu mulai aktivitas berikutnya dalam urutan untuk kasus yang sama.
Contoh
2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
|
|||
|
Waktu penyelesaian
ResolutionDateTime
|
Tanggal dan waktu saat permintaan layanan resmi diselesaikan. | ||
|
Deskripsi
Atribut tingkat kasus ini mencatat waktu akhir saat layanan diberikan atau masalah diperbaiki, sebelum permintaan resmi ditutup. Waktu ini menjadi titik akhir utama untuk menghitung waktu siklus permintaan layanan dari awal hingga akhir. Atribut ini penting untuk mengukur efisiensi proses secara keseluruhan dan kepatuhan SLA.
Mengapa ini penting
Atribut ini menentukan titik akhir untuk menghitung waktu siklus proses inti, salah satu indikator kinerja utama efisiensi penyampaian layanan.
Sumber data
Kolom waktu khusus pada objek Service Request, sering bernama 'ResolvedDateTime' atau nama serupa.
Contoh
2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
|
|||
|
Departemen pemohon
RequestorDepartment
|
Departemen tempat pengguna yang mengajukan permintaan layanan bekerja. | ||
|
Deskripsi
Atribut ini menunjukkan departemen karyawan atau sistem yang mengajukan permintaan layanan, seperti 'Penjualan', 'Keuangan', atau 'Sumber Daya Manusia'. Atribut ini memungkinkan analisis kualitas dan permintaan layanan di berbagai bagian organisasi. Misalnya, Anda dapat mengetahui apakah departemen tertentu mengalami waktu penyelesaian lebih lama atau mengajukan lebih banyak permintaan.
Mengapa ini penting
Atribut ini memungkinkan analisis penggunaan dan kualitas layanan berdasarkan unit bisnis, sehingga Anda dapat menemukan masalah atau tren khusus di departemen tertentu.
Sumber data
Informasi ini biasanya diambil dari profil pengguna pemohon yang terhubung ke Service Request. Kolomnya dapat berupa 'Department' pada objek Profile.Employee.
Contoh
KeuanganPenjualanPemasaranTeknologi Informasi
|
|||
|
Jumlah dibuka kembali
ReopenCount
|
Berapa kali permintaan layanan yang telah diselesaikan dibuka kembali. | ||
|
Deskripsi
Penghitung ini bertambah setiap kali status permintaan layanan berubah dari 'Diselesaikan' atau 'Ditutup' kembali menjadi 'Aktif'. Jumlah buka kembali yang tinggi menunjukkan kemungkinan masalah pada kualitas penyelesaian pertama, solusi yang belum tuntas, atau masalah yang berulang. Atribut ini mendukung KPI 'Tingkat pengerjaan ulang permintaan layanan'.
Mengapa ini penting
Atribut ini mengukur pengerjaan ulang secara langsung dan menjadi indikator penting kualitas penyelesaian. Jumlah yang tinggi menunjukkan bahwa perbaikan awal belum efektif.
Sumber data
Biasanya berupa kolom penghitung pada objek Service Request. Nilainya bertambah melalui aturan bisnis saat status berubah sesuai kondisi tertentu. Nama kolomnya mungkin 'ReopenCounter'.
Contoh
0123
|
|||
|
Jumlah penugasan
AssignmentCount
|
Jumlah total penugasan atau penugasan ulang permintaan layanan. | ||
|
Deskripsi
Metrik hasil perhitungan ini menghitung jumlah aktivitas terkait penugasan, seperti 'Ditugaskan ke tim' dan 'Ditugaskan ke agen', untuk setiap permintaan layanan. Penugasan ulang yang sering, yang kerap disebut 'ping-pong tiket', menunjukkan masalah dalam perutean, penyelesaian pada kontak pertama, atau kejelasan tanggung jawab tim. Atribut ini penting untuk KPI 'Rata-rata penugasan ulang per permintaan'.
Mengapa ini penting
Atribut ini mengukur perpindahan tugas yang tidak efisien dan masalah perutean. Jumlah yang tinggi menunjukkan kemungkinan waktu penyelesaian lebih lama dan pengguna yang frustrasi.
Sumber data
Hitung jumlah kemunculan aktivitas terkait penugasan untuk setiap ServiceRequestID unik saat menyiapkan data.
Contoh
12345
|
|||
|
Kanal
Channel
|
Metode atau kanal yang digunakan untuk mengajukan permintaan layanan. | ||
|
Deskripsi
Kanal menunjukkan cara permintaan layanan dibuat, misalnya melalui Portal Layanan Mandiri, email, telepon, atau secara otomatis oleh sistem lain. Dengan menganalisis jumlah permintaan dan waktu penyelesaian berdasarkan kanal, Anda dapat mengetahui kanal mana yang paling efisien dan kanal mana yang perlu diperbaiki prosesnya atau memerlukan pelatihan pengguna.
Mengapa ini penting
Atribut ini membantu memahami perilaku pengguna dan efisiensi kanal. Informasi tersebut dapat menjadi dasar keputusan tentang strategi penyampaian layanan dan peluang otomatisasi.
Sumber data
Informasi ini sering tersimpan di kolom seperti 'Source' atau 'CreatedBy' pada objek Service Request.
Contoh
Layanan mandiriEmailTeleponInput langsung
|
|||
|
Kategori penyelesaian
ResolutionCategory
|
Klasifikasi cara permintaan layanan diselesaikan. | ||
|
Deskripsi
Kategori penyelesaian menyediakan cara terstruktur untuk mengelompokkan cara permintaan layanan diselesaikan. Klasifikasi ini sering memiliki beberapa tingkat, misalnya kategori dan subkategori, yang membantu analisis akar masalah dan pelaporan tren. Contohnya, klasifikasi ini dapat menunjukkan masalah berulang atau tindakan pemenuhan yang umum. Informasi tersebut dapat digunakan untuk meningkatkan layanan atau membuat artikel basis pengetahuan.
Mengapa ini penting
Atribut ini memberi gambaran tentang cara penyelesaian, sehingga Anda dapat menemukan masalah umum, peluang perbaikan layanan, dan proses yang berpotensi diotomatisasi.
Sumber data
Biasanya tersimpan di kolom klasifikasi yang diisi saat permintaan diselesaikan, seperti 'ResolutionCategory' atau kolom kode penutupan khusus.
Contoh
Pelatihan pengguna diperlukanPerangkat lunak diterapkanPerangkat keras diperbaikiAkses diberikan
|
|||
|
Nama vendor
VendorName
|
Nama vendor eksternal yang terlibat dalam penyelesaian permintaan. | ||
|
Deskripsi
Atribut ini menunjukkan vendor pihak ketiga yang dilibatkan untuk membantu atau menyelesaikan permintaan layanan. Atribut ini penting untuk dashboard 'Durasi aktivitas vendor eksternal' karena memungkinkan Anda mengukur dan membandingkan kinerja vendor. Informasi ini membantu mengelola hubungan dengan vendor dan menemukan hambatan akibat ketergantungan pada pihak eksternal.
Mengapa ini penting
Atribut ini memungkinkan analisis kinerja pihak ketiga dan dampaknya terhadap waktu penyelesaian permintaan layanan secara keseluruhan, sehingga mendukung pengelolaan vendor.
Sumber data
Informasi ini dapat tersimpan di kolom pada objek tugas yang terkait dengan permintaan layanan, atau di kolom khusus pada objek Service Request jika vendor ditugaskan.
Contoh
Dell SupportOracle ConsultingMicrosoft Premiernull
|
|||
|
Termasuk pengerjaan ulang
IsRework
|
Penanda boolean yang menunjukkan apakah permintaan layanan melibatkan aktivitas pengerjaan ulang. | ||
|
Deskripsi
Penanda hasil perhitungan ini bernilai true jika permintaan layanan menunjukkan tanda pengerjaan ulang, misalnya dibuka kembali setelah diselesaikan atau aktivitas tertentu berulang dalam satu rangkaian. Penanda ini memudahkan penghitungan KPI 'Tingkat pengerjaan ulang permintaan layanan' dan penyaringan kasus proses yang tidak efisien pada dashboard seperti 'Alur pengerjaan ulang dan penugasan ulang'.
Mengapa ini penting
Atribut ini memudahkan Anda menemukan dan menghitung jumlah permintaan yang memerlukan upaya tambahan di luar rencana, sekaligus menunjukkan masalah kualitas dan efisiensi.
Sumber data
Nilai ini diturunkan dari data. Logikanya dapat menggunakan atribut 'ReopenCount' yang lebih besar dari nol atau mendeteksi urutan aktivitas tertentu, seperti beberapa peristiwa 'Ditugaskan ke agen'.
Contoh
truefalse
|
|||
Aktivitas pengelolaan permintaan layanan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Permintaan ditugaskan ke tim
|
Permintaan layanan ditugaskan kepada tim dukungan tertentu untuk ditangani. Peristiwa ini diketahui dari pengisian atau perubahan kolom 'OwnerTeam' pada rekaman Service Request. | ||
|
Mengapa ini penting
Peristiwa ini penting untuk menganalisis kinerja tim, distribusi beban kerja, dan waktu serah terima antar tim. Data ini membantu menemukan tim yang menjadi hambatan dalam proses.
Sumber data
Dilacak melalui perubahan kolom 'OwnerTeam' dalam riwayat audit atau jurnal Service Request.
Pengumpulan data
Peristiwa pembaruan kolom 'OwnerTeam', yang biasanya tercatat dalam jejak audit.
Jenis peristiwa
explicit
|
|||
|
Permintaan ditugaskan kepada agen
|
Agen tertentu mengambil alih permintaan layanan. Aktivitas ini biasanya disimpulkan saat kolom 'Owner', yang menunjukkan agen penanggung jawab, pertama kali diisi atau diperbarui. | ||
|
Mengapa ini penting
Peristiwa ini menandai berakhirnya waktu tunggu awal atau waktu dalam antrean. Mengukur durasi sebelum aktivitas ini membantu menemukan masalah alokasi sumber daya dan mendukung dashboard Beban Kerja Agen.
Sumber data
Disimpulkan dari pengisian atau perubahan kolom 'Owner' pada rekaman Service Request, sebagaimana terlihat dalam riwayat audit.
Pengumpulan data
Stempel waktu pertama saat kolom 'Owner' diisi dengan nama agen setelah permintaan dibuat atau ditugaskan ke tim.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dibuat
|
Aktivitas ini menandai awal siklus permintaan layanan, saat permintaan baru diajukan secara resmi dan dicatat di Ivanti. Peristiwa ini tercatat ketika rekaman baru dibuat pada objek bisnis Service Request, yang menghasilkan Service Request ID unik. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses. Mengukur waktu dari titik ini hingga penyelesaian menjadi dasar untuk menghitung waktu siklus keseluruhan dan efisiensi proses.
Sumber data
Data ini diambil dari stempel waktu pembuatan rekaman Service Request, misalnya kolom CreatedDateTime pada objek bisnis ServiceReq.
Pengumpulan data
Peristiwa pembuatan rekaman pada tabel ServiceReq, yang ditentukan berdasarkan stempel waktu pembuatannya.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan diselesaikan
|
Permintaan layanan dianggap selesai dan solusi telah diberikan kepada pengguna. Tonggak utama ini tercatat saat status berubah menjadi 'Resolved', yang sering kali menghentikan penghitungan waktu SLA. | ||
|
Mengapa ini penting
Ini adalah titik akhir penting untuk mengukur waktu penyelesaian dan kepatuhan SLA. Durasi dari pembuatan hingga aktivitas ini menjadi KPI utama untuk kinerja proses.
Sumber data
Disimpulkan dari perubahan kolom 'Status' pada rekaman Service Request menjadi 'Resolved', beserta stempel waktunya.
Pengumpulan data
Mendeteksi pembaruan kolom 'Status' menjadi 'Resolved' dari riwayat audit.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan ditutup
|
Permintaan layanan resmi ditutup dan tidak dapat ditindaklanjuti lagi. Penutupan ini sering terjadi secara otomatis setelah jangka waktu tertentu dalam status 'Resolved', sebagai akhir dari siklus permintaan. | ||
|
Mengapa ini penting
Aktivitas ini menandai akhir proses. Waktu antara 'Resolved' dan 'Closed' dapat menunjukkan keterlambatan konfirmasi atau proses otomatis dalam sistem.
Sumber data
Disimpulkan dari perubahan kolom 'Status' pada rekaman Service Request menjadi 'Closed', beserta stempel waktunya.
Pengumpulan data
Mendeteksi pembaruan kolom 'Status' menjadi 'Closed' dari riwayat audit.
Jenis peristiwa
inferred
|
|||
|
Informasi diberikan oleh pengguna
|
Pemohon telah memberikan informasi yang diperlukan sehingga agen dapat melanjutkan pekerjaan. Peristiwa ini tercatat saat permintaan keluar dari status 'Waiting for Customer' dan kembali ke status aktif. | ||
|
Mengapa ini penting
Peristiwa ini menutup siklus permintaan informasi. Waktu antara permintaan dan penerimaan informasi menjadi bagian penting dari keterlambatan proses dan siklus pengerjaan ulang.
Sumber data
Disimpulkan saat kolom 'Status' pada Service Request berubah dari status 'Waiting for Customer' ke status aktif, seperti 'Active' atau 'In Progress'.
Pengumpulan data
Mendeteksi perubahan status dari status menunggu pengguna ke status aktif.
Jenis peristiwa
inferred
|
|||
|
Informasi diminta dari pengguna
|
Agen yang ditugaskan memerlukan informasi tambahan dari pemohon agar dapat melanjutkan pemenuhan permintaan. Peristiwa ini tercatat saat status permintaan berubah menjadi, misalnya, 'Waiting for Customer'. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan keterlambatan akibat informasi awal yang tidak lengkap. Melacak frekuensi dan durasinya penting untuk Analisis Dampak Permintaan Informasi dan menemukan peluang perbaikan proses.
Sumber data
Disimpulkan dari perubahan status pada rekaman Service Request menjadi status seperti 'Waiting for Customer' atau 'Pending'.
Pengumpulan data
Mendeteksi perubahan kolom 'Status' ke status khusus yang menandakan sedang menunggu pengguna.
Jenis peristiwa
inferred
|
|||
|
Permintaan diajukan untuk persetujuan
|
Permintaan layanan telah diajukan untuk mendapatkan persetujuan yang diperlukan sebelum dapat dipenuhi. Peristiwa ini biasanya disimpulkan saat status permintaan berubah menjadi 'Submitted' atau 'Pending Approval', yang sering kali memulai alur kerja persetujuan. | ||
|
Mengapa ini penting
Melacak aktivitas ini membantu menemukan keterlambatan pada tahap persetujuan. Waktu tunggu yang lama dapat menjadi hambatan besar, sehingga memperpanjang waktu penyelesaian dan menurunkan kepuasan pengguna.
Sumber data
Disimpulkan dari perubahan status pada rekaman Service Request, kemungkinan menjadi 'Submitted' atau 'Waiting for Approval'. Data ini juga dapat diambil dari objek bisnis FRS_Approval atau FRS_ApprovalVoteTracking.
Pengumpulan data
Perubahan kolom 'Status' pada rekaman Service Request ke status menunggu persetujuan.
Jenis peristiwa
inferred
|
|||
|
Permintaan disetujui
|
Permintaan layanan telah menerima semua persetujuan yang diperlukan dan dapat dilanjutkan ke tahap pemenuhan. Peristiwa ini tercatat saat alur kerja persetujuan berhasil diselesaikan dan status permintaan berubah. | ||
|
Mengapa ini penting
Aktivitas ini menandai tonggak penting, yaitu berakhirnya tahap persetujuan dan dimulainya pemenuhan. Data ini membantu mengukur efisiensi proses persetujuan.
Sumber data
Disimpulkan dari perubahan status 'Waiting for Approval' menjadi 'Approved' atau 'Fulfilled'. Peristiwa ini juga mungkin dicatat secara eksplisit pada objek bisnis FRS_Approval.
Pengumpulan data
Perubahan kolom 'Status' pada rekaman Service Request dari status persetujuan ke status aktif.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dibatalkan
|
Permintaan layanan dibatalkan oleh pengguna atau agen sebelum selesai. Ini merupakan status akhir alternatif yang tercatat saat status berubah menjadi 'Cancelled' atau 'Withdrawn'. | ||
|
Mengapa ini penting
Peristiwa ini menandai proses berakhir dengan cara yang tidak standar. Menganalisis alasan pembatalan permintaan dapat mengungkap masalah dalam proses permintaan atau perubahan kebutuhan pengguna.
Sumber data
Disimpulkan dari perubahan kolom 'Status' pada rekaman Service Request menjadi 'Cancelled'.
Pengumpulan data
Mendeteksi pembaruan kolom 'Status' menjadi 'Cancelled' dari riwayat audit.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dibuka kembali
|
Permintaan layanan yang sebelumnya telah diselesaikan diaktifkan kembali karena masalah masih terjadi atau solusi yang diberikan tidak memuaskan. Peristiwa ini tercatat saat status berubah dari 'Resolved' kembali ke status aktif seperti 'Active' atau 'Assigned'. | ||
|
Mengapa ini penting
Aktivitas ini menunjukkan adanya pengerjaan ulang dan rendahnya kualitas penyelesaian pada upaya pertama. Analisis peristiwa pembukaan kembali membantu menemukan kelemahan proses dan meningkatkan KPI Tingkat Pengerjaan Ulang Permintaan Layanan.
Sumber data
Disimpulkan dari riwayat audit saat kolom 'Status' berubah dari 'Resolved' atau 'Closed' ke status aktif.
Pengumpulan data
Perubahan status dari status akhir ('Resolved', 'Closed') ke status terbuka ('Active', 'Assigned').
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dipenuhi
|
Semua tugas yang diperlukan untuk memenuhi permintaan layanan telah diselesaikan oleh agen atau sistem. Peristiwa ini tercatat saat status berubah menjadi 'Fulfilled', yang sering kali terjadi sebelum status akhir 'Resolved'. | ||
|
Mengapa ini penting
Tonggak ini menandai selesainya pekerjaan teknis atau prosedural. Ini menjadi titik penting untuk mengukur waktu penanganan aktif sebelum konfirmasi akhir dan penutupan.
Sumber data
Disimpulkan dari perubahan kolom 'Status' pada rekaman Service Request menjadi 'Fulfilled'.
Pengumpulan data
Perubahan kolom 'Status' menjadi 'Fulfilled' yang terdeteksi dari riwayat rekaman.
Jenis peristiwa
inferred
|
|||
|
Prioritas diubah
|
Prioritas permintaan layanan diperbarui setelah permintaan dibuat. Peristiwa ini diambil dari log atau riwayat audit yang mencatat perubahan pada tingkat kolom. | ||
|
Mengapa ini penting
Melacak perubahan prioritas penting untuk Ikhtisar Efektivitas Penentuan Prioritas. Data ini membantu memastikan eskalasi ditangani dengan benar dan prioritas awal sudah sesuai.
Sumber data
Peristiwa ini tercatat secara eksplisit dalam riwayat audit rekaman Service Request, yang mencatat perubahan kolom 'Priority'.
Pengumpulan data
Peristiwa pembaruan kolom 'Priority' yang tercatat dalam jejak audit sistem.
Jenis peristiwa
explicit
|
|||
|
Vendor eksternal dilibatkan
|
Pemenuhan permintaan layanan telah diserahkan kepada vendor eksternal atau pihak ketiga. Peristiwa ini biasanya tercatat saat status berubah menjadi 'Waiting for 3rd Party' atau status serupa. | ||
|
Mengapa ini penting
Aktivitas ini penting untuk mengukur kinerja vendor dan dampaknya terhadap waktu siklus keseluruhan. Data ini memungkinkan analisis keterlambatan terkait vendor dan mendukung dashboard Durasi Aktivitas Vendor Eksternal.
Sumber data
Disimpulkan dari perubahan status pada rekaman Service Request menjadi status seperti 'Waiting for 3rd Party' atau 'Pending Vendor'.
Pengumpulan data
Mendeteksi perubahan kolom 'Status' ke status khusus yang menandakan sedang menunggu vendor.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat data terperinci ini untuk memahami potensi proses pengelolaan permintaan layanan Anda. Mulai tingkatkan operasional Anda hari ini.
Mulai optimalkan pengelolaan permintaan layanan Anda hari ini
Akhiri pemenuhan yang lambat, kurangi frustrasi pengguna, dan capai tingkat otomatisasi 70%.
Tidak perlu kartu kredit. Siap digunakan dalam hitungan menit.