Templat data pengelolaan permintaan layanan
Templat data pengelolaan permintaan layanan
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama untuk dilacak saat menemukan proses
- Panduan ekstraksi data langkah demi langkah
Atribut manajemen permintaan layanan
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi dalam siklus permintaan layanan. | ||
|
Deskripsi
Atribut Aktivitas mencatat nama setiap langkah atau perubahan status dalam proses permintaan layanan. Contohnya mencakup peristiwa seperti 'Permintaan dibuat', 'Permintaan disetujui', 'Ditugaskan ke agen', atau 'Permintaan ditutup'. Analisis aktivitas ini membantu memvisualisasikan alur proses, menemukan jalur yang umum, dan mendeteksi penyimpangan dari prosedur standar. Atribut ini menjadi dasar untuk memahami apa yang sebenarnya terjadi selama pemenuhan permintaan.
Mengapa ini penting
Atribut wajib ini menentukan langkah-langkah dalam peta proses. Atribut ini menjadi dasar semua analisis proses, termasuk menemukan hambatan, alur pengerjaan ulang, dan masalah kepatuhan.
Sumber data
Diambil dari perubahan pada kolom 'State' atau 'Stage' di tabel seperti 'sc_request' atau 'sc_req_item', atau dari jejak audit (sys_audit).
Contoh
Permintaan layanan dibuatPermintaan ditugaskan ke grupPermintaan layanan diselesaikanInformasi diminta dari pengguna
|
|||
|
Service Request ID
ServiceRequestID
|
Pengenal unik untuk setiap rekaman permintaan layanan. | ||
|
Deskripsi
Service Request ID adalah kunci utama yang membedakan setiap permintaan layanan yang diajukan oleh pengguna atau sistem. ID ini menghubungkan semua peristiwa berikutnya, dari pencatatan awal hingga penutupan akhir. Dalam process mining, ID ini penting untuk merekonstruksi perjalanan setiap permintaan dari awal hingga akhir dan menganalisis seluruh siklusnya.
Mengapa ini penting
Ini adalah Case ID wajib. ID ini menghubungkan semua aktivitas terkait ke dalam satu instans proses, sehingga alur proses, variasi, dan waktu siklus dapat dianalisis.
Sumber data
Tabel ServiceNow Request [sc_request], kolom 'number'.
Contoh
REQ0010001REQ0010025REQ0010112
|
|||
|
Waktu mulai
EventTime
|
Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa dimulai. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu tepat terjadinya setiap aktivitas dalam proses permintaan layanan. Urutan kronologis ini diperlukan untuk membuat peta proses dan melakukan analisis berbasis waktu. Stempel waktu yang akurat penting untuk menghitung waktu siklus, waktu tunggu, dan durasi pemrosesan. Data ini membantu menemukan hambatan, pelanggaran SLA, dan tren kinerja dari waktu ke waktu.
Mengapa ini penting
Stempel waktu wajib ini diperlukan untuk mengurutkan peristiwa dengan benar. Data ini menjadi dasar semua analisis kinerja dan durasi, termasuk waktu siklus dan identifikasi hambatan.
Sumber data
Biasanya terdapat di kolom 'sys_updated_on' atau 'sys_created_on' pada tabel ServiceNow terkait, seperti sc_request dan sc_task, atau di jejak audit (sys_audit).
Contoh
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu penyegaran atau ekstraksi data terbaru. | ||
|
Deskripsi
Atribut ini menunjukkan tanggal dan waktu terakhir data diekstrak dari sistem sumber dan dimuat ke alat process mining. Dengan begitu, Anda dapat mengetahui seberapa baru data yang dianalisis. Analis menggunakan informasi ini untuk memastikan apakah data yang dilihat sudah mutakhir. Hal ini penting untuk pemantauan operasional dan pengambilan keputusan secara langsung. Informasi ini juga membantu menetapkan ekspektasi tentang kebaruan wawasan yang tersedia.
Mengapa ini penting
Memastikan pengguna mengetahui kebaruan data, yang penting untuk mempercayai hasil analisis dan mengambil keputusan tepat waktu berdasarkan data.
Sumber data
Kolom metadata ini ditambahkan saat data dimasukkan dan mencerminkan stempel waktu selesainya tugas ETL.
Contoh
2023-10-27T04:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem asal data. | ||
|
Deskripsi
Atribut ini menunjukkan sistem asal data, dalam hal ini ServiceNow. Atribut ini berguna saat data dari beberapa sistem digabungkan untuk memberikan gambaran proses secara menyeluruh. Untuk analisis dari satu sumber, atribut ini memberikan konteks penting serta membantu tata kelola dan pengelolaan data. Atribut ini memastikan setiap pengguna memahami asal data yang sedang dianalisis.
Mengapa ini penting
Menyediakan metadata penting untuk tata kelola data, keterlacakan, dan konteks, terutama saat menggabungkan data dari beberapa sistem perusahaan.
Sumber data
Biasanya berupa nilai tetap yang ditambahkan selama proses ekstraksi dan transformasi data.
Contoh
ServiceNow
|
|||
|
Ditugaskan kepada
AssignedTo
|
Pengguna yang bertanggung jawab menangani permintaan layanan pada waktu tertentu. | ||
|
Deskripsi
Atribut ini menunjukkan agen atau teknisi tertentu yang ditugaskan menangani permintaan layanan. Nilainya berubah saat permintaan dialihkan antarindividu. Analisis kolom 'Assigned To' penting untuk memahami pembagian beban kerja, kinerja individu, dan dampak serah terima terhadap waktu penyelesaian. Analisis ini membantu menjawab pertanyaan tentang pemanfaatan sumber daya dan menemukan peluang pelatihan atau penjelasan proses untuk mengurangi penugasan ulang.
Mengapa ini penting
Memungkinkan analisis beban kerja, kinerja, dan serah terima antaragen. Atribut ini penting untuk pengelolaan sumber daya dan menemukan hambatan yang terkait dengan individu tertentu.
Sumber data
Tabel ServiceNow Request Item [sc_req_item] atau Catalog Task [sc_task], kolom 'assigned_to'.
Contoh
Beth AnglinDavid LooHoward Johnson
|
|||
|
Grup penugasan
AssignmentGroup
|
Tim atau grup yang bertanggung jawab menangani permintaan layanan. | ||
|
Deskripsi
Grup Penugasan menunjukkan tim yang bertanggung jawab atas permintaan layanan pada tahap tertentu, seperti 'Service Desk', 'Network Operations', atau 'Database Administration'. Atribut ini penting untuk menganalisis alur proses antarbidang kerja. Dengan melacak perubahan Grup Penugasan, organisasi dapat memvisualisasikan serah terima antar tim, mengukur waktu antre dalam daftar pekerjaan tiap grup, dan menemukan ketergantungan atau keterlambatan antar tim. Informasi ini penting untuk meningkatkan kolaborasi lintas fungsi.
Mengapa ini penting
Melacak pembagian pekerjaan antar tim, menunjukkan serah terima, dan membantu menemukan hambatan atau masalah kinerja pada tim tertentu.
Sumber data
Tabel ServiceNow Request Item [sc_req_item] atau Catalog Task [sc_task], kolom 'assignment_group'.
Contoh
Meja layananDukungan TI L2Penyediaan perangkat keras
|
|||
|
Kategori
Category
|
Klasifikasi utama permintaan layanan, seperti Perangkat Keras atau Perangkat Lunak. | ||
|
Deskripsi
Kategori memberikan klasifikasi umum untuk permintaan layanan. Biasanya, kategori digunakan untuk meneruskan permintaan ke tim yang tepat dan melaporkan jenis permintaan yang masuk. Dalam process mining, kategori berguna untuk memfilter data dan menganalisis proses berdasarkan dimensi tertentu. Analis dapat membandingkan alur proses, waktu siklus, dan tingkat otomatisasi untuk berbagai jenis permintaan. Dengan begitu, variasi yang tidak terlihat pada data keseluruhan dapat ditemukan. Misalnya, proses untuk permintaan 'Perangkat Keras' mungkin sangat berbeda dari proses untuk permintaan 'Perangkat Lunak'.
Mengapa ini penting
Memudahkan segmentasi dan perbandingan proses untuk berbagai jenis layanan, sehingga masalah khusus pada kategori tertentu dan peluang perbaikan dapat ditemukan.
Sumber data
Tabel ServiceNow Request Item [sc_req_item], biasanya melalui kategori Catalog Item terkait [sc_cat_item].
Contoh
Perangkat kerasPerangkat lunakPermintaan aksesJaringan
|
|||
|
Memenuhi SLA
MadeSLA
|
Penanda boolean yang menunjukkan apakah permintaan layanan diselesaikan sesuai Service Level Agreement. | ||
|
Deskripsi
Atribut ini menunjukkan apakah waktu penyelesaian permintaan layanan memenuhi Service Level Agreement (SLA) yang ditetapkan. Ini adalah metrik hasil penting yang mengukur kinerja layanan berdasarkan komitmen yang telah dibuat. Analisis penanda ini membantu menghitung KPI Tingkat Kepatuhan SLA. Atribut ini juga dapat digunakan sebagai dimensi untuk membandingkan jalur proses permintaan yang memenuhi SLA dengan yang melanggar SLA. Perbandingan ini dapat mengungkap pola atau aktivitas yang menyebabkan kegagalan memenuhi SLA. Informasi ini penting untuk memantau risiko lebih awal dan terus meningkatkan layanan.
Mengapa ini penting
Mengukur kinerja layanan berdasarkan komitmen secara langsung dan membantu mencari akar penyebab pelanggaran SLA dengan membandingkan kasus yang patuh dan tidak patuh.
Sumber data
Tabel ServiceNow Task SLA [task_sla], kolom 'has_breached'. Nilainya perlu dibalik, misalnya MadeSLA = NOT has_breached.
Contoh
truefalse
|
|||
|
Prioritas
Priority
|
Tingkat prioritas permintaan layanan yang memengaruhi tingkat urgensinya. | ||
|
Deskripsi
Prioritas menentukan tingkat kepentingan dan urgensi relatif suatu permintaan layanan. Prioritas biasanya ditentukan berdasarkan dampak dan urgensi, lalu digunakan untuk membantu agen menentukan permintaan yang harus ditangani lebih dahulu. Analisis data berdasarkan prioritas penting untuk mengetahui apakah permintaan berprioritas tinggi diproses lebih cepat daripada permintaan berprioritas rendah. Anda dapat memfilter dasbor untuk memeriksa apakah SLA permintaan penting terpenuhi dan menilai efektivitas sistem penentuan prioritas.
Mengapa ini penting
Memungkinkan permintaan dikelompokkan untuk memastikan item berprioritas tinggi diproses lebih cepat. Atribut ini penting untuk analisis SLA dan alokasi sumber daya.
Sumber data
Tabel ServiceNow Request [sc_request] atau Request Item [sc_req_item], kolom 'priority'.
Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
|
|||
|
Status
State
|
Status operasional permintaan layanan saat ini. | ||
|
Deskripsi
Atribut Status menunjukkan tahap permintaan layanan saat ini dalam siklusnya, seperti 'Open', 'Work in Progress', 'Pending', atau 'Closed'. Perubahan pada kolom ini sering digunakan untuk menghasilkan aktivitas pada peta proses. Analisis Status penting untuk memahami berapa lama permintaan berada dalam status tertentu, terutama status menunggu atau tertunda. Analisis ini membantu menemukan antrean dan keterlambatan, seperti waktu yang dihabiskan untuk 'Menunggu Informasi dari Pengguna', yang sering memperpanjang waktu siklus.
Mengapa ini penting
Memberikan gambaran status permintaan pada waktu tertentu, sehingga waktu tunggu, antrean, dan durasi tiap tahap proses dapat dianalisis.
Sumber data
Tabel ServiceNow Request [sc_request] atau Request Item [sc_req_item], kolom 'state' atau 'stage'.
Contoh
TerbukaSedang dikerjakanMenunggu informasi dari penggunaDitutup, selesai
|
|||
|
Dibuka oleh
OpenedBy
|
Orang yang pertama kali mengirimkan permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan pengguna yang membuat permintaan layanan. Orang tersebut sering kali adalah pihak yang membutuhkan layanan, tetapi bisa juga manajer, perwakilan, atau sistem otomatis. Analisis permintaan berdasarkan pengguna yang membukanya atau departemennya dapat mengungkap pola tertentu. Misalnya, kelompok pengguna tertentu mungkin sering mengirimkan permintaan yang rumit atau bermasalah. Temuan ini dapat menjadi dasar pelatihan yang lebih terarah atau menunjukkan perlunya artikel basis pengetahuan yang lebih baik agar pengguna dapat menyelesaikan kebutuhan secara mandiri.
Mengapa ini penting
Membantu menganalisis pola permintaan berdasarkan pengguna, departemen, atau peran. Hasilnya dapat menjadi dasar untuk pelatihan dan perbaikan proses yang lebih terarah.
Sumber data
Tabel ServiceNow Request [sc_request], kolom 'opened_by'.
Contoh
Abel TuterFred LuddyDon Goodliffe
|
|||
|
Dilakukan otomatis
IsAutomated
|
Penanda yang menunjukkan apakah suatu aktivitas dilakukan oleh sistem atau otomatisasi. | ||
|
Deskripsi
Atribut boolean ini membedakan aktivitas yang dilakukan secara manual oleh petugas dengan aktivitas yang dijalankan sistem otomatis, seperti workflow atau integrasi. Misalnya, 'Persetujuan Diminta' mungkin dilakukan secara otomatis, sedangkan 'Permintaan Ditugaskan kepada Petugas' mungkin dilakukan secara manual. Analisis atribut ini penting untuk mengukur dan meningkatkan tingkat otomatisasi dalam proses permintaan layanan. Atribut ini membantu menemukan tugas manual yang paling banyak menyita waktu dan berpotensi diotomatisasi, sehingga efisiensi meningkat dan biaya berkurang.
Mengapa ini penting
Membantu mengukur tingkat otomatisasi dan menemukan peluang untuk mengotomatisasi tugas manual, sehingga efisiensi meningkat dan biaya operasional berkurang.
Sumber data
Ditentukan dengan memeriksa apakah pengguna yang melakukan tindakan, misalnya 'sys_updated_by', merupakan pengguna sistem atau integrasi yang telah ditetapkan.
Contoh
truefalse
|
|||
|
Diselesaikan pada upaya pertama
IsFirstPassResolution
|
Penanda yang menunjukkan apakah permintaan diselesaikan pada upaya pertama tanpa dibuka kembali. | ||
|
Deskripsi
Atribut terhitung ini berupa penanda boolean yang bernilai 'true' hanya jika permintaan layanan diselesaikan dan ditutup tanpa pernah dibuka kembali. Atribut ini menjadi indikator penting untuk kualitas dan efektivitas penyelesaian oleh meja layanan. Metrik ini mendukung KPI Tingkat Penyelesaian pada Upaya Pertama. Tingkat yang tinggi menunjukkan layanan yang efisien dan berkualitas, sehingga kepuasan pelanggan meningkat. Analisis kasus yang tidak selesai pada upaya pertama dapat mengungkap akar masalah, seperti pelatihan yang kurang memadai, dokumentasi yang buruk, atau diagnosis awal yang keliru.
Mengapa ini penting
Mengukur kualitas dan efisiensi proses penyelesaian. Tingkat penyelesaian pada upaya pertama yang rendah menunjukkan masalah mendasar yang menyebabkan pengerjaan ulang dan kekecewaan pelanggan.
Sumber data
Dihitung pada tingkat kasus. Kasus dianggap selesai pada upaya pertama jika 'ReopenCount'-nya nol.
Contoh
truefalse
|
|||
|
Jumlah dibuka kembali
ReopenCount
|
Berapa kali permintaan layanan dibuka kembali setelah diselesaikan. | ||
|
Deskripsi
Atribut ini menghitung berapa kali permintaan layanan berpindah dari status selesai atau ditutup kembali ke status terbuka atau sedang dikerjakan. Jika jumlahnya lebih dari nol, berarti penyelesaian awal belum berhasil. Metrik ini menunjukkan adanya pengerjaan ulang dan menjadi komponen penting dalam KPI Tingkat Penyelesaian pada Upaya Pertama. Jumlah pembukaan kembali yang tinggi dapat menandakan kualitas penyelesaian yang kurang baik, pemenuhan yang belum tuntas, atau kesalahpahaman tentang kebutuhan pengguna. Semua ini membuat proses kurang efisien dan menurunkan kepuasan pengguna.
Mengapa ini penting
Mengukur pengerjaan ulang dan kualitas penyelesaian. Jumlah pembukaan kembali yang tinggi menunjukkan proses yang tidak efisien, tingkat penyelesaian pada upaya pertama yang rendah, dan kepuasan pelanggan yang menurun.
Sumber data
Tabel ServiceNow Request [sc_request] atau Request Item [sc_req_item], kolom 'reopen_count'.
Contoh
012
|
|||
|
Kanal
ContactType
|
Cara pemohon mengirimkan permintaan layanan. | ||
|
Deskripsi
Contact Type, atau kanal, menunjukkan cara permintaan layanan diajukan. Kanal yang umum mencakup portal layanan, email, telepon, atau peringatan otomatis. Informasi kanal penting untuk menganalisis variasi proses yang mungkin dipengaruhi oleh cara pengajuan. Misalnya, permintaan melalui portal mungkin lebih terstruktur dan otomatis sehingga lebih cepat diproses daripada permintaan melalui email. Analisis ini membantu mendorong penggunaan kanal yang lebih efisien.
Mengapa ini penting
Membantu mengetahui dampak kanal pengajuan terhadap efisiensi proses, tingkat otomatisasi, dan waktu siklus secara keseluruhan. Hasilnya dapat menjadi panduan untuk menyempurnakan interaksi dengan pengguna.
Sumber data
Tabel ServiceNow Request [sc_request] atau Interaction [interaction]. Nama kolomnya sering kali 'contact_type'.
Contoh
PortalEmailTeleponLayanan mandiri
|
|||
|
Kode penyelesaian
ResolutionCode
|
Kode yang mengelompokkan hasil akhir penyelesaian permintaan layanan. | ||
|
Deskripsi
Kode penyelesaian mengelompokkan cara permintaan layanan akhirnya diselesaikan. Contohnya, 'Dipenuhi oleh Otomatisasi', 'Kesalahan Pengguna', atau 'Tidak Lagi Diperlukan'. Atribut ini penting untuk dashboard Analisis Akar Penyebab Keterlambatan. Dengan menghubungkan kode penyelesaian dengan waktu siklus yang panjang atau tingkat pengerjaan ulang yang tinggi, analis dapat menemukan masalah sistemik. Misalnya, jika permintaan dengan kode 'Informasi Tidak Lengkap' selalu lambat, kemungkinan ada masalah pada tahap awal pengumpulan data.
Mengapa ini penting
Menyediakan data terstruktur tentang hasil penyelesaian, sehingga akar penyebab keterlambatan proses, pengerjaan ulang, dan inefisiensi lainnya dapat dianalisis.
Sumber data
Tabel ServiceNow Request Item [sc_req_item] atau tabel tugas terkait. Nama kolomnya biasanya 'close_code' atau 'resolution_code'.
Contoh
Berhasil diselesaikan secara permanenTidak berhasil diselesaikan, tidak dapat direproduksiPermintaan terpenuhiDibatalkan oleh pengguna
|
|||
|
Merupakan pengerjaan ulang
IsRework
|
Penanda terhitung yang menunjukkan apakah suatu aktivitas mengulang aktivitas sebelumnya dalam kasus yang sama. | ||
|
Deskripsi
Penanda boolean ini dihitung untuk menemukan pengulangan dalam permintaan layanan. Nilainya 'true' jika aktivitas yang sama sudah terjadi sebelumnya dalam kasus yang sama. Contohnya, permintaan ditugaskan kepada tim yang sama dua kali atau informasi diminta dari pengguna beberapa kali. Atribut ini penting untuk dashboard Serah Terima antarpetugas dan Insiden Pengerjaan Ulang, serta KPI Tingkat Pengerjaan Ulang Permintaan. Atribut ini membantu menampilkan dan mengukur secara langsung pengulangan proses yang tidak efisien, yang sering kali tidak terlihat dalam data keseluruhan.
Mengapa ini penting
Menandai dan mengukur pengerjaan ulang secara langsung, sehingga penyebab dan dampak pengulangan proses yang tidak efisien, yang menambah biaya dan waktu siklus, dapat dianalisis.
Sumber data
Dihitung saat transformasi data dengan memeriksa apakah nama aktivitas yang sama pernah muncul sebelumnya dalam kasus yang sama.
Contoh
falsetrue
|
|||
|
Skor kepuasan
SatisfactionScore
|
Penilaian kepuasan pelanggan yang diberikan pemohon saat permintaan ditutup. | ||
|
Deskripsi
Atribut ini mencatat skor kepuasan, biasanya pada skala 1-5, yang diberikan pengguna akhir setelah permintaan layanannya diselesaikan. Skor ini mengukur langsung kualitas layanan yang dirasakan pengguna. Data ini penting untuk dashboard Analisis Dampak terhadap Kepuasan Pelanggan. Anda dapat menghubungkan metrik proses, seperti waktu siklus, pengerjaan ulang, dan serah terima, dengan pengalaman pelanggan secara keseluruhan. Hubungan ini membantu menunjukkan manfaat bisnis dari perbaikan proses dengan mengaitkan efisiensi operasional dan hasil bagi pelanggan.
Mengapa ini penting
Menghubungkan metrik kinerja proses dengan hasil bagi pelanggan, sehingga dampak inefisiensi proses terhadap pengalaman pengguna dapat diukur.
Sumber data
Biasanya terdapat di tabel Survey terkait [asmt_assessment_instance], yang terhubung dengan permintaan awal.
Contoh
5431
|
|||
|
Waktu selesai
EndTime
|
Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa selesai. | ||
|
Deskripsi
Waktu Selesai menandai akhir suatu aktivitas. Nilainya menggunakan stempel waktu aktivitas berikutnya dalam urutan, yang sekaligus menutup durasi aktivitas saat ini. Atribut ini penting untuk menghitung waktu yang diperlukan pada setiap langkah proses. Dengan membandingkan Waktu Mulai dan Waktu Selesai suatu aktivitas, analis dapat menghitung waktu pemrosesan dan waktu tunggu. Perhitungan ini menjadi dasar untuk menemukan hambatan, mengukur efisiensi sumber daya, dan memantau kinerja terhadap target waktu.
Mengapa ini penting
Atribut ini diperlukan untuk menghitung durasi setiap aktivitas, yang menjadi bagian utama analisis kinerja, identifikasi hambatan, dan kajian pemanfaatan sumber daya.
Sumber data
Atribut turunan ini dihitung menggunakan 'StartTime' dari peristiwa berikutnya dalam kasus yang sama.
Contoh
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
|
Waktu siklus kasus
CaseCycleTime
|
Total waktu sejak permintaan layanan dibuat hingga akhirnya ditutup. | ||
|
Deskripsi
Waktu siklus kasus adalah metrik terhitung yang mengukur durasi total permintaan layanan, dari waktu kejadian pertama hingga waktu kejadian terakhir. Metrik ini menunjukkan waktu pemrosesan dari awal hingga akhir, dari sudut pandang pelanggan. Metrik ini menjadi KPI utama untuk mengukur efisiensi proses secara keseluruhan. Dasbor tingkat tinggi menggunakannya untuk memantau kinerja berdasarkan target dan melihat tren dari waktu ke waktu. Anda juga dapat mengelompokkan data berdasarkan dimensi seperti kategori atau prioritas untuk mengetahui jenis permintaan yang paling lama diproses.
Mengapa ini penting
KPI penting ini mengukur kinerja proses dari awal hingga akhir. Metrik ini diperlukan untuk pemantauan tingkat tinggi, pembandingan kinerja, dan menemukan area yang perlu diperbaiki.
Sumber data
Dihitung dengan mengurangi 'StartTime' minimum dari 'EndTime' maksimum untuk setiap 'ServiceRequestID' yang unik.
Contoh
2 10:30:000 04:15:2210 00:05:00
|
|||
Aktivitas manajemen permintaan layanan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Informasi diminta dari pengguna
|
Terjadi saat agen pemenuhan memerlukan informasi tambahan dari pemohon awal untuk melanjutkan pekerjaan. Biasanya, peristiwa ini disimpulkan saat status permintaan berubah menjadi 'Awaiting User Info' atau status serupa. | ||
|
Mengapa ini penting
Aktivitas ini penting untuk dasbor 'Analisis Keterlambatan Informasi dari Pemohon'. Dasbor ini membantu mengukur waktu yang terbuang saat menunggu masukan dari pengguna.
Sumber data
Disimpulkan dari perubahan kolom state pada sc_req_item menjadi status 'menunggu informasi' yang ditetapkan. Perubahan dicatat di tabel sys_audit.
Pengumpulan data
Temukan stempel waktu saat sc_req_item.state berubah menjadi 'Awaiting User Info'.
Jenis peristiwa
inferred
|
|||
|
Permintaan disetujui
|
Aktivitas ini menandakan bahwa permintaan telah disetujui secara resmi dan dapat dilanjutkan ke tahap pemenuhan. Peristiwa tercatat saat pemberi persetujuan mengubah status rekaman persetujuan terkait menjadi 'approved'. | ||
|
Mengapa ini penting
Tonggak penting ini menandai peralihan dari tahap persetujuan ke tahap pemenuhan. Analisis waktu yang diperlukan untuk mencapai tahap ini penting untuk memahami keterlambatan sebelum pemenuhan.
Sumber data
Disimpulkan dari perubahan kolom state pada rekaman sysapproval_approver terkait menjadi 'approved', yang kemudian memicu perubahan status pada sc_req_item.
Pengumpulan data
Temukan stempel waktu saat sysapproval_approver.state berubah menjadi 'approved'.
Jenis peristiwa
inferred
|
|||
|
Permintaan ditugaskan ke agen
|
Aktivitas ini terjadi saat permintaan layanan ditugaskan kepada agen tertentu. Peristiwa tercatat dengan memantau perubahan pada kolom 'Assigned to' di permintaan atau tugas pemenuhannya. | ||
|
Mengapa ini penting
Data ini penting untuk mengukur serah terima, menghitung beban kerja tiap agen, dan menganalisis waktu antre sebelum agen mulai menangani permintaan.
Sumber data
Disimpulkan dari perubahan pada kolom assigned_to di tabel sc_req_item atau sc_task. Riwayat perubahan dicatat di tabel sys_audit.
Pengumpulan data
Lacak perubahan pada kolom assigned_to di sys_audit.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan dibuat
|
Aktivitas ini menandai awal siklus permintaan layanan. Aktivitas tercatat saat pengguna mengirimkan permintaan melalui katalog layanan. Sistem mencatatnya sebagai peristiwa pembuatan rekaman baru di tabel sc_req_item (Requested Item). | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama proses. Data ini penting untuk menghitung waktu siklus keseluruhan serta menganalisis volume dan pola pengajuan permintaan.
Sumber data
Peristiwa ini tercatat secara langsung dari stempel waktu pembuatan (kolom sys_created_on) pada rekaman di tabel sc_req_item.
Pengumpulan data
Gunakan stempel waktu sys_created_on dari rekaman sc_req_item.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan diselesaikan
|
Aktivitas ini menunjukkan bahwa agen pemenuhan telah menyelesaikan pekerjaan dan memberikan solusi. Peristiwa tercatat saat status permintaan diperbarui menjadi 'Resolved' atau status serupa. | ||
|
Mengapa ini penting
Tonggak penting ini biasanya menghentikan penghitungan waktu SLA. Peristiwa ini menandai berakhirnya pekerjaan pemenuhan aktif dan menjadi bagian penting dalam penghitungan total waktu penyelesaian.
Sumber data
Disimpulkan saat kolom state pada sc_req_item diperbarui menjadi 'Resolved' atau status akhir serupa sebelum permintaan ditutup sepenuhnya. Perubahan dicatat di tabel sys_audit.
Pengumpulan data
Temukan stempel waktu saat sc_req_item.state berubah menjadi 'Resolved'.
Jenis peristiwa
inferred
|
|||
|
Permintaan layanan ditutup
|
Menandai akhir siklus permintaan layanan secara definitif. Biasanya, permintaan ditutup secara otomatis setelah berada dalam status 'Resolved' selama jangka waktu tertentu. Selama periode ini, pengguna masih dapat membuka kembali permintaan. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir utama yang menandakan proses berhasil. Jeda waktu antara 'Resolved' dan 'Closed' juga dapat dianalisis untuk memahami kebijakan penutupan otomatis.
Sumber data
Disimpulkan saat kolom state pada sc_req_item diperbarui menjadi status akhir, seperti 'Closed Complete'. Perubahan ini dicatat di tabel sys_audit.
Pengumpulan data
Temukan stempel waktu saat sc_req_item.state berubah menjadi 'Closed Complete'.
Jenis peristiwa
inferred
|
|||
|
Informasi diberikan oleh pengguna
|
Aktivitas ini menandai saat pemohon memberikan informasi yang diperlukan. Peristiwa ini disimpulkan saat permintaan keluar dari status 'Awaiting User Info' dan kembali ke status aktif, seperti 'Work in Progress'. | ||
|
Mengapa ini penting
Jika dipasangkan dengan aktivitas 'Informasi diminta dari pengguna', aktivitas ini membantu mengukur keterlambatan akibat menunggu pengguna secara akurat dan menilai efisiensi komunikasi.
Sumber data
Disimpulkan dari perubahan kolom state pada sc_req_item dari status 'menunggu informasi' ke status aktif. Perubahan ini sering dipicu saat pengguna menambahkan komentar atau membalas email.
Pengumpulan data
Temukan stempel waktu saat status berubah dari 'Awaiting User Info' menjadi 'Work in Progress'.
Jenis peristiwa
inferred
|
|||
|
Permintaan dibatalkan
|
Aktivitas ini menjadi status akhir bagi permintaan yang dibatalkan sebelum selesai, baik oleh pengguna maupun agen. Peristiwa tercatat saat status permintaan diatur menjadi 'Cancelled' atau 'Closed Cancelled'. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir utama yang menandakan proses tidak berhasil. Analisis alasan pembatalan permintaan dapat memberi wawasan tentang kebutuhan pengguna, inefisiensi proses, atau perubahan prioritas bisnis.
Sumber data
Disimpulkan saat kolom state pada sc_req_item diperbarui menjadi status akhir pembatalan, seperti 'Closed Cancelled'. Perubahan dicatat di tabel sys_audit.
Pengumpulan data
Temukan stempel waktu saat sc_req_item.state berubah menjadi 'Cancelled'.
Jenis peristiwa
inferred
|
|||
|
Permintaan dibuka kembali
|
Aktivitas ini mencatat permintaan yang sebelumnya berstatus selesai, lalu dikembalikan ke status terbuka. Peristiwa ini disimpulkan dari perubahan status 'Resolved' kembali menjadi 'Work in Progress' atau status serupa. | ||
|
Mengapa ini penting
Ini adalah ukuran langsung pengerjaan ulang dan penting untuk menghitung KPI 'Tingkat Penyelesaian pada Penanganan Pertama'. Angka yang tinggi menunjukkan kualitas solusi yang rendah atau penyelesaian yang belum tuntas.
Sumber data
Disimpulkan dari perubahan kolom state pada sc_req_item, dari status selesai atau ditutup kembali ke status terbuka atau sedang dikerjakan. Perubahan ini dicatat di sys_audit.
Pengumpulan data
Deteksi perubahan status dari 'Resolved' menjadi 'Work in Progress' di sys_audit.
Jenis peristiwa
inferred
|
|||
|
Permintaan ditolak
|
Aktivitas ini menandai permintaan yang secara resmi ditolak pada tahap persetujuan. Ini adalah jalur alternatif menuju penutupan dan tercatat saat pemberi persetujuan mengubah status permintaan menjadi 'rejected'. | ||
|
Mengapa ini penting
Pelacakan penolakan membantu menemukan permintaan yang tidak valid atau salah tujuan, masalah dalam proses pengajuan, serta jalur pengecualian penting untuk dianalisis.
Sumber data
Disimpulkan dari perubahan kolom state pada rekaman sysapproval_approver terkait menjadi 'rejected'. Perubahan ini biasanya mengatur sc_req_item induk ke status ditutup, tidak lengkap.
Pengumpulan data
Temukan stempel waktu saat sysapproval_approver.state berubah menjadi 'rejected'.
Jenis peristiwa
inferred
|
|||
|
Permintaan ditugaskan ke grup
|
Menunjukkan bahwa permintaan layanan telah ditugaskan ke tim atau grup pemenuhan tertentu. Peristiwa ini disimpulkan dengan mendeteksi perubahan pada kolom grup penugasan di item permintaan atau tugas terkait. | ||
|
Mengapa ini penting
Pelacakan penugasan grup membantu menganalisis pembagian beban kerja antar tim dan menemukan keterlambatan sebelum permintaan diteruskan ke petugas pemenuhan yang tepat.
Sumber data
Disimpulkan dari perubahan pada kolom assignment_group di tabel sc_req_item atau sc_task. Riwayat perubahan dicatat di tabel sys_audit.
Pengumpulan data
Lacak perubahan pada kolom assignment_group di sys_audit.
Jenis peristiwa
inferred
|
|||
|
Persetujuan diminta
|
Menandai saat permintaan layanan diajukan untuk mendapat persetujuan dari manajer atau pemberi persetujuan yang ditunjuk. Biasanya, peristiwa ini disimpulkan saat status permintaan berubah menjadi 'Pending Approval' atau status serupa. | ||
|
Mengapa ini penting
Pelacakan persetujuan membantu menemukan hambatan dalam proses persetujuan dan mengukur berapa lama permintaan menunggu otorisasi sebelum pemenuhan dapat dimulai.
Sumber data
Disimpulkan dari perubahan kolom state pada sc_req_item menjadi status menunggu persetujuan, atau dari pembuatan rekaman terkait di tabel sysapproval_approver. Perubahan dicatat di tabel sys_audit.
Pengumpulan data
Temukan stempel waktu saat sc_req_item.state berubah menjadi 'Pending Approval'.
Jenis peristiwa
inferred
|
|||
|
Tugas pemenuhan dibuat
|
Menandai pembuatan item kerja atau tugas tertentu yang diperlukan untuk memenuhi permintaan layanan. Peristiwa ini dicatat secara eksplisit saat rekaman baru dibuat di tabel Catalog Task. | ||
|
Mengapa ini penting
Untuk permintaan yang kompleks, analisis pembuatan dan penyelesaian tiap tugas memberikan gambaran lebih terperinci tentang proses pemenuhan dan lokasi terjadinya keterlambatan.
Sumber data
Peristiwa ini tercatat secara langsung dari stempel waktu pembuatan (kolom sys_created_on) pada rekaman di tabel sc_task yang terhubung ke sc_req_item.
Pengumpulan data
Gunakan stempel waktu sys_created_on dari rekaman sc_task.
Jenis peristiwa
explicit
|
|||
|
Vendor eksternal dilibatkan
|
Menandai penyerahan permintaan layanan atau salah satu tugasnya kepada vendor pihak ketiga untuk dipenuhi. Peristiwa ini dapat disimpulkan dari penugasan ke grup khusus vendor atau dari penanda pada permintaan. | ||
|
Mengapa ini penting
Aktivitas ini memungkinkan analisis kinerja vendor dan dampaknya terhadap keseluruhan siklus permintaan. Analisis ini penting untuk dasbor 'Siklus Pelibatan Vendor Eksternal'.
Sumber data
Peristiwa ini biasanya disimpulkan. Dasarnya dapat berupa assignment_group yang diatur ke grup vendor atau kolom penanda tertentu pada rekaman sc_req_item atau sc_task.
Pengumpulan data
Temukan perubahan assignment_group ke grup vendor yang dikenal.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi data
Siap memulai?
Gunakan templat ini untuk memulai inisiatif process mining dan meningkatkan efisiensi manajemen permintaan layanan. Mulai perbaikan alur kerja Anda hari ini agar permintaan lebih cepat diselesaikan dan kepuasan pelanggan meningkat.
Perbaiki manajemen permintaan layanan sekarang
Capai otomatisasi 70% dan selesaikan permintaan layanan lebih cepat.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.