> Perbaikan proses berkelanjutan > Pengelolaan perubahan > Jira Service Management > Templat data

Templat data pengelolaan perubahan

Jira Service Management

Atribut pengelolaan perubahan(19) Aktivitas pengelolaan perubahan(13) Panduan ekstraksi data(3)

Templat data pengelolaan perubahan

Templat ini memandu Anda mengumpulkan data yang diperlukan untuk menganalisis proses pengelolaan perubahan. Isinya mencakup atribut penting, aktivitas utama yang perlu dilacak, serta panduan praktis untuk mengekstrak data dari Jira Service Management. Gunakan templat ini untuk menyusun log peristiwa yang akurat dan memahami proses perubahan Anda.

Atribut yang disarankan untuk dikumpulkan
Aktivitas utama yang perlu dilacak dalam proses
Panduan ekstraksi data dari Jira Service Management

Baru mengenal log peristiwa? Pelajari cara membuat log peristiwa process mining.

Unduh template

Atribut pengelolaan perubahan

Berikut kolom data yang disarankan untuk log peristiwa agar proses pengelolaan perubahan dapat dianalisis dengan baik.

5 Wajib 7 Disarankan 7 Opsional

	Nama	Deskripsi
	Aktivitas ActivityName	Nama peristiwa bisnis atau tugas tertentu yang terjadi dalam proses Change Management.
Deskripsi Atribut ini mencatat nama aktivitas yang berlangsung pada waktu tertentu dalam permintaan perubahan. Aktivitas ini berasal dari perubahan status, langkah alur kerja, atau entri log tertentu di Jira, seperti 'Perubahan Diajukan untuk Ditinjau' atau 'Penerapan Dimulai'. Menganalisis urutan dan frekuensi aktivitas merupakan inti process mining. Analisis ini membantu menemukan alur proses yang sebenarnya, mengidentifikasi hambatan antar langkah, dan membandingkan variasi proses dengan prosedur operasional standar. Mengapa ini penting Atribut ini menentukan langkah-langkah proses, yang penting untuk menemukan peta proses, menganalisis variasi, dan mengidentifikasi hambatan. Sumber data Biasanya diambil dari riwayat isu Jira, khususnya perubahan status atau pembaruan kolom khusus yang menandai tahap penting dalam proses. Contoh Permintaan perubahan disetujuiPenilaian risiko dilakukanPerubahan diterapkanTinjauan setelah penerapan selesai
	ID permintaan perubahan ChangeRequestId	Pengenal unik untuk satu kasus permintaan perubahan, yang mengelompokkan semua aktivitas terkait sejak dibuat hingga ditutup.
Deskripsi ID Permintaan Perubahan adalah kunci utama yang mengidentifikasi setiap inisiatif perubahan di Jira Service Management secara unik. ID ini berfungsi sebagai pengenal kasus untuk process mining, dengan menghubungkan semua peristiwa, perubahan status, dan pembaruan menjadi satu gambaran proses menyeluruh. Dalam analisis, ID ini memungkinkan rekonstruksi seluruh siklus setiap perubahan. ID ini penting untuk melacak perubahan di berbagai tahap, seperti penilaian risiko, persetujuan, penerapan, dan peninjauan. Semua metrik, KPI, dan dasbor mengandalkan atribut ini untuk menggabungkan dan menghubungkan data peristiwa dengan tepat untuk setiap perubahan. Mengapa ini penting Ini adalah pengenal kasus utama yang memungkinkan Anda menelusuri seluruh perjalanan permintaan perubahan dan menganalisis kinerjanya. Sumber data Ini adalah Kunci Isu Jira standar, yang terdapat di kolom `key` untuk isu bertipe Change request. Contoh ITSM-1024CHG-2023-001CR-5921
	Waktu mulai EventTime	Stempel waktu tepat yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi.
Deskripsi Waktu Mulai, atau stempel waktu peristiwa, menunjukkan tanggal dan waktu tepat saat aktivitas dicatat untuk suatu permintaan perubahan. Setiap aktivitas dalam log peristiwa, dari pembuatan hingga penutupan, memiliki stempel waktu. Atribut ini penting untuk semua analisis berbasis waktu dalam process mining. Atribut ini digunakan untuk menghitung waktu siklus, durasi antaraktivitas, waktu tunggu, dan urutan peristiwa. Atribut ini menjadi dasar pemantauan kinerja, penghitungan kepatuhan terhadap SLA, dan identifikasi hambatan. Mengapa ini penting Stempel waktu ini menjadi dasar analisis kinerja dan durasi. Dengan data ini, Anda dapat menghitung waktu siklus dan menemukan keterlambatan. Sumber data Stempel waktu setiap entri dalam log riwayat isu Jira. Untuk peristiwa pembuatan, gunakan kolom `created`. Contoh 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	Pembaruan data terakhir LastDataUpdate	Stempel waktu yang menunjukkan kapan data untuk catatan ini terakhir diperbarui atau diekstrak.
Deskripsi Atribut ini mencatat tanggal dan waktu terakhir kali data diambil dari sistem sumber. Atribut ini menunjukkan seberapa baru data dalam alat process mining. Dengan menganalisis atribut ini, pengguna dapat mengetahui seberapa mutakhir data proses. Informasi ini penting untuk dasbor operasional dan pemantauan langsung. Atribut ini memberi konteks pada analisis agar keputusan tidak dibuat berdasarkan data yang sudah usang. Mengapa ini penting Menunjukkan seberapa baru data, sehingga analisis tetap relevan dan menggunakan informasi terkini. Sumber data Kolom metadata ini diisi oleh alat ekstraksi data saat data diambil. Contoh 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	Sistem sumber SourceSystem	Menunjukkan sistem tempat data Change Management diekstrak.
Deskripsi Atribut ini menunjukkan sistem sumber asal data proses. Dalam konteks ini, nilainya selalu 'Jira Service Management'. Dalam lingkungan perusahaan yang lebih luas, data mungkin digabungkan dari beberapa sistem. Kolom ini penting untuk melacak asal-usul data, memecahkan masalah, dan memahami variasi proses yang bergantung pada sistem. Kolom ini memperjelas asal data yang dianalisis. Mengapa ini penting Memperjelas asal-usul data, yang penting saat menggabungkan data dari beberapa sistem atau untuk keperluan audit. Sumber data Nilai statis ini ditambahkan saat ekstraksi data untuk menandai asal kumpulan data. Contoh Jira Service Management
	Jenis Perubahan ChangeRequestType	Klasifikasi perubahan, seperti Standar, Normal, atau Darurat.
Deskripsi Jenis Perubahan mengelompokkan permintaan perubahan berdasarkan sifat, urgensi, dan dampaknya. Jenis yang umum mencakup 'Standar' untuk perubahan berisiko rendah yang sudah disetujui sebelumnya, 'Normal' untuk perubahan rutin yang memerlukan persetujuan penuh, dan 'Darurat' untuk perubahan mendesak guna menangani insiden. Atribut ini penting untuk analisis proses karena tiap jenis perubahan dapat mengikuti alur proses dan SLA yang berbeda. Atribut ini digunakan untuk menghitung KPI 'Tingkat Perubahan Darurat' dan memfilter dashboard agar Anda dapat membandingkan kinerja serta risiko tiap jenis perubahan. Mengapa ini penting Atribut ini membantu memisahkan proses untuk menganalisis alur kerja yang berbeda, seperti perubahan standar dan darurat, yang memiliki ekspektasi kinerja dan risiko masing-masing. Sumber data Biasanya, ini adalah kolom khusus di proyek Jira Service Management. Nama kolomnya dapat berbeda, tetapi sering disebut 'Jenis Perubahan'. Contoh StandarNormalDarurat
	Penanggung Jawab Assignee	Pengguna yang saat ini bertanggung jawab menangani permintaan perubahan.
Deskripsi Penanggung Jawab adalah pengguna yang bertanggung jawab atas langkah atau aktivitas saat ini dalam alur kerja manajemen perubahan. Penanggung jawab dapat berganti beberapa kali selama siklus permintaan perubahan, saat pekerjaan berpindah antarorang dan tim. Atribut ini digunakan untuk menganalisis pembagian beban kerja, menemukan hambatan pada pengguna tertentu, dan memahami alokasi sumber daya. Dashboard 'Beban Kerja Aktivitas Tim Perubahan' menggunakan data ini untuk menunjukkan individu atau kelompok yang menangani aktivitas terbanyak. Mengapa ini penting Atribut ini membantu menganalisis kinerja dan pembagian beban kerja, serta menemukan hambatan pada individu atau tim. Sumber data Ini adalah kolom `assignee` standar pada issue Jira. Contoh Alice JohnsonBob WilliamsCharlie Brown
	Prioritas Priority	Tingkat prioritas permintaan perubahan yang menunjukkan kepentingannya bagi bisnis.
Deskripsi Kolom Prioritas membantu tim menentukan urutan penanganan permintaan perubahan. Prioritas mencerminkan gabungan dampak dan urgensi, serta menjadi panduan untuk penjadwalan dan alokasi sumber daya. Dengan menganalisis prioritas, Anda dapat membandingkan kinerja perubahan berprioritas tinggi dan rendah. Misalnya, Anda dapat memeriksa apakah perubahan berprioritas tinggi benar-benar memiliki waktu siklus lebih singkat atau justru mengalami hambatan yang sama dengan perubahan lain. Analisis ini membantu mengarahkan sumber daya dan memenuhi ekspektasi bisnis. Mengapa ini penting Atribut ini membantu menganalisis kinerja proses berdasarkan prioritas bisnis, sehingga perubahan kritis dapat dipercepat sesuai harapan. Sumber data Ini adalah kolom `priority` standar pada issue Jira. Contoh TertinggiTinggiSedangRendah
	Status perubahan ChangeRequestStatus	Status permintaan perubahan saat ini atau sebelumnya pada waktu peristiwa terjadi.
Deskripsi Atribut ini menunjukkan status permintaan perubahan, seperti 'Menunggu Persetujuan', 'Sedang Diproses', atau 'Ditutup'. Kolom status di Jira menjadi dasar workflow-nya. Perubahan pada kolom ini juga menjadi pemicu utama alur proses. Dengan menganalisis status, Anda dapat melacak kemajuan perubahan yang masih berjalan dan memahami hasil perubahan yang sudah selesai, misalnya 'Ditutup - Berhasil' atau 'Ditutup - Gagal'. Informasi ini penting untuk membuat dashboard throughput dan menganalisis siklus pengerjaan ulang saat status kembali ke tahap sebelumnya. Mengapa ini penting Atribut ini memperlihatkan kemajuan dan hasil akhir permintaan perubahan dengan jelas. Informasi ini penting untuk menganalisis throughput dan pengerjaan ulang. Sumber data Ini adalah kolom `status` standar pada issue Jira. Status yang tersedia ditentukan dalam konfigurasi workflow proyek. Contoh PerencanaanMenunggu PersetujuanDalam PenerapanDitutupDibatalkan
	Status SLA SLAStatus	Menunjukkan apakah permintaan perubahan selesai sebelum atau pada tanggal target penyelesaian.
Deskripsi Atribut terhitung ini membandingkan tanggal resolusi sebenarnya dari permintaan perubahan dengan 'Tanggal Target Penyelesaian'. Hasilnya berupa status sederhana, seperti 'Terpenuhi' atau 'Terlewati'. Status ini memberikan gambaran kinerja yang jelas pada dashboard 'Pemantauan Kinerja SLA Perubahan'. Status yang dihitung untuk setiap kasus juga memudahkan pembuatan KPI seperti 'Tingkat Kepatuhan SLA Perubahan'. Anda dapat memfilter dan mengelompokkan data untuk melihat jenis perubahan, tim, atau layanan yang paling sering mengalami pelanggaran SLA. Mengapa ini penting Atribut ini memberikan hasil yang jelas untuk kinerja SLA setiap kasus, sehingga pelaporan dan analisis kepatuhan SLA lebih mudah. Sumber data Dihitung dengan membandingkan stempel waktu aktivitas terakhir 'Perubahan Ditutup' dengan atribut 'TargetCompletionDate'. Contoh TerpenuhiTerlewati
	Tanggal Target Penyelesaian TargetCompletionDate	Batas waktu yang direncanakan atau ditetapkan dalam Service Level Agreement (SLA) untuk menyelesaikan permintaan perubahan.
Deskripsi Atribut ini menyimpan tanggal target penyelesaian permintaan perubahan agar memenuhi SLA. Tanggal ini menjadi acuan untuk mengukur waktu penyelesaian sebenarnya. Tanggal ini penting untuk memantau kinerja terhadap komitmen. Atribut ini menjadi dasar dashboard 'Pemantauan Kinerja SLA Perubahan' dan KPI 'Tingkat Kepatuhan SLA Perubahan'. Dengan membandingkan tanggal penyelesaian sebenarnya dengan target, organisasi dapat mengukur efektivitas penyampaian layanan. Mengapa ini penting Atribut ini menjadi data utama untuk menghitung kepatuhan SLA dan menemukan perubahan yang berisiko melewati tenggat. Sumber data Biasanya, atribut ini menggunakan kolom `duedate` di Jira atau nilai dari metrik SLA yang dikonfigurasi di Jira Service Management. Contoh 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	Tingkat Risiko RiskLevel	Tingkat risiko yang dinilai untuk perubahan, seperti Rendah, Sedang, atau Tinggi.
Deskripsi Tingkat Risiko wajib dinilai dalam sebagian besar proses manajemen perubahan. Atribut ini mengelompokkan potensi dampak negatif dari suatu perubahan. Penilaiannya dilakukan pada tahap penilaian risiko dan sering menentukan alur persetujuan yang diperlukan. Dalam process mining, atribut ini penting untuk analisis berbasis risiko. Atribut ini mendukung dashboard 'Akurasi dan Hasil Penilaian Risiko' dengan membandingkan risiko awal dan hasil sebenarnya. Atribut ini juga menjadi dimensi utama KPI 'Tingkat Kegagalan Perubahan berdasarkan Tingkat Risiko' untuk membantu menilai efektivitas penanganan perubahan berisiko tinggi. Mengapa ini penting Atribut ini membantu menilai efektivitas kontrol proses dan alur persetujuan untuk berbagai tingkat risiko, serta menghubungkan risiko dengan tingkat kegagalan perubahan. Sumber data Biasanya, ini adalah kolom khusus di Jira Service Management. Nama yang umum digunakan antara lain 'Tingkat Risiko' atau 'Dampak'. Contoh RendahSedangTinggiKritis
	Alasan Perubahan ChangeReason	Alasan atau kebutuhan bisnis yang mendasari pengajuan perubahan.
Deskripsi Atribut ini mencatat alasan yang mendasari perubahan, seperti 'Penerapan Fitur Baru', 'Perbaikan Bug', atau 'Peningkatan Infrastruktur'. Informasi ini memberi konteks penting di luar ringkasan atau deskripsi. Dalam analisis, alasan perubahan dapat dibandingkan dengan metrik lain, seperti waktu siklus, tingkat kegagalan, dan tingkat risiko. Dengan begitu, Anda dapat menjawab pertanyaan seperti, 'Apakah perubahan untuk memperbaiki bug lebih cepat disetujui daripada penerapan fitur baru?' atau 'Apakah peningkatan infrastruktur memiliki tingkat kegagalan lebih tinggi?'. Mengapa ini penting Atribut ini memberi konteks bisnis untuk analisis lebih lanjut dengan menghubungkan tujuan perubahan dengan kinerja dan hasilnya. Sumber data Biasanya, ini adalah kolom khusus di Jira Service Management, berupa daftar pilihan atau kolom teks. Contoh Patch KeamananPeningkatan Perangkat LunakPemasangan Perangkat Keras Baru
	Apakah Pengerjaan Ulang IsRework	Penanda boolean bernilai true jika permintaan perubahan mengalami siklus pengerjaan ulang.
Deskripsi Atribut terhitung ini mengidentifikasi permintaan perubahan yang dikembalikan ke tahap sebelumnya untuk diperbaiki, misalnya dari 'Menunggu Persetujuan' kembali ke 'Perencanaan'. Ini menandakan pengajuan awal belum lengkap, keliru, atau belum memenuhi kriteria yang diperlukan. Penanda ini menjadi dasar KPI 'Tingkat Pengerjaan Ulang Perubahan' dan dashboard 'Analisis Pengerjaan Ulang dan Penolakan Perubahan'. Dengan menandai kasus pengerjaan ulang, analis dapat memfilternya dengan mudah dan menyelidiki penyebabnya, seperti perencanaan awal yang kurang baik, persyaratan yang tidak jelas, atau penilaian risiko yang tidak memadai. Mengapa ini penting Atribut ini menyoroti ketidakefisienan proses dengan menandai kasus yang memerlukan pekerjaan tambahan di luar rencana, sehingga penyebab pengerjaan ulang dapat dianalisis. Sumber data Dihitung dengan menganalisis urutan aktivitas dalam log peristiwa. Pengerjaan ulang terdeteksi jika aktivitas pada tahap lanjut diikuti aktivitas dari tahap sebelumnya. Contoh truefalse
	Layanan Bisnis BusinessService	Layanan bisnis atau aplikasi yang terdampak oleh perubahan.
Deskripsi Atribut ini menghubungkan permintaan perubahan dengan layanan bisnis tertentu yang tercatat di Configuration Management Database (CMDB), seperti 'Layanan Email' atau 'CRM Pelanggan'. Atribut ini penting untuk memahami dampak perubahan terhadap bisnis. Dengan menganalisis perubahan berdasarkan layanan bisnis, Anda dapat menentukan prioritas dan menyampaikan dampaknya kepada pemangku kepentingan. Anda dapat melihat layanan yang paling sering mengalami perubahan, layanan yang paling berisiko, dan layanan yang paling banyak mengalami insiden terkait perubahan. Informasi ini penting untuk mengelola perubahan teknis dengan mempertimbangkan kebutuhan bisnis. Mengapa ini penting Atribut ini menghubungkan perubahan teknis dengan dampak bisnis, sehingga Anda dapat menentukan prioritas dan menganalisis risiko berdasarkan tingkat kepentingan layanan yang terdampak. Sumber data Biasanya, ini adalah kolom khusus di JSM yang sering terhubung ke Jira Assets (sebelumnya Insight) atau CMDB lainnya. Contoh Situs Web PerusahaanSAP ERPWiki Internal
	Masalah Pascapenerapan PostImplementationIssue	Penanda yang menunjukkan apakah insiden atau masalah dikaitkan dengan perubahan ini setelah penerapan.
Deskripsi Atribut ini menunjukkan apakah perubahan menimbulkan dampak negatif, seperti insiden di lingkungan produksi. Biasanya, hal ini diketahui dengan menghubungkan issue permintaan perubahan dengan satu atau beberapa issue insiden di Jira. Data ini penting untuk menghitung KPI 'Tingkat Masalah Pascapenerapan' dan 'Tingkat Kegagalan Perubahan'. Data ini mengukur kualitas perubahan dan efektivitas proses perencanaan, pengujian, serta penilaian risiko secara langsung. Dengan menganalisis perubahan yang menimbulkan masalah, Anda dapat menyempurnakan kontrol dan mencegah kegagalan serupa. Mengapa ini penting Atribut ini mengukur kualitas dan keberhasilan perubahan secara langsung dengan mencatat apakah perubahan tersebut menimbulkan masalah operasional setelah diterapkan. Sumber data Biasanya, atribut ini ditentukan dengan memeriksa issue yang saling terhubung di Jira, khususnya apakah issue Perubahan memiliki tautan 'disebabkan oleh' dari issue Insiden. Contoh truefalse
	Pelapor Reporter	Pengguna yang pertama kali membuat atau mengirimkan permintaan perubahan.
Deskripsi Pelapor adalah orang yang membuat issue permintaan perubahan di Jira. Biasanya, pelapor adalah pemilik perubahan atau orang yang mengajukan perubahan atas nama tim. Dengan menganalisis pelapor, Anda dapat mengetahui departemen, tim, atau individu yang paling sering mengajukan perubahan. Data ini juga dapat digunakan untuk melihat tren sumber perubahan dan memberikan masukan atau pelatihan kepada kelompok yang sering mengirimkan permintaan perubahan yang tidak lengkap atau kurang berkualitas. Mengapa ini penting Atribut ini membantu menemukan sumber permintaan perubahan. Informasi tersebut dapat dianalisis untuk meningkatkan kualitas pengajuan awal. Sumber data Ini adalah kolom `reporter` standar pada issue Jira. Contoh David MillerEva GreenFrank Wright
	Resolusi Resolution	Hasil akhir permintaan perubahan yang ditutup, yang menunjukkan cara penyelesaiannya.
Deskripsi Saat permintaan perubahan ditutup, kolom Resolusi menjelaskan hasilnya secara spesifik. Misalnya, 'Selesai' menunjukkan keberhasilan, sedangkan 'Tidak Dilakukan' atau 'Duplikat' menunjukkan alasan penutupan lainnya. Informasi ini memberi konteks lebih lengkap daripada status 'Ditutup' saja. Atribut ini penting untuk menganalisis tingkat keberhasilan dan kegagalan perubahan. Misalnya, KPI 'Tingkat Masalah Pascapenerapan' dapat dianalisis lebih lanjut dengan memfilter perubahan yang memiliki resolusi 'Gagal' atau 'Dikembalikan'. Atribut ini membantu membedakan perubahan yang berhasil diterapkan dari perubahan yang dibatalkan atau ditolak setelah disetujui. Mengapa ini penting Atribut ini memberi konteks terperinci tentang hasil akhir perubahan, sehingga tingkat keberhasilan dan kegagalan dapat dihitung dengan akurat. Sumber data Ini adalah kolom `resolution` standar di Jira. Biasanya, kolom ini diisi saat issue berpindah ke kategori status 'Selesai'. Contoh SelesaiTidak DilakukanDuplikatDibatalkanDikembalikan
	Tim Team	Tim atau kelompok yang bertanggung jawab atas permintaan perubahan atau aktivitas tertentu.
Deskripsi Atribut ini menunjukkan tim yang ditugaskan menangani perubahan. Jira menyediakan kolom 'Penanggung Jawab' untuk individu, sedangkan kolom 'Tim' biasanya digunakan untuk menugaskan pekerjaan kepada kelompok fungsional, seperti 'Operasional Jaringan' atau 'Administrator Database'. Atribut ini penting untuk dashboard 'Beban Kerja Aktivitas Tim Perubahan'. Anda dapat menganalisis kinerja dan hambatan di tingkat tim, bukan hanya individu. Analisis di tingkat tim sering lebih berguna untuk perencanaan dan pengelolaan sumber daya. Mengapa ini penting Atribut ini membantu menganalisis beban kerja dan kinerja di tingkat tim atau departemen, serta menyoroti hambatan yang terjadi di seluruh sistem. Sumber data Biasanya, ini adalah kolom khusus di Jira karena tidak ada kolom 'Tim' standar. Jenis kolomnya dapat berupa 'Group Picker' atau daftar pilihan sederhana. Contoh Tim InfrastrukturLayanan IntiDukungan Aplikasi

Wajib Disarankan Opsional

Aktivitas pengelolaan perubahan

Berikut langkah dan tonggak proses utama yang perlu dicatat dalam log peristiwa agar proses pengelolaan perubahan dapat ditemukan dengan akurat.

5 Disarankan 8 Opsional

	Aktivitas	Deskripsi
	Permintaan perubahan dibuat	Menandai pembuatan awal tiket permintaan perubahan di Jira Service Management. Peristiwa ini tercatat dengan stempel waktu pembuatan saat isu baru bertipe 'Change' pertama kali disimpan.
Mengapa ini penting Ini adalah titik awal semua permintaan perubahan. Informasi ini penting untuk mengukur waktu tunggu keseluruhan dan menganalisis jumlah perubahan yang masuk dari waktu ke waktu. Sumber data Diambil dari stempel waktu 'created' pada objek isu Jira. Kolom sistem standar ini tersedia untuk setiap isu dan dapat diperoleh melalui riwayat isu atau API. Pengumpulan data Gunakan stempel waktu pada kolom 'created' dari isu Jira. Jenis peristiwa explicit
	Permintaan perubahan disetujui	Tahap penting yang menandakan perubahan telah disetujui secara resmi untuk diterapkan. Peristiwa ini hampir selalu diketahui dari perubahan status dalam alur kerja Jira menjadi 'Approved' atau 'Ready for Implementation'.
Mengapa ini penting Peristiwa ini menandai akhir siklus persetujuan dan awal tahap penerapan. Informasi ini penting untuk mengukur waktu siklus persetujuan dan melacak perubahan tanpa izin. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah menjadi 'Approved'. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Approved' atau 'Ready to Implement'. Jenis peristiwa inferred
	Perubahan diterapkan	Tahap penting yang menandakan pekerjaan terkait perubahan telah selesai. Peristiwa ini tercatat saat status dalam alur kerja Jira berubah menjadi 'Implemented' atau 'Pending Verification'.
Mengapa ini penting Tahap ini menandai akhir penerapan dan penting untuk menghitung waktu tunggu penerapan. Tahap ini juga menjadi pemicu untuk tinjauan dan verifikasi setelah penerapan. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah menjadi 'Implemented' atau 'Pending Post-Implementation Review'. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Implemented' atau status serupa. Jenis peristiwa inferred
	Perubahan ditutup	Menandai penutupan akhir permintaan perubahan, yang berarti semua aktivitas terkait telah selesai. Peristiwa ini tercatat saat status isu Jira berubah ke status akhir yang telah diselesaikan, seperti 'Closed' atau 'Done'.
Mengapa ini penting Ini adalah titik akhir utama proses. Informasi ini digunakan untuk menghitung waktu siklus keseluruhan dan mengukur kepatuhan terhadap SLA. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah ke status akhir yang tertutup. Kolom resolusi biasanya juga diisi pada saat ini. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Closed' atau 'Done'. Jenis peristiwa inferred
	Perubahan menunggu persetujuan	Menandakan bahwa permintaan perubahan telah melewati peninjauan awal dan sedang menunggu keputusan resmi dari Change Advisory Board (CAB) atau pemberi persetujuan yang ditunjuk. Peristiwa ini tercatat saat status dalam alur kerja berubah, misalnya menjadi 'Pending Approval' atau 'Awaiting CAB'.
Mengapa ini penting Aktivitas ini penting untuk mengukur waktu tunggu persetujuan dan menemukan hambatan pada tahap pengambilan keputusan, yang berdampak langsung pada KPI Waktu Siklus Persetujuan Perubahan. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah ke status persetujuan, seperti 'Pending CAB Approval' atau 'Awaiting Approval'. Pengumpulan data Catat stempel waktu saat status berubah menjadi status 'Awaiting Approval' yang ditetapkan. Jenis peristiwa inferred
	Penerapan dimulai	Menandai dimulainya penerapan teknis atas perubahan yang disetujui. Peristiwa ini biasanya tercatat saat status Jira berubah dari 'Approved' atau 'Scheduled' menjadi 'In Progress' atau 'Implementing'.
Mengapa ini penting Aktivitas ini memulai pengukuran Rata-rata Waktu Tunggu Penerapan dan membantu menemukan hambatan selama tahap pelaksanaan. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah menjadi status penerapan aktif, seperti 'In Progress'. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'In Progress' atau 'Implementing'. Jenis peristiwa inferred
	Pengujian dilakukan	Menandai selesainya pengujian setelah penerapan untuk memvalidasi perubahan. Peristiwa ini dapat tercatat sebagai status tersendiri, seperti 'In Testing', atau diketahui dari komentar maupun pembaruan oleh tim QA setelah peristiwa 'Perubahan Diterapkan'.
Mengapa ini penting Analisis durasi dan hasil pengujian membantu mengevaluasi kualitas penerapan dan efektivitas proses pengujian. Informasi ini menjadi masukan penting untuk menghitung Tingkat Masalah Setelah Penerapan. Sumber data Peristiwa ini dapat diketahui dari perubahan status menjadi 'Testing' atau 'Under Test', atau dengan menganalisis komentar dan perubahan penanggung jawab dalam riwayat isu setelah penerapan. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'In Testing' atau berdasarkan komentar. Jenis peristiwa inferred
	Penilaian risiko dilakukan	Menandai selesainya analisis risiko dan dampak untuk perubahan yang diusulkan. Peristiwa ini sering diketahui dari riwayat isu saat kolom khusus terkait risiko, seperti 'Risk Level' atau 'Impact', diisi atau diperbarui.
Mengapa ini penting Analisis aktivitas ini membantu mengevaluasi ketepatan penilaian risiko dan memastikan kepatuhan terhadap kebijakan perubahan. Aktivitas ini penting untuk menghitung KPI berbasis risiko, seperti Tingkat Kegagalan Perubahan berdasarkan Tingkat Risiko. Sumber data Diketahui dari riwayat isu Jira dengan mencatat stempel waktu saat kolom tertentu, seperti 'Risk Level', 'Impact', atau 'Urgency', pertama kali diisi atau diubah. Pengumpulan data Catat stempel waktu saat kolom seperti 'Risk Level' atau 'Impact' pertama kali diisi. Jenis peristiwa inferred
	Permintaan perubahan ditolak	Menandai penolakan resmi atas permintaan perubahan. Biasanya, permintaan dikembalikan kepada pemohon untuk dilengkapi atau dibatalkan. Peristiwa ini tercatat saat status dalam alur kerja Jira berubah menjadi 'Rejected' atau 'Needs More Info'.
Mengapa ini penting Melacak penolakan penting untuk menganalisis Tingkat Pengerjaan Ulang Perubahan. Aktivitas ini yang sering terjadi menandakan adanya masalah pada kualitas pengajuan perubahan awal. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah menjadi 'Rejected' atau status akhir serupa. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Rejected' atau 'Declined'. Jenis peristiwa inferred
	Perubahan diajukan untuk ditinjau	Menandai saat informasi awal permintaan perubahan sudah lengkap dan secara resmi diajukan untuk dinilai. Peristiwa ini biasanya diketahui dari perubahan status dalam alur kerja Jira, misalnya dari 'Draft' menjadi 'Pending Review'.
Mengapa ini penting Aktivitas ini memulai siklus persetujuan. Mengukur waktu dari tahap ini hingga persetujuan penting untuk menghitung KPI waktu siklus persetujuan dan menemukan hambatan di tahap awal. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah ke status peninjauan, seperti 'Pending Review' atau 'Awaiting Assessment'. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Pending Review', 'Submitted', atau status serupa. Jenis peristiwa inferred
	Perubahan dibatalkan	Menandai penghentian permintaan perubahan sebelum penerapan atau penyelesaian. Peristiwa ini tercatat saat status isu Jira berubah ke status akhir, seperti 'Canceled' atau 'Withdrawn'.
Mengapa ini penting Titik akhir alternatif ini membantu menganalisis alasan perubahan dibatalkan. Tingkat pembatalan yang tinggi dapat menandakan perencanaan awal yang kurang baik atau perubahan prioritas bisnis. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' berubah menjadi 'Canceled' dan resolusi terkait ditetapkan. Pengumpulan data Catat stempel waktu saat status berubah menjadi 'Canceled' atau 'Withdrawn'. Jenis peristiwa inferred
	Perubahan dijadwalkan	Menandakan bahwa perubahan yang disetujui telah mendapat jadwal penerapan tertentu. Peristiwa ini diketahui saat kolom 'Planned start date' dan 'Planned end date' pada isu Jira diisi atau diperbarui.
Mengapa ini penting Aktivitas ini memberi gambaran tentang perencanaan perubahan ke depan. Informasi ini membantu pengelolaan sumber daya dan penilaian waktu antara persetujuan dan penerapan yang dijadwalkan. Sumber data Diketahui dari riwayat isu Jira dengan mencatat stempel waktu saat kolom tanggal seperti 'Planned start date' atau 'Change window' diisi. Pengumpulan data Catat stempel waktu saat kolom 'Planned start date' diisi. Jenis peristiwa inferred
	Tinjauan setelah penerapan selesai	Menandakan selesainya tinjauan resmi untuk menilai keberhasilan perubahan dan mencatat pelajaran yang diperoleh. Peristiwa ini biasanya tercatat saat status dalam alur kerja berubah, misalnya dari 'Post-Implementation Review' menjadi 'Verified'.
Mengapa ini penting Aktivitas ini penting untuk perbaikan proses. Mengukur waktu siklus tinjauan membantu memastikan pelajaran yang diperoleh segera dicatat. Sumber data Diketahui dari riwayat isu Jira dengan mencari stempel waktu saat kolom 'status' keluar dari status 'Post-Implementation Review'. Pengumpulan data Catat stempel waktu saat status berubah dari 'PIR' ke status berikutnya. Jenis peristiwa inferred

Disarankan Opsional

Panduan ekstraksi data

Cara mengambil data dari Jira Service Management

Langkah

Buka Issue Navigator di Jira: Masuk ke instans Jira Service Management Anda. Di bilah navigasi utama, pilih 'Issues', lalu pilih 'Search for issues' untuk membuka Issue Navigator.
Beralih ke pencarian JQL: Jika Anda menggunakan mode pencarian 'Basic', beralihlah ke mode lanjutan dengan mengeklik 'JQL' (atau 'Advanced' pada beberapa versi). Anda dapat memasukkan kueri Jira Query Language (JQL) khusus.
Filter permintaan perubahan: Masukkan kueri JQL yang tercantum di bagian 'query' dokumen ini ke bilah pencarian. Sesuaikan placeholder untuk kunci proyek, nama jenis masalah perubahan, dan rentang tanggal yang diinginkan.
Jalankan pencarian dan ekspor data: Jalankan pencarian. Setelah daftar masalah permintaan perubahan muncul, cari tombol 'Export', biasanya di pojok kanan atas. Pilih 'Export Excel CSV (all fields)'. Format ini penting karena menyertakan riwayat masalah terperinci yang diperlukan untuk menyusun ulang alur proses.
Muat CSV untuk transformasi: Buka file CSV yang diunduh dengan alat persiapan data seperti Power Query, skrip Python dengan pustaka pandas, atau alat ETL lainnya. Ekspor mentah berisi satu baris untuk setiap masalah, dengan kolom yang memuat data historis.
Susun data dasar: Untuk setiap baris di file sumber, buat peristiwa awal 'Change Request Created'. Gunakan 'Issue key' sebagai ChangeRequestId, tetapkan ActivityName ke 'Change Request Created', dan gunakan kolom 'Created' untuk EventTime.
Ubah riwayat status menjadi baris: Cari kolom yang memuat riwayat perubahan status. Setiap perubahan status adalah satu peristiwa. Untuk setiap permintaan perubahan, buat baris baru untuk setiap perubahan status yang relevan, misalnya dari 'Draft' ke 'Pending Review' atau dari 'Pending Approval' ke 'Approved'. Petakan perubahan ini ke ActivityName yang sesuai, seperti 'Change Submitted For Review', 'Change Awaiting Approval', 'Change Request Approved', dan seterusnya. Waktu perubahan status menjadi EventTime.
Ubah riwayat pembaruan kolom menjadi baris: Beberapa aktivitas disimpulkan dari pembaruan kolom, bukan perubahan status. Olah riwayat kolom seperti 'Risk Level', 'Planned start date', dan 'Planned end date'. Buat baris baru untuk peristiwa 'Risk Assessment Performed' dan 'Change Scheduled', menggunakan waktu saat kolom tersebut pertama kali diisi atau diperbarui.
Petakan dan lengkapi atribut: Untuk setiap baris peristiwa yang dibuat, petakan kolom Jira terkait ke atribut yang diperlukan, seperti ChangeRequestStatus, ChangeRequestType, Assignee, dan Priority. Gunakan nilai yang berlaku pada saat peristiwa terjadi.
Tambahkan kolom metadata: Tambahkan kolom bernama SourceSystem dengan nilai tetap 'Jira Service Management'. Tambahkan kolom LastDataUpdate dan isi dengan waktu ekstraksi dilakukan.
Hitung metrik turunan: Setelah seluruh log peristiwa dibuat, hitung atribut yang memerlukan beberapa titik data, seperti ApprovalCycleTime. Caranya, hitung selisih waktu antara peristiwa 'Change Submitted For Review' dan 'Change Request Approved' untuk setiap ChangeRequestId.
Selesaikan dan ekspor untuk diunggah: Pastikan tabel akhir memiliki kolom yang diperlukan: ChangeRequestId, ActivityName, dan EventTime. Hapus kolom perantara atau kolom sumber. Simpan data hasil transformasi sebagai file CSV dengan encoding UTF-8, lalu unggah ke alat process mining.

Konfigurasi

Filter JQL: Kueri JQL menjadi alat utama untuk memilih kumpulan data yang tepat. Filter penting mencakup project, issuetype, dan rentang tanggal pada kolom created untuk membatasi ekstraksi.
Rentang tanggal: Sebaiknya mulai dengan data selama 3 hingga 6 bulan agar mewakili proses tanpa menimbulkan masalah kinerja. Contoh: created >= "-180d".
Jenis masalah: Tentukan nama persis jenis masalah yang digunakan untuk pengelolaan perubahan di instans Jira Anda, misalnya issuetype = "Change" atau issuetype = "Change Request".
Format ekspor: Selalu gunakan 'Export Excel CSV (all fields)'. Opsi ini menyertakan semua kolom khusus dan, yang terpenting, seluruh riwayat changelog untuk status dan kolom dalam file ekspor. Ekspor dengan kolom terbatas tidak memuat data yang diperlukan untuk menyusun log peristiwa.
Izin Jira: Pengguna yang melakukan ekspor harus memiliki izin 'Browse Projects' untuk proyek yang ditentukan dan izin lain yang diperlukan untuk melihat semua kolom masalah terkait.
Identifikasi kolom khusus: Sebelum melakukan transformasi, cari nama persis kolom khusus di instans Jira Anda yang sesuai dengan atribut proses seperti 'Risk Level', 'Planned start date', dan 'Change Type'.

Contoh kueri config

project = "[Your_Project_Key]" AND issuetype = "Change" AND created >= "[Start_Date_YYYY-MM-DD]" AND created <= "[End_Date_YYYY-MM-DD]" ORDER BY created ASC

Langkah

Hubungkan ke basis data: Dapatkan kredensial akses hanya-baca untuk basis data Jira Server atau Data Center Anda, yang dapat menggunakan PostgreSQL, MySQL, SQL Server, atau Oracle. Hubungkan ke basis data dengan klien SQL standar seperti DBeaver, SQL Developer, atau pgAdmin.
Periksa konfigurasi Jira: Sebelum menjalankan kueri, cari nama khusus yang digunakan dalam konfigurasi Jira Service Management Anda. Masuk ke Jira dan buka proyek pengelolaan perubahan. Catat informasi berikut:
- Kunci proyek: Pengenal singkat proyek Anda, misalnya 'CSM'.
- Nama jenis masalah: Nama persis untuk permintaan perubahan, biasanya 'Change'.
- Status workflow: Nama setiap status dalam workflow perubahan, seperti 'Pending Review', 'Pending Approval', 'In Progress', 'Closed', dan lainnya.
- Nama kolom khusus: Nama kolom khusus untuk 'Change Type', 'Risk Level', 'Planned start date', dan 'Planned end date'.
Sesuaikan kueri SQL: Buka kueri SQL yang disediakan di klien SQL Anda. Ganti nilai placeholder dengan informasi yang dikumpulkan pada langkah sebelumnya. Placeholder utama yang perlu diperbarui adalah [Your_JSM_Project_Key], [Your Change Type Field Name], [Your Risk Level Field Name], [Your Planned Start Date Field Name], [Your Planned End Date Field Name], serta semua nama status dalam klausa WHERE.
Tentukan rentang tanggal: Cari baris AND i.created >= '[YYYY-MM-DD]' di Common Table Expression (CTE) awal. Ubah tanggal untuk menentukan awal ekstraksi data. Langkah ini penting untuk membatasi volume data dan meningkatkan kinerja kueri.
Jalankan kueri: Jalankan kueri SQL yang telah diubah pada basis data Jira. Proses ini dapat memerlukan beberapa menit, bergantung pada ukuran instans Jira dan rentang tanggal yang dipilih.
Periksa hasil: Setelah kueri selesai, periksa sekilas hasilnya di klien SQL untuk memastikan baris muncul dan kolom seperti ChangeRequestId, ActivityName, serta EventTime terisi dengan benar.
Ekspor data ke CSV: Ekspor seluruh hasil kueri dari klien SQL ke file CSV. Pastikan pengaturan ekspor menyertakan judul kolom, menggunakan koma sebagai pemisah, dan memakai encoding UTF-8.
Siapkan file untuk diunggah: Beri nama file yang jelas, misalnya jira_change_management_log.csv. File ini siap diunggah ke alat process mining untuk dianalisis.

Konfigurasi

Akses basis data: Anda memerlukan akun pengguna hanya-baca untuk basis data produksi Jira. Akses langsung ke basis data hanya tersedia untuk instans Jira Server dan Jira Data Center, bukan Jira Cloud.
Kunci proyek Jira: Kueri harus menggunakan kunci khusus proyek Jira Service Management Anda. Temukan dan ubah nilainya pada klausa p.pkey IN ('[Your_JSM_Project_Key]').
Jenis masalah untuk perubahan: Kueri mengasumsikan nama jenis masalah untuk permintaan perubahan adalah 'Change'. Jika konfigurasi Anda menggunakan nama lain, perbarui filter issuetype.pname = 'Change'.
Pemetaan status workflow: Keakuratan log peristiwa sepenuhnya bergantung pada pemetaan nama status dalam klausa WHERE kueri ke status workflow yang benar di proyek Anda. Periksa dan perbarui setiap teks 'Status Name' dengan cermat.
Pemetaan kolom khusus: Kueri menggunakan nama kolom khusus untuk melacak aktivitas tertentu ('Risk Assessment Performed', 'Change Scheduled') dan atribut. Pastikan nama seperti '[Your Risk Level Field Name]' sesuai dengan konfigurasi Jira Anda.
Rentang tanggal: Sebaiknya mulai dengan rentang terbatas, misalnya 3 hingga 6 bulan (i.created >= '[YYYY-MM-DD]'), agar volume data dan kinerja kueri tetap terkendali. Ekstraksi data beberapa tahun dapat berlangsung sangat lama.
Kinerja: Menjalankan kueri ini dapat memengaruhi kinerja basis data Jira yang memiliki jutaan masalah. Sebaiknya jalankan di luar jam sibuk. Terapkan filter rentang tanggal untuk membatasi cakupan data.

Contoh kueri sql

WITH ChangeRequestAttributes AS (
    SELECT
        i.id AS issueid,
        i.pkey AS ChangeRequestId,
        i.created,
        i.duedate AS TargetCompletionDate,
        istat.pname AS ChangeRequestStatus,
        u.display_name AS Assignee,
        prio.pname AS Priority,
        ct.customvalue AS ChangeRequestType,
        rl.customvalue AS RiskLevel
    FROM
        jiraissue i
    JOIN
        project p ON i.project = p.id
    LEFT JOIN
        issuestatus istat ON i.issuestatus = istat.id
    LEFT JOIN
        priority prio ON i.priority = prio.id
    LEFT JOIN
        app_user au ON i.assignee = au.user_key
    LEFT JOIN
        cwd_user u ON au.lower_user_name = u.lower_user_name
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Change Type Field Name]'
    ) ct ON i.id = ct.issue
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Risk Level Field Name]'
    ) rl ON i.id = rl.issue
    WHERE
        p.pkey IN ('[Your_JSM_Project_Key]')
        AND i.issuetype = (SELECT id FROM issuetype WHERE pname = 'Change')
        AND i.created >= '[YYYY-MM-DD]'
)
-- 1. Change Request Created
SELECT
    cra.ChangeRequestId,
    'Change Request Created' AS ActivityName,
    cra.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    ChangeRequestAttributes cra

UNION ALL

-- All subsequent events from issue history
SELECT
    cra.ChangeRequestId,
    CASE 
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Review' THEN 'Change Submitted For Review'
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Approval' THEN 'Change Awaiting Approval'
        WHEN ci.field = 'status' AND ci.newstring = 'Approved' THEN 'Change Request Approved'
        WHEN ci.field = 'status' AND ci.newstring = 'Rejected' THEN 'Change Request Rejected'
        WHEN ci.field = 'status' AND ci.newstring = 'In Progress' THEN 'Implementation Started'
        WHEN ci.field = 'status' AND ci.newstring = 'Implemented' THEN 'Change Implemented'
        WHEN ci.field = 'status' AND ci.newstring = 'In Testing' THEN 'Testing Performed'
        WHEN ci.field = 'status' AND ci.newstring = 'Verified' AND ci.oldstring = 'Post-Implementation Review' THEN 'Post-Implementation Review Done'
        WHEN ci.field = 'status' AND ci.newstring = 'Closed' THEN 'Change Closed'
        WHEN ci.field = 'status' AND ci.newstring = 'Canceled' THEN 'Change Canceled'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]') AND ci.oldvalue IS NULL THEN 'Risk Assessment Performed'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]') AND ci.oldvalue IS NULL THEN 'Change Scheduled'
    END AS ActivityName,
    cg.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    changegroup cg
JOIN
    changeitem ci ON cg.id = ci.groupid
JOIN
    ChangeRequestAttributes cra ON cg.issueid = cra.issueid
WHERE
    (
        ci.fieldtype = 'jira' AND ci.field = 'status' AND ci.newstring IN (
            'Pending Review', 'Pending Approval', 'Approved', 'Rejected', 
            'In Progress', 'Implemented', 'In Testing', 'Verified', 'Closed', 'Canceled'
        )
    )
    OR
    (
        ci.fieldtype = 'custom' AND ci.fieldid IN (
            (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]'),
            (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]')
        ) AND ci.oldvalue IS NULL
    )
ORDER BY
    ChangeRequestId, EventTime;

Langkah

Siapkan lingkungan Python: Pastikan Python 3.6 atau versi lebih baru sudah terpasang. Pasang pustaka yang diperlukan, yaitu requests untuk melakukan panggilan API dan pandas untuk mengolah data, dengan menjalankan perintah: pip install requests pandas.
Buat token Jira API: Masuk ke akun Jira Anda. Buka pengaturan profil, pilih 'Account settings', lalu buka tab 'Security' dan klik 'Create and manage API tokens'. Buat token baru dan simpan dengan aman. Token ini akan digunakan sebagai kata sandi untuk autentikasi API.
Atur skrip Python: Buka skrip Python yang disediakan di editor. Ganti nilai placeholder JIRA_URL, JIRA_EMAIL, dan JIRA_API_TOKEN dengan URL instans Jira, alamat email, dan token API yang Anda buat.
Sesuaikan kueri JQL: Ubah variabel JQL_QUERY dalam skrip agar mengarah ke proyek dan jenis masalah Jira Service Management yang benar. Misalnya, ganti project = "CSM" dengan kunci proyek Anda. Sesuaikan rentang tanggal dalam kueri untuk membatasi periode ekstraksi dan meningkatkan kinerja.
Petakan kolom khusus dan status: Periksa kamus STATUS_TO_ACTIVITY_MAPPING dan FIELD_TO_ACTIVITY_MAPPING dalam skrip. Perbarui nama status Jira, misalnya 'Pending Approval', dan nama kolom khusus, misalnya 'Risk Level', agar sama persis dengan yang digunakan dalam workflow Jira Anda. Gunakan halaman administrasi kolom khusus Jira untuk menemukan ID yang benar bagi kolom seperti customfield_10050.
Jalankan skrip: Jalankan skrip dari terminal dengan perintah python your_script_name.py. Skrip akan terhubung ke Jira API, mengambil masalah permintaan perubahan, lalu mengolah riwayatnya.
Pantau jalannya skrip: Skrip akan menampilkan pesan kemajuan di konsol, termasuk jumlah masalah yang diambil dan diolah. Untuk kumpulan data besar, proses ini dapat memerlukan waktu cukup lama.
Periksa hasil: Setelah skrip selesai, file CSV bernama jira_change_management_event_log.csv akan dibuat di direktori yang sama. File ini berisi log peristiwa hasil ekstraksi.
Siapkan file untuk diunggah: Buka file CSV di aplikasi spreadsheet untuk memastikan susunan kolomnya benar, termasuk ChangeRequestId, ActivityName, dan EventTime. File ini siap diunggah ke alat process mining.

Konfigurasi

Kueri JQL: Variabel JQL_QUERY menjadi filter utama untuk ekstraksi. Minimal, variabel ini harus menentukan project, issuetype = 'Change', dan rentang tanggal untuk kolom created, misalnya created >= -180d untuk 180 hari terakhir. Filter tanggal penting untuk mengendalikan volume data.
Pemetaan status dan kolom: Keakuratan skrip sepenuhnya bergantung pada kamus STATUS_TO_ACTIVITY_MAPPING dan FIELD_TO_ACTIVITY_MAPPING. Atur keduanya agar sesuai dengan status workflow Jira dan nama kolom khusus di organisasi Anda sehingga aktivitas yang dihasilkan benar.
Kredensial API: Skrip memerlukan JIRA_URL, JIRA_EMAIL, dan JIRA_API_TOKEN yang valid untuk autentikasi. Pengguna yang terkait dengan token harus memiliki izin baca untuk proyek dan semua kolom terkait.
Paginasi data: Skrip menggunakan parameter maxResults (ditetapkan ke 100) untuk mengambil masalah dari API secara bertahap atau per halaman. Cara ini penting agar banyak masalah dapat diekstrak tanpa mengalami timeout.
Perluasan changelog: Parameter expand=changelog dalam permintaan API sangat penting. Parameter ini meminta Jira menyertakan seluruh riwayat perubahan kolom untuk setiap masalah, yang menjadi sumber sebagian besar aktivitas.

Contoh kueri python

import requests
import json
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-domain].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your_jira_api_token]"

class=class="hl-string">"hl-comment"># JQL to select Change Management issues. Itclass="hl-string">'s recommended to add a date filter, e.g., 'AND created >= -180d'
JQL_QUERY = class="hl-string">'project = "CSM" AND issuetype = "Change" ORDER BY created DESC'

class=class="hl-string">"hl-comment"># --- Mappings - CRITICAL: Customize these to match your Jira workflow --- #
class=class="hl-string">"hl-comment"># Map Jira status names to standardized Activity Names
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Pending Review': class="hl-string">'Change Submitted For Review',
    class="hl-string">'Pending Approval': class="hl-string">'Change Awaiting Approval',
    class="hl-string">'Approved': class="hl-string">'Change Request Approved',
    class="hl-string">'Rejected': class="hl-string">'Change Request Rejected',
    class="hl-string">'In Progress': class="hl-string">'Implementation Started',
    class="hl-string">'Implemented': class="hl-string">'Change Implemented',
    class="hl-string">'Post-Implementation Review': class="hl-string">'Post-Implementation Review Done',
    class="hl-string">'Closed': class="hl-string">'Change Closed',
    class="hl-string">'Canceled': class="hl-string">'Change Canceled',
    class=class="hl-string">"hl-comment"># Add other custom statuses from your workflow
}

class=class="hl-string">"hl-comment"># Map Jira field updates to standardized Activity Names
class=class="hl-string">"hl-comment"># Use field names as they appear in the API changelog. Custom fields might have different names.
FIELD_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Risk Level': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Planned start date': class="hl-string">'Change Scheduled',
    class="hl-string">'Testing Status': class="hl-string">'Testing Performed', class=class="hl-string">"hl-comment"># Example for a custom class="hl-string">'Testing Status' field
}
class=class="hl-string">"hl-comment"># --- End of Configuration --- #

def get_issues(auth):
    class="hl-string">"""Paginates through JQL results to fetch all issues."""
    all_issues = []
    start_at = 0
    max_results = 100

    while True:
        api_endpoint = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'fields': class="hl-string">'*all',
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_endpoint, auth=auth, params=params, headers={class="hl-string">'Accept': class="hl-string">'application/json'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an error for bad responses (4xx or 5xx)
            data = response.json()
            issues = data.get(class="hl-string">'issues', [])
            all_issues.extend(issues)

            print(fclass="hl-string">"Fetched {len(issues)} issues, total so far: {len(all_issues)}")

            if len(issues) < max_results:
                break class=class="hl-string">"hl-comment"># Exit loop if this is the last page
            start_at += len(issues)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching issues: {e}")
            break

    return all_issues

def parse_issues_to_event_log(issues):
    class="hl-string">"""Parses issues and their changelogs into a structured event log."""
    event_log = []
    source_system = class="hl-string">"Jira Service Management"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        
        class=class="hl-string">"hl-comment"># 1. Handle class="hl-string">'Change Request Created' event
        event_log.append({
            class="hl-string">'ChangeRequestId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': fields.get(class="hl-string">'created'),
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'ChangeRequestStatus': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
            class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
            class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
            class="hl-string">'ApprovalCycleTime': None, class=class="hl-string">"hl-comment"># Requires post-processing to calculate
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># Requires post-processing to calculate
        })

        class=class="hl-string">"hl-comment"># 2. Parse changelog for all other events
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        for history in changelog:
            event_time = history[class="hl-string">'created']
            for item in history.get(class="hl-string">'items', []):
                activity_name = None
                class=class="hl-string">"hl-comment"># Map status changes
                if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status':
                    activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'toString'))
                class=class="hl-string">"hl-comment"># Map field updates
                elif item.get(class="hl-string">'field') in FIELD_TO_ACTIVITY_MAPPING:
                    activity_name = FIELD_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'field'))

                if activity_name:
                    event_log.append({
                        class="hl-string">'ChangeRequestId': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'SourceSystem': source_system,
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'ChangeRequestStatus': item.get(class="hl-string">'toString') if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status' else fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
                        class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'),
                        class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
                        class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'),
                        class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                        class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
                        class="hl-string">'ApprovalCycleTime': None,
                        class="hl-string">'SLAStatus': None
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira data extraction...")
    jira_auth = (JIRA_EMAIL, JIRA_API_TOKEN)
    
    issues_data = get_issues(jira_auth)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues into an event log...")
        event_log_data = parse_issues_to_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        df_sorted = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'jira_change_management_event_log.csv'
        df_sorted.to_csv(output_filename, index=False)
        print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

Siap memulai?

Gunakan templat data ini untuk memulai process mining pada pengelolaan perubahan. Ubah data mentah Anda menjadi wawasan yang dapat ditindaklanjuti.

Kembali ke panduan perbaikan

Unduh template

Tingkatkan pengelolaan perubahan: raih keberhasilan 95%

Kurangi perubahan yang gagal dan tingkatkan tingkat keberhasilan hingga 95% dengan mudah.

Mulai uji coba gratis

Tidak perlu kartu kredit. Siapkan dalam hitungan menit.

Templat data pengelolaan perubahan

Templat data pengelolaan perubahan

Atribut pengelolaan perubahan

Aktivitas pengelolaan perubahan

Panduan ekstraksi data

Ekspor masalah bawaan Jira Service Management ke CSV

Langkah

Konfigurasi

Contoh kueri config

Kueri SQL langsung ke basis data Jira Server/Data Center

Langkah

Konfigurasi

Contoh kueri sql

Ekstraksi dengan skrip Python melalui Jira REST API dan JQL

Langkah

Konfigurasi

Contoh kueri python

Siap memulai?

Tingkatkan pengelolaan perubahan: raih keberhasilan 95%