Templat data pengelolaan permintaan layanan
Templat data pengelolaan permintaan layanan
Ini template data umum kami untuk process mining Pengelolaan Permintaan Layanan. Gunakan template khusus sistem untuk mendapatkan panduan yang lebih terarah.
Pilih sistem tertentu- Kolom data standar untuk analisis yang konsisten di berbagai sistem.
- Aktivitas proses utama yang dipetakan untuk menemukan proses secara menyeluruh.
- Dasar yang fleksibel untuk mengoptimalkan alur kerja permintaan layanan apa pun.
Atribut pengelolaan permintaan layanan
| Nama | Deskripsi | ||
|---|---|---|---|
| Aktivitas Activity | Nama tugas, peristiwa, atau perubahan status tertentu yang terjadi selama siklus hidup permintaan layanan. | ||
| Deskripsi Atribut Aktivitas menjelaskan langkah atau tindakan tertentu yang dilakukan pada permintaan layanan. Aktivitas ini membentuk urutan proses, misalnya 'Permintaan Dibuat', 'Permintaan Ditugaskan', 'Pekerjaan Berlangsung', dan 'Permintaan Ditutup'. Setiap aktivitas menandai titik waktu tertentu dalam perjalanan permintaan layanan. Analisis aktivitas merupakan inti process mining. Analisis ini membantu menemukan dan menampilkan alur proses yang sebenarnya. Dengan memeriksa urutan dan frekuensi aktivitas, analis dapat menemukan jalur yang umum, penyimpangan dari proses standar, hambatan yang membuat permintaan tertahan, serta pekerjaan ulang akibat langkah yang tidak perlu diulang. Mengapa ini penting Atribut ini menentukan langkah-langkah proses, sehingga alur proses yang sebenarnya, hambatan, dan penyimpangan dapat ditemukan. Sumber data Biasanya diambil dari log perubahan status, tabel peristiwa, atau jejak audit yang terkait dengan objek permintaan layanan. Contoh Permintaan layanan dibuatPermintaan ditugaskanPermintaan diselesaikanPermintaan layanan ditutup | |||
| ID Permintaan Layanan CaseId | Pengenal unik untuk setiap kasus permintaan layanan. ID ini digunakan untuk melacak satu permintaan sejak dibuat hingga ditutup. | ||
| Deskripsi ID Permintaan Layanan adalah kunci utama yang membedakan setiap permintaan layanan selama siklus hidupnya. ID ini berfungsi sebagai pengenal kasus dan menghubungkan semua aktivitas, perubahan status, serta atribut terkait menjadi satu rangkaian proses. Dalam analisis process mining, ID ini menjadi dasar untuk merekonstruksi perjalanan setiap permintaan dari awal hingga akhir. Dengan mengelompokkan semua peristiwa berdasarkan CaseId yang sama, analis dapat melihat alur proses, menghitung durasi kasus, dan menemukan perbedaan dalam penanganan permintaan. ID ini menjadi landasan analisis proses pengelolaan permintaan layanan. Mengapa ini penting ID ini penting untuk menghubungkan semua peristiwa dalam satu permintaan layanan, sehingga Anda dapat melihat proses secara utuh dari awal hingga akhir. Sumber data Biasanya terdapat di header atau tabel transaksi utama untuk permintaan layanan. Contoh SR-2023-00123REQ0045891TICKET-98765 | |||
| Waktu Mulai StartTime | Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa dimulai. | ||
| Deskripsi Waktu Mulai mencatat tanggal dan waktu tepat saat suatu aktivitas dimulai. Stempel waktu ini penting untuk mengurutkan peristiwa secara kronologis serta menghitung durasi aktivitas dan siklus hidup kasus secara keseluruhan. Setiap aktivitas dalam proses sebaiknya memiliki Waktu Mulai agar log peristiwa tersusun akurat. Dalam analisis proses, Waktu Mulai digunakan untuk menghitung indikator kinerja utama seperti waktu siklus, waktu tunggu antaraktivitas, dan waktu pemrosesan aktivitas. Data ini membantu menyusun gambaran proses berdasarkan waktu, menyoroti keterlambatan, dan menemukan langkah yang paling banyak menyita waktu. Stempel waktu yang akurat menjadi dasar analisis kinerja. Mengapa ini penting Stempel waktu ini penting untuk mengurutkan peristiwa dengan benar dan menghitung metrik waktu, seperti waktu siklus dan hambatan. Sumber data Terdapat di tabel log peristiwa atau jejak audit. Biasanya dicatat sebagai 'tanggal pembuatan' atau 'stempel waktu peristiwa' untuk setiap catatan aktivitas. Contoh 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu yang menunjukkan kapan terakhir kali data diperbarui dari sistem sumber. | ||
| Deskripsi Pembaruan Data Terakhir mencatat waktu ekstraksi atau pembaruan data terbaru. Informasi ini membantu pengguna mengetahui seberapa baru data yang sedang dianalisis, sehingga mereka dapat menilai apakah analisis mencerminkan kondisi terkini atau kondisi pada waktu sebelumnya. Atribut ini penting untuk pemantauan operasional dan pelaporan karena memberi konteks tentang kebaruan wawasan yang dihasilkan. Informasi ini membantu pengguna memercayai data dan mengambil keputusan berdasarkan seberapa baru data tersebut. Misalnya, dasbor dengan data yang terakhir diperbarui seminggu lalu perlu ditafsirkan berbeda dari dasbor yang diperbarui satu jam lalu. Mengapa ini penting Menunjukkan kebaruan data, yang penting agar analisis tetap relevan dan menggunakan informasi terkini. Sumber data Kolom metadata ini biasanya dibuat dan disimpan selama proses ekstraksi data (ETL). Contoh 2023-10-27T08:00:00Z2023-10-26T23:59:59Z | |||
| Sistem Sumber SourceSystem | Menunjukkan sistem atau aplikasi asal data permintaan layanan. | ||
| Deskripsi Atribut Sistem Sumber menunjukkan nama platform IT Service Management (ITSM) atau aplikasi lain tempat data diambil. Jika lingkungan Anda menggunakan beberapa sistem, kolom ini membantu membedakan sumber data dan memperjelas asal-usul data. Atribut ini mungkin tidak digunakan langsung dalam sebagian besar analisis alur proses, tetapi penting untuk tata kelola data, validasi, dan pemecahan masalah. Saat menggabungkan data dari beberapa sumber, analis dapat menggunakan atribut ini untuk memisahkan tampilan proses berdasarkan sistem. Dengan begitu, perbedaan pelaksanaan proses atau kualitas data antarplatform dapat terlihat. Mengapa ini penting Penting untuk tata kelola data dan pemecahan masalah. Atribut ini memperjelas asal data, terutama jika beberapa sistem terintegrasi digunakan. Sumber data Nilai ini biasanya ditambahkan saat ekstraksi data (ETL), bukan sebagai kolom bawaan di sistem sumber. Contoh ServiceNowJira Service ManagementZendesk | |||
| Agen yang Ditugaskan AssignedAgent | Pengguna atau agen yang saat ini ditugaskan untuk menangani permintaan layanan. | ||
| Deskripsi Agen yang Ditugaskan adalah orang yang bertanggung jawab menangani permintaan layanan pada waktu tertentu. Selama siklus hidupnya, permintaan dapat ditugaskan kepada agen yang berbeda. Atribut ini penting untuk analisis kinerja dan beban kerja. Organisasi dapat mengukur dan membandingkan kinerja setiap agen, termasuk rata-rata waktu penyelesaian dan jumlah permintaan yang ditangani. Atribut ini juga membantu menganalisis pengalihan antaragen, yang dapat menunjukkan masalah dalam triase awal, spesialisasi agen, atau pembagian beban kerja. Mengapa ini penting Memungkinkan analisis kinerja setiap agen, pembagian beban kerja, dan frekuensi pengalihan permintaan antaragen. Sumber data Tersedia pada catatan permintaan layanan. Perubahan pada kolom ini biasanya dicatat dalam log audit atau tabel riwayat. Contoh John SmithJane Doeagent_user_123 | |||
| Batas Waktu SLA SlaDueDate | Tanggal dan waktu target penyelesaian permintaan sesuai dengan Perjanjian Tingkat Layanan (SLA). | ||
| Deskripsi Batas Waktu SLA adalah stempel waktu target yang dihitung berdasarkan perjanjian tingkat layanan untuk permintaan tersebut. Penentuannya mempertimbangkan faktor seperti prioritas, jenis, dan waktu pembuatan permintaan, lalu menetapkan batas waktu penyelesaian yang diharapkan. Atribut ini menjadi dasar analisis kepatuhan SLA. Dengan membandingkan waktu penyelesaian aktual dengan Batas Waktu SLA, organisasi dapat mengetahui apakah permintaan diselesaikan tepat waktu atau SLA terlampaui. Ini merupakan KPI penting untuk mengukur kualitas layanan dan menemukan masalah sistemik yang menyebabkan keterlambatan serta pelanggaran SLA. Mengapa ini penting Atribut ini menjadi patokan untuk mengukur kinerja. Gunakan untuk menghitung tingkat kepatuhan SLA dan menemukan permintaan yang melewati batas waktu. Sumber data Sering kali berupa kolom hasil perhitungan pada catatan permintaan layanan, berdasarkan kebijakan SLA yang berlaku. Contoh 2023-10-28T17:00:00Z2023-11-01T09:00:00Z | |||
| Jenis Layanan ServiceType | Kategori atau jenis layanan yang diminta pengguna. | ||
| Deskripsi Jenis Layanan mengelompokkan permintaan berdasarkan layanan yang dibutuhkan. Jenisnya dapat berupa permintaan perangkat keras baru, akses perangkat lunak, pertanyaan umum, atau dukungan teknis. Pengelompokan ini membantu meneruskan permintaan ke tim yang tepat dan memahami kebutuhan akan berbagai layanan. Dalam analisis proses, Jenis Layanan menjadi dimensi penting untuk memisahkan data. Dengan memfilter peta proses berdasarkan jenis layanan, organisasi dapat menemukan bahwa jenis permintaan tertentu mengikuti proses yang sangat berbeda, memiliki waktu siklus lebih lama, atau lebih sering mengalami pekerjaan ulang. Temuan ini membantu organisasi melakukan perbaikan proses yang terarah untuk kategori layanan tertentu. Mengapa ini penting Memungkinkan Anda memfilter dan membandingkan proses untuk berbagai kategori permintaan, serta menemukan hambatan atau inefisiensi khusus pada setiap jenis. Sumber data Kolom standar pada catatan permintaan layanan, yang sering terhubung ke katalog layanan. Contoh Permintaan Perangkat KerasAkses Perangkat LunakPengaturan Ulang Kata SandiPertanyaan Umum | |||
| Prioritas Permintaan RequestPriority | Tingkat prioritas yang diberikan kepada permintaan, yang menunjukkan dampak dan urgensinya bagi bisnis. | ||
| Deskripsi Prioritas Permintaan membantu tim dukungan menentukan urutan penanganan permintaan. Prioritas biasanya ditetapkan berdasarkan dampak permintaan terhadap bisnis dan tingkat urgensinya. Tingkat prioritas yang umum meliputi Rendah, Sedang, Tinggi, dan Kritis. Atribut ini penting untuk analisis kinerja dan alokasi sumber daya. Analis dapat membandingkan waktu siklus dan kepatuhan SLA pada setiap tingkat prioritas untuk memastikan permintaan berprioritas tinggi ditangani dengan semestinya. Atribut ini juga membantu menemukan apakah permintaan berprioritas rendah terabaikan atau tim dukungan mengikuti sistem prioritas dengan benar. Mengapa ini penting Penting untuk menganalisis apakah permintaan ditangani sesuai kepentingannya bagi bisnis dan memahami dampak prioritas terhadap waktu penyelesaian. Sumber data Biasanya berupa kolom standar pada catatan utama permintaan layanan. Contoh RendahSedangTinggiKritis | |||
| Status Permintaan RequestStatus | Status permintaan layanan saat ini atau pada waktu terjadinya suatu peristiwa, misalnya 'Sedang Diproses' atau 'Ditutup'. | ||
| Deskripsi Status Permintaan menunjukkan kondisi permintaan layanan pada titik tertentu dalam siklus hidupnya. Status yang umum antara lain Baru, Sedang Diproses, Tertunda, Diselesaikan, dan Ditutup. Atribut ini menunjukkan posisi permintaan dalam keseluruhan proses. Analisis Status Permintaan penting untuk memahami alur proses dan perubahan status. Anda dapat menggunakannya untuk memfilter kasus, menemukan permintaan yang tertahan pada status tertentu, dan mengukur waktu yang dihabiskan di setiap status. Misalnya, dengan menganalisis berapa lama permintaan berstatus 'Tertunda', Anda dapat menemukan keterlambatan akibat menunggu informasi dari pengguna atau tim eksternal. Mengapa ini penting Atribut ini membantu menganalisis berapa lama permintaan berada di setiap status dan menyoroti hambatan atau keterlambatan dalam proses. Sumber data Tersedia di tabel utama permintaan layanan atau log riwayat status. Contoh Sedang DiprosesMenunggu PelangganDiselesaikanDitutup | |||
| Tim yang Ditugaskan AssignedTeam | Grup atau tim dukungan yang saat ini ditugaskan untuk menangani permintaan layanan. | ||
| Deskripsi Tim yang Ditugaskan adalah grup dukungan yang bertanggung jawab menangani permintaan layanan. Permintaan sering diteruskan antarberbagai tim, seperti help desk Level 1, tim jaringan, atau tim pengembangan perangkat lunak, sesuai keahlian yang dibutuhkan. Analisis serah terima antar tim merupakan bagian penting dari process mining untuk manajemen layanan. Atribut ini membantu menampilkan pengalihan dari satu tim ke tim lain, sehingga kesenjangan komunikasi atau keterlambatan dapat ditemukan. Atribut ini juga memungkinkan perbandingan kinerja antar tim, termasuk efisiensi, volume permintaan, dan kemampuan menyelesaikan permintaan tanpa eskalasi lebih lanjut. Mengapa ini penting Penting untuk menganalisis serah terima proses antar tim, menemukan keterlambatan pengalihan, dan membandingkan kinerja tim. Sumber data Kolom standar pada catatan permintaan layanan. Perubahan pada kolom ini dicatat dalam log audit. Contoh Meja Layanan L1Operasional JaringanDukungan Sistem SDM | |||
| Apakah SLA Terlampaui IsSlaBreached | Penanda yang menunjukkan apakah permintaan layanan diselesaikan setelah batas waktu SLA. | ||
| Deskripsi Atribut boolean ini menunjukkan apakah permintaan layanan tidak memenuhi perjanjian tingkat layanan yang ditetapkan. Nilainya true jika permintaan diselesaikan setelah 'SlaDueDate', dan false jika tidak. Atribut ini menyederhanakan pelaporan dan analisis kepatuhan SLA. Anda tidak perlu membandingkan tanggal di setiap kueri, cukup gunakan penanda ini untuk memfilter dan mengelompokkan data. Ini merupakan metrik utama untuk dasbor kinerja SLA dan membantu Anda dengan cepat mengetahui jumlah serta persentase permintaan yang tidak memenuhi target layanan. Mengapa ini penting Menyediakan penanda yang jelas dan sederhana untuk analisis kinerja SLA, sehingga permintaan yang melewati batas waktu mudah difilter dan dilaporkan. Sumber data Atribut turunan ini dihitung saat transformasi data dengan membandingkan stempel waktu penyelesaian akhir dengan kolom 'SlaDueDate'. Contoh truefalse | |||
| Departemen Pemohon RequestorDepartment | Departemen atau unit bisnis tempat pengguna yang mengajukan permintaan bekerja. | ||
| Deskripsi Atribut ini menunjukkan departemen atau unit bisnis orang yang mengajukan permintaan layanan. Informasi ini memberi konteks organisasi pada permintaan. Analisis permintaan berdasarkan departemen dapat membantu menemukan kebutuhan, tren, atau masalah khusus di departemen tertentu. Misalnya, banyaknya permintaan dengan jenis tertentu dari departemen Keuangan dapat menunjukkan perlunya pelatihan khusus atau perbaikan sistem. Informasi ini juga mendukung pelaporan alokasi biaya dan membantu memahami kebutuhan layanan TI di seluruh organisasi. Mengapa ini penting Memberi konteks organisasi agar pola permintaan dan kebutuhan layanan dapat dianalisis berdasarkan unit bisnis. Sumber data Informasi ini biasanya diambil dari profil pengguna pemohon di direktori karyawan atau sistem ITSM. Contoh KeuanganSumber Daya ManusiaPemasaranOperasional TI | |||
| Jumlah Pengalihan ReassignmentCount | Jumlah total pengalihan permintaan antaragen atau antartim. | ||
| Deskripsi Jumlah Pengalihan menghitung berapa kali permintaan layanan dipindahkan dari satu agen atau tim ke agen atau tim lain. Jumlah yang tinggi dapat menunjukkan masalah seperti pengalihan awal yang keliru, kurangnya pengetahuan agen, atau kepemilikan proses yang tidak jelas. Metrik ini menjadi indikator penting inefisiensi proses. Dalam process mining, metrik ini mengukur seberapa sering permintaan berpindah-pindah. Analisis kasus dengan jumlah pengalihan tinggi dapat mengungkap peluang untuk memperbaiki proses triase, meningkatkan pelatihan agen, atau memperjelas tanggung jawab tim agar permintaan diarahkan dengan benar sejak awal. Mengapa ini penting Metrik penting untuk menemukan inefisiensi proses. Jumlah pengalihan yang tinggi sering berkaitan dengan waktu penyelesaian yang lebih lama dan ketidakpuasan pengguna. Sumber data Metrik ini dihitung dengan menghitung berapa kali kolom 'AssignedAgent' atau 'AssignedTeam' berubah untuk 'CaseId' tertentu. Contoh 0135 | |||
| Kanal Pengajuan SubmissionChannel | Metode atau kanal yang digunakan untuk mengajukan permintaan layanan. | ||
| Deskripsi Kanal Pengajuan menunjukkan cara permintaan layanan dibuat, misalnya melalui portal layanan mandiri, email, telepon, atau API. Setiap kanal mungkin memiliki proses dan ekspektasi pengguna yang berbeda. Analisis proses berdasarkan kanal pengajuan dapat mengungkap wawasan penting. Misalnya, permintaan melalui portal layanan mandiri mungkin lebih terstruktur dan lebih cepat diselesaikan daripada permintaan melalui email, yang mungkin memerlukan entri data manual. Analisis ini membantu organisasi mendorong penggunaan kanal yang lebih efisien atau memperbaiki proses pada kanal yang kurang efisien. Mengapa ini penting Membantu mengetahui apakah metode pengajuan memengaruhi efisiensi proses, waktu penyelesaian, atau tingkat penyelesaian pada kontak pertama. Sumber data Biasanya tersedia sebagai kolom standar pada catatan permintaan layanan. Contoh PortalEmailTeleponChat | |||
| Kode Penyelesaian ResolutionCode | Kode atau kategori yang menunjukkan hasil akhir atau alasan permintaan ditutup. | ||
| Deskripsi Kode Penyelesaian menyediakan cara terstruktur untuk mengelompokkan hasil permintaan layanan. Contohnya meliputi 'Diselesaikan oleh Pengguna', 'Perangkat Keras Diganti', 'Perangkat Lunak Diterapkan', atau 'Permintaan Duplikat'. Agen biasanya mengisi informasi ini saat menutup permintaan. Kode ini berguna untuk analisis akar masalah. Dengan menganalisis frekuensi setiap kode penyelesaian, organisasi dapat menemukan masalah berulang, solusi yang umum, serta peluang untuk membuat artikel basis pengetahuan atau solusi otomatis. Misalnya, banyaknya penyelesaian dengan kode 'Pengaturan Ulang Kata Sandi' dapat menjadi alasan untuk berinvestasi pada alat pengaturan ulang kata sandi mandiri. Mengapa ini penting Mendukung analisis akar masalah dengan mengelompokkan cara permintaan diselesaikan, sehingga tren dan peluang untuk menangani masalah secara proaktif dapat ditemukan. Sumber data Kolom ini biasanya diisi secara manual oleh agen saat menyelesaikan atau menutup permintaan layanan. Contoh DipenuhiKesalahan PenggunaDibatalkan oleh PenggunaTidak Lagi Diperlukan | |||
| Waktu Selesai EndTime | Stempel waktu yang menunjukkan kapan suatu aktivitas atau peristiwa selesai. | ||
| Deskripsi Waktu Selesai mencatat tanggal dan waktu tepat saat suatu aktivitas berakhir. Waktu Mulai menandai awal, sedangkan Waktu Selesai menandai akhir, sehingga durasi satu langkah proses dapat diketahui. Tidak semua peristiwa memiliki Waktu Selesai tersendiri karena beberapa peristiwa terjadi seketika. Atribut ini penting untuk menghitung waktu pemrosesan setiap aktivitas. Dengan mengurangi Waktu Mulai dari Waktu Selesai, analis dapat mengukur berapa lama agen atau sistem benar-benar mengerjakan tugas. Hasilnya membantu menemukan aktivitas yang paling banyak menyita waktu dan layak diprioritaskan untuk perbaikan atau otomatisasi. Mengapa ini penting Memungkinkan Anda menghitung waktu pemrosesan aktivitas dan menemukan langkah proses tertentu yang paling banyak menyita waktu. Sumber data Terdapat di tabel log peristiwa atau jejak audit. Jika tidak tersedia secara langsung, nilainya mungkin perlu diturunkan dari Waktu Mulai aktivitas berikutnya. Contoh 2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z | |||
Aktivitas pengelolaan permintaan layanan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Informasi diminta | Agen pemenuhan memerlukan informasi tambahan dari pemohon untuk melanjutkan pekerjaan. Biasanya, permintaan diubah ke status menunggu atau ditahan, sehingga waktu pemenuhan berhenti sementara. | ||
| Mengapa ini penting Aktivitas ini menunjukkan adanya ketergantungan pada pemohon dan menjadi salah satu penyebab utama waktu siklus yang panjang. Melacak frekuensi dan durasinya dapat mengungkap kesenjangan komunikasi. Sumber data Aktivitas ini disimpulkan dari perubahan status menjadi 'Pending Customer', 'Awaiting User Information', atau 'On-Hold'. Pengumpulan data Gunakan stempel waktu saat status permintaan berubah menjadi status yang menunjukkan bahwa permintaan sedang menunggu pengguna. Jenis peristiwa inferred | |||
| Pengerjaan sedang berlangsung | Agen atau tim yang ditugaskan telah mulai mengerjakan pemenuhan permintaan layanan. Ini menunjukkan bahwa permintaan telah berpindah dari antrean ke status pengerjaan aktif. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya waktu pemenuhan aktif. Menganalisis durasi tahap ini penting untuk menemukan inefisiensi proses. Sumber data Aktivitas ini biasanya disimpulkan dari perubahan status pertama menjadi 'In Progress' atau 'Active' setelah permintaan ditugaskan. Pengumpulan data Catat stempel waktu perubahan status pertama ke status aktif seperti 'In Progress' setelah permintaan ditugaskan. Jenis peristiwa inferred | |||
| Permintaan dibuka kembali | Permintaan layanan yang sebelumnya diselesaikan telah dikembalikan ke status aktif. Hal ini biasanya terjadi saat pemohon menyatakan solusi tidak berhasil atau masalah muncul kembali. | ||
| Mengapa ini penting Permintaan yang dibuka kembali menunjukkan adanya pengerjaan ulang dan rendahnya tingkat penyelesaian pada penanganan pertama. Menganalisis peristiwa ini penting untuk meningkatkan kualitas layanan. Sumber data Aktivitas ini disimpulkan dari perubahan status 'Resolved' atau 'Closed' kembali ke status terbuka atau sedang dikerjakan. Pengumpulan data Catat stempel waktu saat status berubah dari status selesai kembali ke status aktif. Jenis peristiwa inferred | |||
| Permintaan diselesaikan | Agen telah menyelesaikan pekerjaan pemenuhan dan menilai bahwa permintaan layanan sudah terpenuhi. Status permintaan berubah menjadi 'Resolved', yang sering kali menghentikan penghitungan waktu SLA. | ||
| Mengapa ini penting Ini adalah pencapaian terpenting dalam proses pemenuhan. Waktu dari pembuatan hingga penyelesaian merupakan KPI utama untuk mengukur kinerja. Sumber data Aktivitas ini hampir selalu tercatat sebagai perubahan status khusus menjadi 'Resolved' atau 'Fulfilled' dalam riwayat permintaan. Pengumpulan data Gunakan stempel waktu dari log peristiwa saat status pertama kali berubah menjadi 'Resolved' atau status yang setara. Jenis peristiwa explicit | |||
| Permintaan ditugaskan | Permintaan layanan telah ditugaskan kepada agen atau tim pemenuhan tertentu yang bertanggung jawab menyelesaikan pekerjaan. Ini menandai perpindahan dari triase awal ke antrean pemenuhan. | ||
| Mengapa ini penting Ini adalah pencapaian penting untuk mengukur KPI waktu hingga penugasan dan memahami pembagian beban kerja di antara tim dan individu. Sumber data Aktivitas ini dapat dilacak melalui perubahan pada kolom 'Assignee' atau 'Assigned Group' dalam jejak audit atau riwayat permintaan. Pengumpulan data Temukan stempel waktu pertama saat kolom penanggung jawab atau kelompok penugasan terisi. Jenis peristiwa explicit | |||
| Permintaan layanan dibuat | Ini adalah aktivitas pertama dalam proses, yang menandai pengajuan resmi dan pencatatan permintaan layanan baru. Aktivitas ini tercatat saat pengguna mengajukan permintaan melalui portal, email, atau saluran lain, lalu sistem membuat ID kasus unik. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya siklus proses. Informasi ini menjadi dasar untuk menghitung waktu siklus keseluruhan dan menganalisis volume permintaan. Sumber data Biasanya, aktivitas ini tercatat sebagai peristiwa pembuatan yang jelas di tabel transaksi atau tiket utama, dengan stempel waktu saat data dibuat. Pengumpulan data Gunakan stempel waktu pembuatan data utama permintaan layanan. Jenis peristiwa explicit | |||
| Permintaan layanan ditutup | Permintaan layanan resmi ditutup dan dipindahkan ke status arsip, sehingga tidak ada tindakan lanjutan yang dapat dilakukan. Ini adalah aktivitas terakhir dalam siklus proses. | ||
| Mengapa ini penting Aktivitas ini menandai akhir proses secara resmi. Waktu antara penyelesaian dan penutupan dapat menunjukkan penundaan dalam mengonfirmasi solusi. Sumber data Biasanya, aktivitas ini tercatat sebagai perubahan status terakhir menjadi 'Closed'. Perubahan ini sering terjadi secara otomatis setelah jangka waktu tertentu dalam status 'Resolved'. Pengumpulan data Gunakan stempel waktu dari log peristiwa saat status berubah menjadi 'Closed'. Jenis peristiwa explicit | |||
| Informasi diberikan | Pemohon telah memberikan informasi yang diperlukan, sehingga agen pemenuhan dapat melanjutkan pekerjaan. Peristiwa ini biasanya mengeluarkan permintaan dari status menunggu. | ||
| Mengapa ini penting Aktivitas ini menandai berakhirnya waktu tunggu akibat pengguna. Waktu antara 'Information Requested' dan aktivitas ini merupakan metrik penting untuk menganalisis ketergantungan. Sumber data Aktivitas ini sering disimpulkan saat status permintaan berubah dari status menunggu kembali ke status aktif, biasanya setelah pengguna memberi komentar atau memperbarui permintaan. Pengumpulan data Catat stempel waktu saat status berubah dari menunggu pengguna kembali ke status aktif. Jenis peristiwa inferred | |||
| Ketergantungan eksternal dimulai | Permintaan layanan telah diserahkan kepada vendor eksternal atau departemen internal lain untuk ditindaklanjuti. Permintaan kini menunggu respons dari pihak tersebut. | ||
| Mengapa ini penting Aktivitas ini membantu mengisolasi dan mengukur penundaan akibat pihak eksternal, yang penting untuk analisis kinerja dan pengelolaan SLA yang akurat. Sumber data Aktivitas ini biasanya disimpulkan dari perubahan status menjadi 'Pending Vendor' atau 'Awaiting Third Party', atau dari penugasan ke kelompok khusus vendor. Pengumpulan data Temukan stempel waktu saat status berubah menjadi status yang menunjukkan adanya ketergantungan pada pihak ketiga. Jenis peristiwa inferred | |||
| Penyelesaian dikonfirmasi | Pemohon telah mengonfirmasi bahwa layanan diberikan dengan memuaskan dan permintaan telah diselesaikan. Konfirmasi ini menunjukkan bahwa penyelesaian berhasil. | ||
| Mengapa ini penting Aktivitas ini memberikan data berharga untuk mengukur kepuasan pelanggan dan memastikan solusi berhasil sebelum permintaan ditutup. Sumber data Aktivitas ini dapat tercatat sebagai perubahan status khusus atau disimpulkan dari respons survei positif maupun komentar tertentu yang ditambahkan pengguna setelah permintaan diselesaikan. Pengumpulan data Temukan stempel waktu dari peristiwa konfirmasi pengguna, seperti perubahan status yang dipicu pengguna atau respons survei yang tertaut. Jenis peristiwa inferred | |||
| Permintaan dialihkan | Tanggung jawab atas permintaan layanan telah dialihkan dari satu agen atau tim ke agen atau tim lain setelah penugasan awal. Hal ini sering menunjukkan bahwa permintaan salah diarahkan atau perlu dieskalasikan. | ||
| Mengapa ini penting Pengalihan yang sering dapat menandakan masalah pada triase awal, keterampilan agen, atau kompleksitas proses. Kondisi ini sering memperpanjang waktu penyelesaian. Sumber data Aktivitas ini dapat dilacak melalui setiap perubahan pada kolom 'Assignee' atau 'Assigned Group' setelah penugasan pertama. Pengumpulan data Catat setiap stempel waktu saat kolom penanggung jawab atau kelompok penugasan diperbarui, kecuali penugasan awal. Jenis peristiwa explicit | |||
| Permintaan disetujui | Permintaan layanan telah disetujui secara resmi oleh pihak yang berwenang. Keputusan ini memungkinkan proses pemenuhan berlanjut ke tahap berikutnya. | ||
| Mengapa ini penting Ini menandai pencapaian penting sekaligus mengakhiri subproses persetujuan. Waktu antara 'Approval Requested' dan 'Request Approved' merupakan KPI penting. Sumber data Peristiwa ini biasanya tercatat dalam log persetujuan atau disimpulkan dari perubahan status 'Pending Approval' menjadi status aktif. Pengumpulan data Gunakan stempel waktu dari data persetujuan atau peristiwa perubahan status dalam log audit permintaan. Jenis peristiwa explicit | |||
| Permintaan ditolak | Permintaan layanan ditolak secara resmi pada tahap persetujuan. Status akhir ini menghentikan proses sebelum pekerjaan pemenuhan dimulai. | ||
| Mengapa ini penting Menganalisis permintaan yang ditolak membantu memahami alasan penolakan dan menemukan masalah pada definisi permintaan, kebijakan, atau ekspektasi pengguna. Sumber data Biasanya, penolakan tercatat sebagai status khusus seperti 'Rejected' atau 'Denied' dalam riwayat status permintaan. Pengumpulan data Catat stempel waktu saat status permintaan diperbarui menjadi 'Rejected' atau status akhir serupa. Jenis peristiwa explicit | |||
| Permintaan layanan dibatalkan | Permintaan layanan ditarik sebelum pemenuhan selesai. Pembatalan dapat dilakukan oleh pemohon atau tim layanan. | ||
| Mengapa ini penting Ini merupakan akhir proses alternatif yang tidak menghasilkan penyelesaian. Menganalisis pembatalan membantu memahami mengapa permintaan tidak lagi diperlukan atau diajukan karena kesalahan. Sumber data Biasanya, pembatalan tercatat sebagai perubahan status khusus menjadi 'Canceled' atau 'Withdrawn' dalam riwayat status permintaan. Pengumpulan data Catat stempel waktu saat status diperbarui menjadi 'Canceled'. Jenis peristiwa explicit | |||
| Persetujuan diminta | Permintaan layanan telah dikirim kepada pemberi persetujuan atau kelompok persetujuan yang ditunjuk dan sedang menunggu keputusan. Langkah ini umum untuk permintaan yang berdampak pada biaya, keamanan, atau sumber daya. | ||
| Mengapa ini penting Melacak aktivitas ini membantu menemukan penundaan pada tahap persetujuan, yang sering menjadi hambatan penting sebelum pekerjaan pemenuhan dapat dimulai. Sumber data Aktivitas ini sering disimpulkan dari perubahan status menjadi 'Pending Approval' atau 'Awaiting Approval' dalam riwayat permintaan. Pengumpulan data Catat stempel waktu saat status permintaan berubah menjadi status menunggu persetujuan. Jenis peristiwa inferred | |||
| SLA dilanggar | Perjanjian tingkat layanan berbasis waktu, seperti waktu respons atau waktu penyelesaian, telah dilanggar. Peristiwa ini dihitung oleh sistem, bukan dipicu oleh tindakan manual pengguna. | ||
| Mengapa ini penting Melacak pelanggaran SLA penting untuk pelaporan kepatuhan dan menemukan permintaan yang tidak ditangani tepat waktu. Sumber data Sebagian sistem mencatatnya sebagai peristiwa khusus. Jika tidak, peristiwa ini perlu dihitung dengan membandingkan stempel waktu penyelesaian dengan target SLA. Pengumpulan data Bandingkan stempel waktu penyelesaian atau respons dengan tenggat SLA yang ditetapkan. Jika permintaan diselesaikan setelah tenggat, catat peristiwa ini. Jenis peristiwa calculated | |||
Panduan ekstraksi
Metode ekstraksi berbeda-beda untuk setiap sistem. Untuk petunjuk lengkap,
baca panduan ETL kami atau pilih proses dan sistem tertentu.
Siap memulai?
Mulailah mengoptimalkan proses permintaan layanan Anda. Pilih panduan ekstraksi khusus untuk sistem yang digunakan, atau gunakan templat umum ini sebagai titik awal yang fleksibel untuk sumber data apa pun.
Mulai optimalkan pengelolaan permintaan layanan Anda hari ini
Temukan inefisiensi dan percepat penyelesaian dengan wawasan yang berguna.
Tidak perlu kartu kredit