Templat data pengelolaan permintaan layanan Anda
Templat data pengelolaan permintaan layanan Anda
- Atribut yang disarankan untuk analisis menyeluruh
- Aktivitas utama untuk ditelusuri saat menemukan proses
- Panduan ekstraksi data dari Jira Service Management
Atribut pengelolaan permintaan layanan
| Nama | Deskripsi | ||
|---|---|---|---|
|
Aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi selama siklus hidup permintaan layanan. | ||
|
Deskripsi
Atribut ini menjelaskan tindakan atau perubahan status tertentu yang terjadi pada suatu waktu dalam penanganan permintaan layanan. Contohnya, 'Permintaan dibuat', 'Permintaan ditugaskan', 'Solusi diterapkan', dan 'Permintaan ditutup'. Analisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu memvisualisasikan peta proses, menemukan hambatan, dan mendeteksi penyimpangan dari alur kerja standar. Hal ini penting untuk memahami efisiensi proses dan kepatuhan.
Mengapa ini penting
Atribut ini menentukan langkah-langkah dalam proses, sehingga peta proses dapat divisualisasikan dan pola serta penyimpangan alur kerja dapat dianalisis.
Sumber data
Biasanya diambil dari riwayat perubahan 'status' pada isu Jira. Setiap entri perubahan pada kolom status di changelog isu mewakili satu aktivitas.
Contoh
Permintaan selesai ditriaseInformasi dimintaSolusi diterapkanPermintaan layanan ditutup
|
|||
|
ID permintaan layanan
ServiceRequestId
|
Pengenal unik untuk setiap permintaan layanan, yang menjadi kunci utama bagi semua peristiwa terkait. | ||
|
Deskripsi
ID Permintaan Layanan, yang sering disebut Issue Key di Jira, mengidentifikasi setiap permintaan layanan yang diajukan oleh pengguna atau sistem secara unik. ID ini menjadi penghubung utama bagi semua peristiwa berikutnya, dari pencatatan awal hingga penutupan akhir, sehingga perjalanan setiap permintaan layanan dapat dianalisis secara menyeluruh. Dalam process mining, ID ini penting untuk menghubungkan kasus. ID ini memastikan setiap aktivitas, perubahan status, dan waktu tercatat pada permintaan yang tepat, sehingga membentuk satu rangkaian proses yang utuh untuk dianalisis.
Mengapa ini penting
ID ini adalah pengenal utama kasus yang menghubungkan semua aktivitas terkait ke dalam satu alur proses dari awal hingga akhir, sehingga analisis proses dapat dilakukan.
Sumber data
Ini adalah kolom 'key' untuk suatu isu di Jira Service Management.
Contoh
SR-2023-001IT-45892HELP-105
|
|||
|
Waktu mulai
EventTime
|
Tanggal dan waktu tepat saat suatu aktivitas atau peristiwa terjadi. | ||
|
Deskripsi
Waktu Mulai, atau stempel waktu peristiwa, mencatat saat tepat suatu aktivitas terjadi. Ini merupakan komponen penting dalam analisis process mining karena memberikan konteks waktu untuk seluruh proses. Stempel waktu ini digunakan untuk mengurutkan peristiwa, menghitung jeda antaraktivitas dan total waktu siklus kasus, serta mengukur kinerja proses terhadap target berbasis waktu seperti SLA. Tanpa stempel waktu yang akurat, alur proses, keterlambatan, dan efisiensi tidak dapat dipahami atau diukur.
Mengapa ini penting
Stempel waktu ini penting untuk mengurutkan peristiwa, menghitung durasi dan waktu siklus, serta menemukan hambatan proses.
Sumber data
Ini adalah stempel waktu yang terkait dengan setiap perubahan status dalam changelog isu Jira. Waktu pembuatan isu tercatat di kolom 'created'.
Contoh
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Stempel waktu yang menunjukkan kapan data terakhir kali diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu ekstraksi data terbaru dari Jira Service Management. Informasi ini memberi konteks penting tentang kebaruan analisis dan data dalam dasbor serta KPI. Untuk mengambil keputusan yang tepat, Anda perlu mengetahui seberapa mutakhir data yang digunakan. Stempel waktu ini membantu pengguna memahami apakah informasi yang dilihat bersifat real-time atau merupakan rekaman dari waktu sebelumnya, yang memengaruhi relevansi temuan.
Mengapa ini penting
Menunjukkan kebaruan data agar analisis menggunakan informasi terkini.
Sumber data
Ini adalah kolom metadata yang dibuat dan disimpan oleh alat atau skrip ekstraksi data setelah prosesnya selesai.
Contoh
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem tempat data permintaan layanan diekstrak. | ||
|
Deskripsi
Atribut ini menunjukkan asal data, dalam hal ini Jira Service Management. Asal data mungkin tampak sepele saat menganalisis satu sumber, tetapi menjadi penting ketika data proses dari beberapa sistem digabungkan. Dalam analisis, atribut ini membantu melacak asal-usul data dan memastikan kualitasnya. Atribut ini juga memungkinkan Anda memfilter dan membandingkan proses yang melibatkan berbagai platform perangkat lunak.
Mengapa ini penting
Menunjukkan asal data. Informasi ini penting untuk tata kelola data dan saat menggabungkan data proses dari beberapa sistem perusahaan.
Sumber data
Biasanya berupa nilai tetap yang ditambahkan selama proses ekstraksi dan transformasi data untuk menandai asal dataset.
Contoh
Jira Service ManagementJiraSM
|
|||
|
Batas waktu SLA
SlaDueDate
|
Tanggal dan waktu target penyelesaian permintaan layanan sesuai SLA. | ||
|
Deskripsi
Batas Waktu SLA adalah stempel waktu hasil perhitungan yang menunjukkan tenggat penyelesaian permintaan. Tenggat ini ditentukan berdasarkan prioritas dan jenis permintaan, serta kebijakan Service Level Agreement (SLA) yang dikonfigurasi di Jira Service Management. Atribut ini menjadi dasar dasbor 'Kinerja SLA permintaan layanan' dan KPI 'Tingkat kepatuhan SLA'. Dengan membandingkan waktu penyelesaian aktual dengan tenggat ini, sistem dapat menentukan apakah permintaan selesai tepat waktu, terlambat, atau berisiko melanggar SLA.
Mengapa ini penting
Menjadi tolok ukur kinerja. Atribut ini mendukung penghitungan kepatuhan SLA secara langsung dan membantu menentukan prioritas pekerjaan.
Sumber data
Informasi SLA dikelola oleh Jira Service Management dan dapat diakses melalui API. Informasi ini sering disimpan di kolom khusus yang diperbarui secara dinamis.
Contoh
2023-10-28T16:00:00Z2023-11-01T09:00:00Z
|
|||
|
Jenis permintaan
RequestType
|
Klasifikasi permintaan layanan, seperti 'Permintaan akses' atau 'Masalah perangkat keras'. | ||
|
Deskripsi
Jenis Permintaan mengelompokkan permintaan layanan berdasarkan sifatnya. Ini merupakan dimensi dasar dalam analisis karena tiap jenis permintaan sering memiliki proses penyelesaian, SLA, dan kebutuhan sumber daya yang berbeda. Dengan menganalisis proses berdasarkan Jenis Permintaan, organisasi dapat menyesuaikan perbaikan untuk alur kerja tertentu. Misalnya, hambatan dalam permintaan 'Atur ulang kata sandi' akan berbeda dari permintaan 'Penyediaan server baru'. Atribut ini penting untuk membuat dasbor yang relevan, seperti 'Kualitas penyelesaian berdasarkan kategori'.
Mengapa ini penting
Atribut ini penting untuk membandingkan proses, beban kerja, dan kinerja pada berbagai kategori permintaan layanan.
Sumber data
Atribut ini biasanya sesuai dengan kolom 'issuetype' di Jira atau kolom khusus 'Request Type' di Jira Service Management.
Contoh
Minta akun baruMinta bantuan TIProses orientasi karyawan baru
|
|||
|
Penerima tugas
Assignee
|
Pengguna atau agen yang saat ini ditugaskan menangani permintaan layanan. | ||
|
Deskripsi
Penerima tugas adalah orang yang bertanggung jawab atas tindakan berikutnya atau penyelesaian permintaan layanan. Nilai atribut ini dapat berubah beberapa kali selama siklus hidup permintaan saat penanganannya dialihkan antaragen atau tim. Atribut ini penting untuk menganalisis beban kerja, mengukur kinerja, dan mengelola sumber daya. Anda dapat memfilter proses berdasarkan agen, membandingkan waktu penyelesaian antarorang, serta menemukan kebutuhan pelatihan atau ketimpangan beban kerja yang menimbulkan hambatan.
Mengapa ini penting
Atribut ini penting untuk menganalisis beban kerja agen, mengukur kinerja individu, dan memahami alokasi sumber daya.
Sumber data
Atribut ini sesuai dengan kolom 'assignee' pada isu Jira.
Contoh
Alice JohnsonBob WilliamsBelum ditugaskan
|
|||
|
Prioritas permintaan
RequestPriority
|
Tingkat prioritas permintaan layanan, seperti Rendah, Sedang, Tinggi, atau Kritis. | ||
|
Deskripsi
Prioritas Permintaan menunjukkan tingkat urgensi dan dampak bisnis suatu permintaan layanan. Klasifikasi ini menentukan urutan penanganan permintaan dan sering kali menetapkan target waktu penyelesaian serta SLA. Dalam analisis proses, prioritas menjadi dimensi penting untuk segmentasi. Anda dapat membandingkan waktu siklus dan kepatuhan SLA pada tiap tingkat prioritas, lalu memastikan permintaan berprioritas tinggi diproses lebih cepat dan memenuhi target. Analisis ini membantu menilai efektivitas sistem penentuan prioritas.
Mengapa ini penting
Memungkinkan analisis berdasarkan segmen untuk memastikan permintaan berprioritas tinggi ditangani lebih cepat dan memenuhi tingkat layanan yang lebih ketat.
Sumber data
Atribut ini sesuai dengan kolom 'priority' pada isu Jira.
Contoh
TertinggiTinggiSedangRendah
|
|||
|
Status permintaan
RequestStatus
|
Status terkini permintaan layanan dalam siklus hidupnya. | ||
|
Deskripsi
Atribut ini menunjukkan kondisi terkini permintaan layanan, seperti 'Open', 'In Progress', 'Waiting for Customer', atau 'Resolved'. Atribut ini memberikan gambaran posisi permintaan pada waktu tertentu. Log aktivitas menunjukkan riwayat proses, sedangkan status terkini berguna untuk menganalisis pekerjaan yang masih berlangsung dan menemukan permintaan yang tertahan. Misalnya, analisis dapat berfokus pada permintaan yang terlalu lama berstatus 'Waiting for Vendor', sehingga ketergantungan pada pihak luar dan keterlambatan dapat terlihat.
Mengapa ini penting
Memberikan gambaran terkini setiap kasus, sehingga pekerjaan yang masih berlangsung dan permintaan yang tertahan atau sudah lama dapat dianalisis.
Sumber data
Ini adalah kolom 'status' pada isu Jira.
Contoh
TerbukaSedang diprosesMenunggu pelangganSelesai
|
|||
|
Dibuka kembali
IsReopened
|
Penanda boolean yang menunjukkan apakah permintaan layanan dibuka kembali setelah diselesaikan. | ||
|
Deskripsi
Atribut hasil perhitungan ini bernilai benar atau salah. Nilainya menjadi benar jika alur kerja permintaan mencakup aktivitas 'Request Reopened'. Nilai ini diperoleh dengan menganalisis urutan aktivitas setiap kasus. Penanda ini penting untuk menghitung KPI 'Tingkat permintaan layanan dibuka kembali' dan menyajikan dasbor 'Volume permintaan layanan yang dibuka kembali'. Tingkat pembukaan kembali yang tinggi menunjukkan kualitas penyelesaian pada upaya pertama yang rendah, sehingga menambah pekerjaan ulang dan menurunkan kepuasan pelanggan. Dengan menganalisis jenis permintaan atau penyelesaian yang terkait dengan penanda ini, Anda dapat menemukan area yang perlu diperbaiki.
Mengapa ini penting
Mengukur secara langsung pekerjaan ulang dan kualitas penyelesaian pada upaya pertama, yang menjadi indikator penting efektivitas proses dan kepuasan pelanggan.
Sumber data
Dihitung saat transformasi data dengan memeriksa apakah urutan aktivitas suatu kasus memuat perubahan ke 'Reopened' setelah perubahan ke 'Resolved'.
Contoh
truefalse
|
|||
|
Kanal
Channel
|
Cara yang digunakan untuk mengajukan permintaan layanan, seperti email, portal, atau API. | ||
|
Deskripsi
Atribut Kanal menunjukkan cara permintaan layanan masuk ke sistem. Kanal yang umum di Jira Service Management mencakup portal pelanggan, email, atau pembuatan langsung oleh agen. Analisis proses berdasarkan kanal penting untuk memahami perilaku pengguna dan meningkatkan layanan. Analisis ini dapat menunjukkan apakah permintaan dari kanal tertentu membutuhkan waktu lebih lama untuk diselesaikan atau perlu lebih banyak klarifikasi. Temuan tersebut dapat menandakan perlunya formulir portal yang lebih baik atau aturan penguraian email yang lebih tepat. Informasi ini mendukung dasbor 'Tren volume permintaan layanan'.
Mengapa ini penting
Membantu menganalisis dampak kanal pengajuan terhadap waktu penyelesaian, kejelasan permintaan, atau efisiensi proses secara keseluruhan.
Sumber data
Informasi ini tersedia di Jira Service Management melalui kolom 'Request channel type'. Anda mungkin memerlukan akses API khusus atau perlu menyimpannya di kolom khusus.
Contoh
portalemailapi
|
|||
|
Organisasi
Organization
|
Organisasi pelanggan atau departemen internal tempat pelapor bekerja. | ||
|
Deskripsi
Atribut ini mengelompokkan pelapor berdasarkan organisasi atau departemen. Jira Service Management memiliki fitur bawaan 'Organizations' yang memungkinkan agen mengelola permintaan dari beberapa pelanggan atau tim internal. Analisis berdasarkan organisasi memberikan konteks bisnis yang berguna. Analisis ini dapat menunjukkan pelanggan atau departemen yang paling banyak menggunakan sumber daya dukungan, kelompok yang mengalami masalah berulang, serta konsistensi pemenuhan SLA di berbagai unit bisnis.
Mengapa ini penting
Memudahkan analisis permintaan layanan dan kinerja berdasarkan pelanggan atau departemen internal, serta memberikan wawasan bisnis penting.
Sumber data
Data ini berasal dari kolom 'Organizations' yang terkait dengan permintaan layanan di Jira Service Management.
Contoh
Acme CorporationDepartemen KeuanganGlobal Tech Inc.
|
|||
|
Pelapor
Reporter
|
Pengguna yang pertama kali membuat atau melaporkan permintaan layanan. | ||
|
Deskripsi
Pelapor adalah orang yang mengajukan permintaan layanan, biasanya pengguna akhir atau pelanggan. Atribut ini menunjukkan pihak yang memulai proses. Dalam analisis, Pelapor dapat digunakan untuk memahami pola permintaan dari berbagai pengguna, departemen, atau segmen pelanggan. Atribut ini membantu menjawab pertanyaan seperti 'Departemen mana yang paling banyak mengajukan permintaan?' atau 'Apakah pengguna tertentu berulang kali mengalami masalah yang sama?'. Informasi ini berguna untuk pengelolaan masalah secara proaktif dan meningkatkan pelatihan pengguna.
Mengapa ini penting
Menunjukkan pihak yang mengajukan permintaan, sehingga volume dan jenis permintaan dapat dianalisis berdasarkan pengguna, departemen, atau pelanggan.
Sumber data
Atribut ini sesuai dengan kolom 'reporter' pada isu Jira.
Contoh
Charles DarwinMarie CurieIsaac Newton
|
|||
|
Penyelesaian
Resolution
|
Hasil akhir atau kesimpulan dari permintaan layanan yang telah diselesaikan. | ||
|
Deskripsi
Kolom Resolution menunjukkan alasan permintaan layanan ditutup. Nilai yang umum antara lain 'Done', 'Won't Do', 'Duplicate', atau 'Cannot Reproduce'. Kolom ini memberikan detail penutupan di luar status 'Resolved' atau 'Closed'. Analisis penyelesaian membantu memahami kualitas dan jenis hasil. Misalnya, banyaknya penyelesaian 'Duplicate' dapat menandakan masalah dalam proses pengajuan permintaan. Sementara itu, melacak penyelesaian yang diikuti permintaan dibuka kembali dapat menunjukkan solusi yang kurang efektif.
Mengapa ini penting
Memberikan konteks tentang hasil permintaan, sehingga kualitas penyelesaian dan tren alasan penutupan permintaan dapat dianalisis.
Sumber data
Atribut ini sesuai dengan kolom 'resolution' pada isu Jira, yang biasanya diisi saat isu beralih ke kategori status 'done'.
Contoh
SelesaiTidak akan dikerjakanDuplikatDiperbaiki
|
|||
|
Status SLA
SlaState
|
Menunjukkan apakah permintaan layanan memenuhi SLA, melanggar SLA, atau masih dalam batas SLA yang ditetapkan. | ||
|
Deskripsi
Status SLA adalah atribut hasil perhitungan yang mengelompokkan setiap permintaan layanan berdasarkan kinerjanya terhadap tenggat SLA. Nilai yang mungkin mencakup 'Met', 'Breached', atau 'In Progress'. Nilai ini ditentukan dengan membandingkan stempel waktu penyelesaian dengan 'SlaDueDate'. Atribut ini menjadi dasar dasbor 'Kinerja SLA permintaan layanan' dan digunakan untuk menghitung KPI 'Tingkat kepatuhan SLA'. Atribut ini memberikan gambaran langsung tentang kepatuhan terhadap tingkat layanan, yang penting untuk pelaporan, pengelolaan kontrak, dan menjaga kualitas layanan.
Mengapa ini penting
Memberikan indikator kinerja SLA yang jelas dan langsung. Ini merupakan ukuran penting untuk kualitas layanan dan kepatuhan terhadap kontrak.
Sumber data
Dihitung saat transformasi data. Jika waktu penyelesaian sebelum 'SlaDueDate', statusnya 'Met'. Jika tidak, statusnya 'Breached'.
Contoh
TerpenuhiDilanggarSedang diproses
|
|||
|
Tim yang ditugaskan
AssignedTeam
|
Tim atau grup yang bertanggung jawab menangani permintaan layanan. | ||
|
Deskripsi
Atribut ini menunjukkan tim yang ditugaskan menangani permintaan. Biasanya, cakupannya lebih luas daripada penerima tugas perorangan. Atribut ini berguna untuk menganalisis kinerja tim, misalnya membandingkan tim Dukungan Tingkat Pertama dengan tim Operasional Jaringan. Dimensi ini penting untuk dasbor seperti 'Beban kerja agen dan metrik penyelesaian'. Atribut ini memungkinkan metrik kinerja dihitung pada tingkat tim, sehingga perbandingan lebih adil dan kontribusi tiap tim terhadap proses layanan secara keseluruhan dapat dipahami.
Mengapa ini penting
Memungkinkan analisis kinerja dan pemerataan beban kerja pada tingkat tim atau departemen, bukan hanya berdasarkan agen perorangan.
Sumber data
Atribut ini mungkin berupa kolom khusus di Jira, misalnya 'Team', atau diambil dari atribut profil pengguna penerima tugas.
Contoh
Dukungan TI - Tingkat 1Tim InfrastrukturDukungan Aplikasi
|
|||
Aktivitas pengelolaan permintaan layanan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Permintaan ditugaskan
|
Aktivitas ini terjadi saat permintaan layanan ditugaskan kepada agen atau tim tertentu untuk diselesaikan. Jira mencatat perubahan pada kolom 'Assignee' secara langsung, termasuk stempel waktu penugasan. | ||
|
Mengapa ini penting
Ini adalah tonggak penting untuk mengukur waktu dari triase hingga penugasan dan distribusi beban kerja agen. Tahap ini menandai peralihan dari antrean ke penanganan aktif.
Sumber data
Data diambil dari riwayat issue dengan mencari kejadian pertama saat kolom 'Assignee' diisi atau diubah dari kondisi belum ditugaskan.
Pengumpulan data
Gunakan stempel waktu perubahan pertama pada kolom 'Assignee' di riwayat issue.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan diselesaikan
|
Menandai waktu resmi saat permintaan dianggap terpenuhi dan solusinya dicatat. Jira mengisi kolom 'Resolution Date' saat isu pertama kali masuk ke status dalam kategori 'Done'. | ||
|
Mengapa ini penting
Ini adalah tonggak akhir utama dalam proses, yang penting untuk menghitung waktu penyelesaian dan kepatuhan terhadap SLA. Peristiwa ini menandai berakhirnya pekerjaan aktif.
Sumber data
Ini adalah peristiwa eksplisit. Waktunya diambil dari nilai kolom 'Resolution Date' pada isu Jira, yang diisi saat isu pertama kali beralih ke status dalam kategori 'Done'.
Pengumpulan data
Gunakan kolom 'resolutiondate' dari isu Jira. Kolom ini terisi secara otomatis.
Jenis peristiwa
explicit
|
|||
|
Permintaan layanan ditutup
|
Menandai penutupan administratif akhir permintaan layanan, yang sering terjadi secara otomatis setelah jangka waktu tertentu dalam status 'Resolved'. Ini adalah titik akhir siklus hidup isu di Jira. | ||
|
Mengapa ini penting
Ini adalah peristiwa akhir proses yang definitif. Jeda waktu antara 'Resolved' dan 'Closed' dapat dianalisis untuk memahami beban administrasi atau kebijakan penutupan otomatis.
Sumber data
Disimpulkan dari riwayat isu. Waktunya sesuai dengan perubahan status terakhir ke 'Closed' atau status akhir yang setara.
Pengumpulan data
Identifikasi waktu perubahan status terakhir ke status 'Closed'.
Jenis peristiwa
inferred
|
|||
|
Service Request dibuat
|
Aktivitas ini menandai awal siklus permintaan layanan, saat pengguna mengajukan permintaan melalui portal, email, atau saluran lain. Jira mencatat peristiwa ini secara langsung ketika issue baru dengan jenis 'Service Request' dibuat, beserta stempel waktu pembuatannya. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses. Informasi ini penting untuk menghitung waktu siklus keseluruhan serta memahami volume dan pola kedatangan permintaan.
Sumber data
Peristiwa ini tercatat secara langsung di tabel riwayat issue. Stempel waktu aktivitas menggunakan kolom 'created' pada issue Jira.
Pengumpulan data
Gunakan stempel waktu pembuatan issue dari tabel 'issues' atau riwayat.
Jenis peristiwa
explicit
|
|||
|
Solusi diajukan
|
Dalam banyak alur kerja service desk, tahap ini menjadi langkah tersendiri saat solusi diajukan kepada pemohon untuk disetujui. Aktivitas ini disimpulkan saat status issue berubah menjadi 'Pending Customer Acceptance' atau 'Awaiting Confirmation'. | ||
|
Mengapa ini penting
Aktivitas ini memisahkan waktu tunggu tanggapan pelanggan setelah solusi diberikan dari waktu kerja internal.
Sumber data
Disimpulkan dari riwayat issue, menggunakan stempel waktu saat status berubah ke kondisi yang menunjukkan solusi sedang menunggu validasi pelanggan.
Pengumpulan data
Temukan stempel waktu perubahan status menjadi 'Pending Customer Acceptance' atau status lain yang setara.
Jenis peristiwa
inferred
|
|||
|
Informasi diberikan
|
Aktivitas ini terjadi saat pemohon memberikan informasi yang diperlukan sehingga agen dapat melanjutkan pekerjaan. Aktivitas ini disimpulkan saat issue keluar dari status 'Waiting for customer', biasanya setelah pemohon menambahkan komentar. | ||
|
Mengapa ini penting
Aktivitas ini menutup siklus permintaan dan respons dengan pelanggan. Waktu antara permintaan dan penerimaan informasi menjadi bagian penting dari waktu tunggu proses.
Sumber data
Disimpulkan dari riwayat issue. Stempel waktunya menunjukkan saat status issue berubah dari 'Waiting for customer' kembali ke status 'In Progress'.
Pengumpulan data
Temukan stempel waktu saat kolom 'status' berubah dari status 'waiting' kembali ke status aktif.
Jenis peristiwa
inferred
|
|||
|
Informasi diminta
|
Aktivitas ini menandai saat agen memerlukan informasi tambahan dari pemohon untuk melanjutkan penyelesaian. Aktivitas ini biasanya disimpulkan saat status issue berubah menjadi 'Waiting for customer' atau 'Pending Input'. | ||
|
Mengapa ini penting
Siklus 'Information Requested' yang sering terjadi atau berlangsung lama dapat menandakan pengajuan awal yang kurang jelas atau komunikasi yang tidak efisien. Kondisi ini dapat menjadi sumber keterlambatan yang signifikan.
Sumber data
Disimpulkan dari riwayat issue. Stempel waktunya menunjukkan saat status issue berubah menjadi 'Waiting for customer' atau status lain yang setara.
Pengumpulan data
Temukan stempel waktu saat kolom 'status' berubah ke nilai yang menunjukkan proses sedang menunggu pemohon.
Jenis peristiwa
inferred
|
|||
|
Koordinasi dengan vendor berakhir
|
Aktivitas ini menandai saat vendor eksternal menyelesaikan tindakannya dan permintaan layanan dikembalikan ke tim internal. Aktivitas ini disimpulkan saat issue keluar dari status 'Waiting for vendor'. | ||
|
Mengapa ini penting
Mengukur durasi koordinasi dengan vendor membantu Anda mengelola kinerja vendor dan memahami dampak pihak eksternal terhadap waktu penyelesaian secara keseluruhan.
Sumber data
Disimpulkan dari riwayat issue. Stempel waktunya menunjukkan saat status issue berubah dari status vendor kembali ke 'In Progress'.
Pengumpulan data
Temukan stempel waktu saat kolom 'status' berubah dari status vendor kembali ke status aktif.
Jenis peristiwa
inferred
|
|||
|
Koordinasi dengan vendor dimulai
|
Aktivitas ini menandakan bahwa permintaan layanan telah dieskalasikan kepada vendor eksternal atau memerlukan tindakan dari pihak ketiga. Aktivitas ini disimpulkan saat status issue berubah menjadi 'Waiting for vendor' atau 'With Third Party'. | ||
|
Mengapa ini penting
Melacak koordinasi dengan vendor penting untuk menemukan ketergantungan eksternal dan keterlambatan yang berada di luar kendali langsung tim layanan internal.
Sumber data
Disimpulkan dari riwayat issue. Stempel waktunya menunjukkan saat status issue berubah menjadi status khusus untuk vendor.
Pengumpulan data
Temukan stempel waktu saat kolom 'status' berubah ke nilai seperti 'Waiting for Vendor'.
Jenis peristiwa
inferred
|
|||
|
Penyelesaian dikonfirmasi
|
Aktivitas ini terjadi saat pemohon secara resmi menerima solusi yang diajukan, yang sering kali memicu perubahan otomatis ke status 'Resolved'. Peristiwa ini biasanya disimpulkan dari perubahan status tersebut. | ||
|
Mengapa ini penting
Tonggak ini memastikan efektivitas solusi dan menjadi pemicu untuk menghentikan penghitungan waktu SLA. Informasi ini membantu mengukur waktu yang dibutuhkan pelanggan untuk mengonfirmasi perbaikan.
Sumber data
Disimpulkan dari riwayat issue. Stempel waktunya menunjukkan saat status berubah dari 'Pending Customer Acceptance' menjadi 'Resolved' atau 'Closed'.
Pengumpulan data
Identifikasi waktu perubahan status dari 'Pending Customer Acceptance' ke status 'Resolved' atau 'Closed'.
Jenis peristiwa
inferred
|
|||
|
Permintaan dibuka kembali
|
Aktivitas ini mencatat saat permintaan layanan yang sebelumnya selesai kembali ke status aktif. Aktivitas ini disimpulkan dari perubahan status selesai atau tertutup menjadi terbuka atau sedang diproses. | ||
|
Mengapa ini penting
Melacak permintaan yang dibuka kembali penting untuk mengukur kualitas penyelesaian dan First-Time Resolution Rate. Tingkat pembukaan kembali yang tinggi menunjukkan solusi yang kurang efektif atau masalah yang berulang.
Sumber data
Disimpulkan dari riwayat issue dengan mencari perubahan status dari kategori 'Resolved' atau 'Closed' ke kategori 'Open' atau 'In Progress'.
Pengumpulan data
Cari perubahan status dari kategori 'Done' ke kategori 'To Do' atau 'In Progress'.
Jenis peristiwa
inferred
|
|||
|
Permintaan selesai ditriase
|
Aktivitas ini menunjukkan penilaian awal atas permintaan layanan, termasuk penentuan prioritas, kategori, dan dampaknya. Aktivitas ini biasanya disimpulkan dari perubahan status, misalnya dari 'New' ke 'In Progress' atau ke status khusus 'Triaged'. | ||
|
Mengapa ini penting
Analisis waktu triase membantu menilai efisiensi penanganan awal permintaan. Keterlambatan pada tahap ini dapat memperpanjang waktu penyelesaian secara keseluruhan dan mengurangi kepatuhan terhadap SLA.
Sumber data
Disimpulkan dari riwayat issue dengan mencari stempel waktu pertama saat status berubah dari kondisi awal 'New' atau 'Open' ke status aktif seperti 'In Progress'.
Pengumpulan data
Temukan perubahan status pertama dari 'New' atau status awal lain yang setara, sesuai alur kerja proyek.
Jenis peristiwa
inferred
|
|||
|
Solusi diterapkan
|
Aktivitas ini menunjukkan bahwa agen telah melakukan tindakan yang diperlukan atau menyusun solusi untuk menangani permintaan layanan. Aktivitas ini sering disimpulkan dari perubahan status menjadi 'Pending Review' atau langsung menjadi 'Resolved'. | ||
|
Mengapa ini penting
Tonggak ini menandai selesainya pekerjaan utama untuk menyelesaikan permintaan. Waktu hingga aktivitas ini sering mencakup bagian proses yang memberikan nilai utama.
Sumber data
Disimpulkan dari riwayat issue, dengan menggunakan stempel waktu saat status berubah menjadi 'Resolved', 'Pending Acceptance', atau status prapenutupan yang serupa.
Pengumpulan data
Temukan stempel waktu saat kolom 'status' berubah ke nilai yang menunjukkan pekerjaan telah selesai.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi data
Siap memulai?
Gunakan templat ini untuk memulai process mining dan menemukan peluang perbaikan dalam pengelolaan permintaan layanan. Mulai tingkatkan operasional Anda hari ini.
Optimalkan pengelolaan permintaan layanan di Jira sekarang
Capai otomatisasi 70% dan hentikan pemenuhan yang lambat. Tingkatkan efisiensi sekarang!
Tidak perlu kartu kredit. Penyiapan hanya perlu beberapa menit.