Templat data manajemen perubahan Anda
Templat data manajemen perubahan Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi data dari Ivanti Cherwell
Atribut manajemen perubahan
| Nama | Deskripsi | ||
|---|---|---|---|
|
ID Permintaan Perubahan
ChangeRequestId
|
Pengenal unik untuk satu kasus permintaan perubahan, yang mengelompokkan semua aktivitas terkait dari pengajuan hingga penutupan. | ||
|
Deskripsi
ID Permintaan Perubahan adalah kunci utama yang membedakan setiap inisiatif perubahan sepanjang siklusnya. Dalam process mining, ID ini berfungsi sebagai pengenal kasus yang menghubungkan semua peristiwa, seperti pengajuan, penilaian, persetujuan, dan penerapan, ke dalam satu rangkaian proses. Analisis berdasarkan ID Permintaan Perubahan memberikan gambaran menyeluruh tentang proses manajemen perubahan. Anda dapat melacak setiap perubahan, menghitung total waktu siklus, serta menemukan penyimpangan atau hambatan yang terkait dengan permintaan tertentu.
Mengapa ini penting
Pengenal kasus ini menghubungkan semua peristiwa terkait, sehingga seluruh perjalanan permintaan perubahan dapat ditelusuri dan kinerjanya dianalisis.
Sumber data
Biasanya, ini adalah pengenal utama objek bisnis Change Request di Ivanti Cherwell.
Contoh
CR-105421CR-105422CR-105423
|
|||
|
Nama aktivitas
ActivityName
|
Nama peristiwa atau tugas tertentu yang terjadi pada suatu waktu dalam proses manajemen perubahan. | ||
|
Deskripsi
Nama Aktivitas menjelaskan langkah atau tonggak tertentu dalam siklus permintaan perubahan, seperti 'Change Submitted For Assessment' atau 'Change Approved by CAB'. Aktivitas ini menjadi simpul dalam peta proses yang ditemukan. Dalam analisis, atribut ini menjadi dasar untuk memvisualisasikan alur proses, mengenali urutan peristiwa, dan menemukan penyimpangan dari prosedur standar. Atribut ini juga digunakan untuk menghitung waktu perpindahan antaraktivitas dan mengetahui titik terjadinya keterlambatan.
Mengapa ini penting
Atribut ini penting untuk menemukan dan memvisualisasikan alur proses yang sebenarnya, serta mengenali hambatan, pengulangan pekerjaan, dan jalur yang tidak mematuhi ketentuan.
Sumber data
Dihasilkan dari perubahan status, entri jurnal, atau log peristiwa tertentu yang terkait dengan objek Change Request di Ivanti Cherwell.
Contoh
Perubahan diajukan untuk penilaianPerubahan menunggu persetujuanPerubahan diterapkan
|
|||
|
Waktu peristiwa
EventTime
|
Waktu yang menunjukkan kapan aktivitas atau peristiwa tertentu terjadi pada permintaan perubahan. | ||
|
Deskripsi
Waktu peristiwa, atau stempel waktu, mencatat tanggal dan waktu persis saat suatu aktivitas berlangsung. Data waktu ini diperlukan untuk mengurutkan peristiwa secara kronologis dan menjadi dasar analisis process mining berbasis waktu. Atribut ini digunakan untuk menghitung durasi antaraktivitas, mengukur waktu siklus keseluruhan kasus, serta menemukan waktu tunggu atau keterlambatan dalam proses. Atribut ini juga menjadi dasar pembuatan dashboard untuk memantau kinerja terhadap target waktu, seperti Waktu Siklus Persetujuan Perubahan.
Mengapa ini penting
Stempel waktu ini menjadi dasar analisis kinerja dan durasi. Dengan data ini, Anda dapat menghitung waktu siklus, menemukan hambatan, dan memantau SLA.
Sumber data
Biasanya tersedia dalam log perubahan status, jejak audit, atau stempel waktu entri jurnal yang terkait dengan objek Change Request di Ivanti Cherwell.
Contoh
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Pembaruan data terakhir
LastDataUpdate
|
Waktu yang menunjukkan kapan data untuk peristiwa ini terakhir diekstrak atau diperbarui dari sistem sumber. | ||
|
Deskripsi
Atribut ini mencatat tanggal dan waktu terakhir kali data diambil dari Ivanti Cherwell. Atribut ini bukan peristiwa dalam proses, melainkan metadata tentang kebaruan data. Informasi ini membantu pengguna dashboard mengetahui seberapa mutakhir analisis yang ditampilkan. Atribut ini juga membantu mengatur jadwal pembaruan data dan memastikan keputusan dibuat berdasarkan data dengan usia yang diketahui.
Mengapa ini penting
Menunjukkan kebaruan data. Informasi ini penting agar pengguna dapat memercayai analisis dan memahami relevansinya terhadap kondisi operasional saat ini.
Sumber data
Stempel waktu ini dibuat dan dicantumkan pada setiap rekaman selama proses ekstraksi, transformasi, dan pemuatan data (ETL).
Contoh
2024-05-21T02:00:00Z
|
|||
|
Sistem sumber
SourceSystem
|
Sistem pencatatan asal tempat data diekstrak. Untuk tampilan ini, sistemnya adalah 'Ivanti Cherwell'. | ||
|
Deskripsi
Atribut ini menunjukkan sistem asal data peristiwa. Dalam lingkungan dengan beragam sistem, atribut ini membantu membedakan data dari tiap sumber. Untuk model data ini, nilainya tetap dan menunjukkan bahwa data berasal dari Ivanti Cherwell. Meski nilainya mungkin tidak berubah dalam model dengan satu sumber, atribut ini penting untuk tata kelola data, ketertelusuran, dan integrasi dengan sistem lain di masa mendatang. Atribut ini memperjelas asal data dan membantu menjaga kualitas data.
Mengapa ini penting
Memberikan konteks penting tentang asal data, yang diperlukan untuk tata kelola data, pemecahan masalah, dan memastikan data dapat ditelusuri.
Sumber data
Biasanya, nilai tetap ini ditambahkan saat proses ekstraksi dan transformasi data untuk menandai asal kumpulan data.
Contoh
Ivanti Cherwell
|
|||
|
Jenis perubahan
ChangeType
|
Klasifikasi perubahan, seperti 'Standard', 'Normal', atau 'Emergency'. | ||
|
Deskripsi
Jenis Perubahan mengelompokkan permintaan perubahan berdasarkan sifat, urgensi, dan dampaknya. Jenis yang umum mencakup Standard (telah disetujui sebelumnya dan berisiko rendah), Normal (memerlukan penilaian dan persetujuan penuh), serta Emergency (perlu segera diterapkan). Atribut ini memungkinkan analisis kinerja proses berdasarkan kategori. Misalnya, Anda dapat mengetahui apakah perubahan darurat mengikuti jalur yang berbeda dan lebih cepat, atau apakah perubahan standar benar-benar diproses dengan sedikit hambatan. Atribut ini menjadi dasar dashboard 'Kinerja Jenis Perubahan Bermasalah'.
Mengapa ini penting
Mengelompokkan proses berdasarkan Jenis Perubahan penting untuk membandingkan kinerja dan mengetahui apakah kategori tertentu, seperti 'Emergency', menimbulkan hambatan atau penyimpangan.
Sumber data
Sesuai dengan kolom klasifikasi, yang kemungkinan bernama 'Change Type' atau 'Category', pada objek bisnis Change Request.
Contoh
StandarNormalDarurat
|
|||
|
Penanggung jawab perubahan
ChangeOwner
|
Pengguna atau individu yang saat ini bertanggung jawab atas permintaan perubahan. | ||
|
Deskripsi
Penanggung Jawab Perubahan adalah orang yang ditugaskan dan bertanggung jawab atas permintaan perubahan pada tahap tertentu. Atribut ini sering berubah seiring berjalannya permintaan, yang menunjukkan perpindahan tanggung jawab antarindividu. Analisis Penanggung Jawab Perubahan membantu memahami beban kerja sumber daya dan menemukan hambatan yang terkait dengan individu tertentu. Atribut ini juga penting untuk menganalisis serah terima, yang dapat menjadi sumber keterlambatan. Atribut ini mendukung dashboard 'Serah Terima Perubahan dan Pemanfaatan Sumber Daya'.
Mengapa ini penting
Melacak tanggung jawab individu untuk menganalisis pembagian beban kerja, frekuensi serah terima, dan hambatan terkait sumber daya tertentu.
Sumber data
Biasanya berupa kolom 'Owned By' atau 'Assigned To' pada objek bisnis Change Request.
Contoh
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Status perubahan
ChangeStatus
|
Status permintaan perubahan saat ini atau status akhirnya, seperti 'Closed', 'Rejected', atau 'In Progress'. | ||
|
Deskripsi
Status Perubahan menunjukkan keadaan permintaan perubahan pada waktu tertentu atau hasil akhirnya. Atribut ini penting untuk memahami penyelesaian kasus dan mengenali pengecualian. Dalam analisis proses, atribut ini digunakan untuk menyaring hasil tertentu, misalnya hanya menganalisis perubahan yang ditolak atau dibatalkan. Atribut ini mendukung KPI seperti 'Tingkat Penolakan Permintaan Perubahan' dan penting untuk memahami kondisi serta efisiensi proses manajemen perubahan secara keseluruhan.
Mengapa ini penting
Menentukan hasil permintaan perubahan, sehingga Anda dapat menganalisis tingkat penolakan dan penyelesaian, serta perbandingan kasus terbuka dan tertutup.
Sumber data
Sesuai dengan kolom 'Status' pada objek bisnis Change Request di Ivanti Cherwell.
Contoh
DisetujuiDitolakDitutupDibatalkanMenunggu persetujuan
|
|||
|
Tanggal target penyelesaian
TargetCompletionDate
|
Tenggat yang direncanakan atau disepakati untuk menyelesaikan penerapan perubahan. | ||
|
Deskripsi
Tanggal Target Penyelesaian adalah tanggal dan waktu saat perubahan diharapkan selesai diterapkan dan diverifikasi. Tanggal ini sering tercantum dalam Perjanjian Tingkat Layanan (SLA) dan menjadi tolok ukur utama kinerja. Atribut ini penting untuk memantau ketepatan waktu dan kepatuhan terhadap tenggat. Tanggal ini dibandingkan dengan tanggal penyelesaian aktual untuk menghitung KPI 'Tingkat Penyelesaian Perubahan Tepat Waktu' dan 'Tingkat Kepatuhan SLA Perubahan'. Atribut ini membantu mengenali lebih awal perubahan yang berisiko tidak mencapai target.
Mengapa ini penting
Menjadi acuan untuk mengukur ketepatan waktu dan kepatuhan SLA, dua indikator penting efisiensi dan keandalan proses.
Sumber data
Biasanya berupa kolom tanggal khusus pada objek Change Request, dengan nama seperti 'Target Date', 'Due Date', atau 'SLA Target'.
Contoh
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Tim perubahan
ChangeTeam
|
Tim atau kelompok yang saat ini bertanggung jawab atas permintaan perubahan. | ||
|
Deskripsi
Tim Perubahan adalah kelompok atau departemen yang ditugaskan menangani permintaan perubahan. Seperti Penanggung Jawab Perubahan, tim ini dapat berganti selama proses berlangsung. Misalnya, tanggung jawab dapat berpindah dari service desk ke tim rekayasa jaringan. Atribut ini penting untuk menganalisis serah terima antar tim dan menemukan keterlambatan sistemik yang disebabkan oleh tim tertentu. Atribut ini membantu menjawab tim mana yang kelebihan beban atau di mana komunikasi terhambat, serta mendukung analisis 'Serah Terima Perubahan dan Pemanfaatan Sumber Daya'.
Mengapa ini penting
Menunjukkan tanggung jawab di tingkat tim. Informasi ini penting untuk menganalisis hambatan proses, mengukur kinerja tim, dan memahami keterlambatan serah terima antar kelompok.
Sumber data
Informasi ini biasanya disimpan dalam kolom 'Owned By Team' atau kolom penetapan kelompok serupa pada objek Change Request.
Contoh
Operasional jaringanAdministrasi basis dataDukungan aplikasi
|
|||
|
Tingkat risiko perubahan
ChangeRiskLevel
|
Tingkat risiko yang dinilai untuk perubahan, seperti 'Low', 'Medium', atau 'High'. | ||
|
Deskripsi
Tingkat Risiko Perubahan adalah klasifikasi yang ditetapkan selama tahap penilaian untuk mengukur potensi dampak negatif suatu perubahan. Hasil penilaian ini sering memengaruhi proses persetujuan dan tingkat pemeriksaan yang diperlukan. Dalam process mining, atribut ini digunakan untuk menganalisis konsistensi penilaian risiko dan kaitan antara risiko dengan perilaku proses. Misalnya, Anda dapat memeriksa apakah perubahan berisiko tinggi mengikuti jalur persetujuan yang lebih ketat atau memerlukan waktu penerapan lebih lama. Atribut ini mendukung dashboard 'Konsistensi Penilaian Risiko Perubahan'.
Mengapa ini penting
Memungkinkan analisis tentang dampak risiko terhadap alur proses, siklus persetujuan, dan tingkat keberhasilan. Dengan begitu, perubahan berisiko tinggi dapat diperiksa secara memadai.
Sumber data
Nilai ini disimpan dalam kolom 'Risk Level' atau kolom serupa pada objek Change Request, biasanya diisi saat aktivitas penilaian risiko.
Contoh
RendahSedangTinggiKritis
|
|||
|
Alasan penolakan
ChangeRejectionReason
|
Uraian atau kategori yang menjelaskan alasan permintaan perubahan ditolak. | ||
|
Deskripsi
Saat permintaan perubahan ditolak, atribut ini mencatat alasan yang diberikan oleh pemberi persetujuan. Alasannya dapat dipilih dari daftar yang tersedia atau ditulis secara bebas. Informasi ini penting untuk dashboard 'Analisis Permintaan Perubahan yang Ditolak'. Dengan mengelompokkan dan menganalisis alasan penolakan, organisasi dapat menemukan masalah umum dalam pengajuan perubahan, seperti informasi yang tidak lengkap, penilaian risiko yang kurang memadai, atau konflik bisnis. Temuan ini dapat digunakan untuk meningkatkan kualitas permintaan perubahan berikutnya.
Mengapa ini penting
Memberikan gambaran langsung tentang alasan perubahan gagal, sehingga perbaikan dapat difokuskan pada proses pengajuan dan penilaian untuk mengurangi tingkat penolakan.
Sumber data
Data ini sering dicatat dalam kolom khusus 'Rejection Reason' atau kolom catatan yang diisi saat status berubah menjadi 'Rejected'.
Contoh
Rincian dalam rencana penerapan tidak memadaiPenilaian risiko belum lengkapBertentangan dengan perubahan lain yang telah dijadwalkan
|
|||
|
Layanan terdampak
ServiceAffected
|
Layanan bisnis utama atau item konfigurasi (CI) yang terdampak oleh perubahan. | ||
|
Deskripsi
Atribut ini menunjukkan layanan TI, aplikasi, atau bagian infrastruktur utama yang menjadi sasaran permintaan perubahan. Atribut ini menghubungkan proses manajemen perubahan dengan lanskap manajemen layanan TI yang lebih luas. Analisis berdasarkan Layanan Terdampak penting untuk KPI 'Jenis Perubahan Bermasalah Teratas'. Analisis ini membantu mengetahui layanan yang paling sering mengalami perubahan dan layanan yang terkait dengan tingkat penolakan atau keterlambatan tinggi. Informasi ini membantu pemilik layanan meningkatkan stabilitas dan mengelola utang teknis.
Mengapa ini penting
Menghubungkan perubahan dengan layanan bisnis tertentu, sehingga Anda dapat mengetahui layanan yang paling tidak stabil atau paling sering mengalami perubahan bermasalah.
Sumber data
Biasanya ditautkan dari Configuration Management Database (CMDB) dan disimpan dalam kolom 'Primary CI' atau 'Service' pada objek Change Request.
Contoh
Layanan email (Exchange)Sistem ERP (SAP)Switch jaringan inti (CISCO-4500X)
|
|||
|
Pengaju perubahan
ChangeSubmitter
|
Pengguna yang pertama kali membuat atau mengajukan permintaan perubahan. | ||
|
Deskripsi
Atribut ini menunjukkan orang yang memulai permintaan perubahan. Orang ini mungkin berbeda dari Penanggung Jawab Perubahan, yang bertanggung jawab atas penerapannya pada tahap berikutnya. Analisis Pengaju Perubahan dapat membantu menemukan pola terkait kualitas permintaan. Misalnya, analisis dapat menunjukkan bahwa individu atau tim tertentu sering mengajukan permintaan yang tidak lengkap sehingga ditolak atau perlu dikerjakan ulang. Temuan ini dapat digunakan untuk memberikan pelatihan yang sesuai dan meningkatkan kualitas pengajuan secara keseluruhan.
Mengapa ini penting
Membantu menelusuri asal permintaan perubahan, menganalisis kualitas pengajuan berdasarkan individu atau tim, dan menemukan kebutuhan pelatihan.
Sumber data
Biasanya berupa kolom 'Created By' atau 'Requested By' pada objek Change Request.
Contoh
Susan MillerDavid ChenMaria Garcia
|
|||
|
Penyelesaian tepat waktu
IsOnTimeCompletion
|
Penanda hasil perhitungan yang bernilai benar jika perubahan selesai pada atau sebelum tanggal target. | ||
|
Deskripsi
Atribut boolean ini dihitung dengan membandingkan 'ActualCompletionDate' dan 'TargetCompletionDate'. Atribut ini memudahkan analisis dengan menunjukkan secara jelas apakah setiap permintaan perubahan selesai tepat waktu. Penanda ini menjadi dasar perhitungan KPI 'On-Time Change Completion Rate'. Anda dapat menggunakannya sebagai filter di dasbor untuk menyaring dan menganalisis perubahan yang terlambat, lalu menemukan penyebab umum keterlambatan.
Mengapa ini penting
Memudahkan analisis kinerja dengan menunjukkan secara jelas apakah tenggat waktu terpenuhi, sekaligus menjadi dasar KPI penyelesaian tepat waktu.
Sumber data
Atribut ini tidak tersedia di sistem sumber. Nilainya dihitung saat transformasi data dengan membandingkan 'ActualCompletionDate' <= 'TargetCompletionDate'.
Contoh
truefalse
|
|||
|
Prioritas perubahan
ChangePriority
|
Tingkat prioritas permintaan perubahan yang menunjukkan urgensi dan dampak bisnisnya. | ||
|
Deskripsi
Prioritas Perubahan ditentukan dengan menggabungkan urgensi dan dampak perubahan. Prioritas membantu tim menentukan urutan pekerjaan dan mengalokasikan sumber daya secara efektif, agar perubahan yang paling penting ditangani lebih dahulu. Dalam analisis, prioritas dapat digunakan untuk melihat apakah perubahan berprioritas tinggi diproses lebih cepat daripada perubahan berprioritas rendah. Jika tidak, hal ini dapat menunjukkan inefisiensi atau hambatan dalam proses penentuan prioritas maupun pelaksanaan.
Mengapa ini penting
Membantu menganalisis apakah proses memprioritaskan perubahan berdampak tinggi dengan tepat dan apakah perubahan tersebut benar-benar dipercepat sesuai rencana.
Sumber data
Biasanya berupa kolom bernama 'Priority' pada objek Change Request. Nilainya dapat diatur secara manual atau ditentukan dari kolom dampak dan urgensi.
Contoh
1 - Kritis2 - Tinggi3 - Sedang4 - Rendah
|
|||
|
Tanggal penyelesaian aktual
ActualCompletionDate
|
Waktu saat perubahan benar-benar diterapkan dan diverifikasi selesai. | ||
|
Deskripsi
Tanggal Penyelesaian Aktual menandai saat pekerjaan penerapan permintaan perubahan selesai. Tonggak ini dibandingkan dengan tenggat yang direncanakan untuk mengukur kinerja. Atribut ini digunakan bersama Tanggal Target Penyelesaian untuk mengetahui apakah perubahan selesai tepat waktu. Atribut ini menjadi masukan utama untuk menghitung KPI seperti 'Tingkat Penyelesaian Perubahan Tepat Waktu' dan menganalisis penyebab keterlambatan pada fase penerapan.
Mengapa ini penting
Mencatat waktu penyelesaian yang sebenarnya, yang diperlukan untuk menghitung tingkat penyelesaian tepat waktu dan menganalisis besarnya keterlambatan.
Sumber data
Tanggal ini sering dicatat saat status permintaan perubahan berubah menjadi 'Implemented' atau 'Completed'. Tanggal dapat disimpan dalam kolom khusus atau disimpulkan dari waktu perubahan status tersebut.
Contoh
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
Unit bisnis
BusinessUnit
|
Unit bisnis atau departemen yang meminta perubahan atau akan memperoleh manfaat darinya. | ||
|
Deskripsi
Atribut ini mengaitkan permintaan perubahan dengan bagian tertentu dalam organisasi, seperti 'Keuangan', 'Pemasaran', atau 'Operasional'. Dengan demikian, proses yang bersifat teknis memiliki konteks bisnis. Analisis berdasarkan Unit Bisnis menunjukkan asal kebutuhan perubahan. Analisis ini dapat membantu penerapan model pembebanan biaya, memahami dampak perubahan TI terhadap berbagai fungsi bisnis, dan mengetahui apakah perubahan di unit tertentu lebih rumit atau lebih sering terlambat.
Mengapa ini penting
Memberikan konteks bisnis untuk menganalisis kebutuhan, dampak, dan kinerja perubahan dari sudut pandang organisasi.
Sumber data
Informasi ini dapat disimpan dalam kolom pada objek Change Request atau diambil dari profil pengguna yang mengajukan permintaan.
Contoh
KeuanganSumber daya manusiaPenjualan dan pemasaranOperasional
|
|||
|
Waktu siklus penerapan perubahan
ImplementationCycleTime
|
Durasi yang dihitung sejak penerapan perubahan dimulai hingga selesai. | ||
|
Deskripsi
Metrik ini mengukur waktu yang dibutuhkan pada tahap penerapan perubahan. Perhitungannya menggunakan durasi antara aktivitas 'Change Implementation Started' dan 'Change Implemented'. Atribut ini digunakan untuk menghitung KPI 'Average Change Implementation Time' dan mendukung dasbor 'Change Implementation Flow & Delays'. Metrik ini membantu membedakan keterlambatan perencanaan dari keterlambatan pelaksanaan, sehingga tim dapat memusatkan upaya perbaikan pada pekerjaan teknis penerapan.
Mengapa ini penting
Mengukur kinerja tahap penerapan itu sendiri, sehingga hambatan teknis atau keterbatasan sumber daya dapat diketahui secara terpisah dari keterlambatan persetujuan.
Sumber data
Dihitung di alat process mining atau saat transformasi data dengan mencari selisih waktu antara stempel waktu peristiwa awal dan akhir penerapan.
Contoh
4 jam 15 menit1 hari 2 jam30 menit
|
|||
Aktivitas manajemen perubahan
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Dampak dan risiko dinilai
|
Aktivitas ini menandai selesainya analisis risiko dan dampak untuk permintaan perubahan. Biasanya, aktivitas disimpulkan saat status permintaan perubahan beralih ke status yang menunjukkan kesiapan untuk disetujui, seperti 'Menunggu Persetujuan'. | ||
|
Mengapa ini penting
Pelacakan aktivitas ini membantu mengukur durasi tahap penilaian dan memastikan analisis risiko dilakukan secara konsisten sebelum persetujuan, sebagai dukungan bagi KPI Tingkat Kepatuhan Penilaian Risiko.
Sumber data
Disimpulkan dari riwayat objek Change Request. Waktu aktivitas dicatat saat kolom 'Status' berubah dari 'Sedang Dinilai' menjadi status seperti 'Menunggu Persetujuan CAB'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Menunggu Persetujuan CAB'.
Jenis peristiwa
inferred
|
|||
|
Permintaan perubahan dibuat
|
Aktivitas ini menandai dimulainya permintaan perubahan baru di sistem. Biasanya, aktivitas tercatat saat rekaman baru dibuat pada objek bisnis Change Request, yang menjadi titik awal seluruh proses. | ||
|
Mengapa ini penting
Ini adalah peristiwa awal utama dalam proses. Dengan menganalisis waktu dari aktivitas ini ke aktivitas lainnya, Anda dapat mengetahui durasi seluruh siklus dan menemukan keterlambatan di tahap awal.
Sumber data
Peristiwa ini diambil dari stempel waktu pembuatan rekaman Change Request. Di Ivanti Cherwell, waktu ini biasanya tersimpan di kolom 'CreatedDateTime' pada objek bisnis Change Request.
Pengumpulan data
Diambil langsung dari stempel waktu pembuatan rekaman.
Jenis peristiwa
explicit
|
|||
|
Perubahan dijadwalkan
|
Aktivitas ini menandai saat tanggal dan waktu penerapan perubahan dikonfirmasi dan dicatat secara resmi. Aktivitas tercatat saat status diperbarui menjadi 'Dijadwalkan'. | ||
|
Mengapa ini penting
Ini adalah tonggak penting yang menandai komitmen. Tahap ini mengubah perubahan dari konsep yang disetujui menjadi tindakan yang direncanakan, sekaligus menjadi prasyarat penerapan.
Sumber data
Disimpulkan dari riwayat objek Change Request dengan mengambil waktu saat kolom 'Status' diperbarui menjadi 'Scheduled'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Scheduled'.
Jenis peristiwa
inferred
|
|||
|
Perubahan disetujui CAB
|
Tahap penting saat Change Advisory Board (CAB) atau pihak berwenang yang ditunjuk menyetujui perubahan untuk dilanjutkan. Aktivitas ini disimpulkan saat status permintaan perubahan diperbarui menjadi 'Disetujui'. | ||
|
Mengapa ini penting
Aktivitas ini menjadi titik akhir untuk mengukur waktu siklus persetujuan. Setelah persetujuan diberikan, proses dapat berlanjut ke perencanaan dan penerapan. Aktivitas ini penting untuk KPI Waktu Siklus Persetujuan Perubahan.
Sumber data
Disimpulkan dari riwayat audit objek Change Request, khususnya stempel waktu saat kolom 'Status' berubah menjadi 'Disetujui'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Disetujui'.
Jenis peristiwa
inferred
|
|||
|
Perubahan diterapkan
|
Tonggak ini menunjukkan bahwa pekerjaan teknis untuk perubahan telah selesai. Tahap ini dicatat saat status permintaan perubahan diperbarui menjadi 'Implemented' atau status serupa yang menunggu verifikasi. | ||
|
Mengapa ini penting
Ini adalah tonggak penting keberhasilan dan menjadi masukan utama untuk KPI Tingkat Penyelesaian Perubahan Tepat Waktu dan Rata-rata Waktu Penerapan Perubahan. Tahap ini menandai berakhirnya fase pelaksanaan.
Sumber data
Disimpulkan dari log audit objek Change Request, menggunakan waktu perubahan status menjadi 'Implemented' atau 'Pending Verification'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Implemented'.
Jenis peristiwa
inferred
|
|||
|
Perubahan ditutup
|
Aktivitas ini menandai akhir proses manajemen perubahan yang berhasil. Tahap ini dicatat saat status permintaan perubahan diatur menjadi 'Closed', yang menunjukkan semua pekerjaan telah selesai. | ||
|
Mengapa ini penting
Sebagai penanda utama keberhasilan, aktivitas ini penting untuk menghitung waktu siklus menyeluruh perubahan yang berhasil diselesaikan. Tahap ini memastikan semua langkah proses telah tuntas.
Sumber data
Disimpulkan dari waktu perubahan status terakhir menjadi 'Closed' dalam riwayat audit objek Change Request.
Pengumpulan data
Disimpulkan dari perubahan status terakhir menjadi 'Closed'.
Jenis peristiwa
inferred
|
|||
|
Tinjauan pascapenerapan dilakukan
|
Aktivitas ini menandakan bahwa perubahan yang telah selesai ditinjau secara resmi untuk menilai keberhasilannya dan mencatat pelajaran yang diperoleh. Tahap ini sering disimpulkan dari perubahan status menjadi 'Post Implementation Review'. | ||
|
Mengapa ini penting
Pelacakan tahap ini memastikan umpan balik atas perubahan ditindaklanjuti. Tahap ini penting untuk perbaikan berkelanjutan dan mendukung KPI Tingkat Tinjauan Pascapenerapan secara langsung.
Sumber data
Disimpulkan dari riwayat audit objek Change Request, dengan mencatat waktu saat 'Status' berubah ke status seperti 'Post Implementation Review'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Post Implementation Review'.
Jenis peristiwa
inferred
|
|||
|
Penerapan perubahan dimulai
|
Menandai dimulainya pelaksanaan teknis perubahan. Biasanya, tahap ini disimpulkan saat status permintaan perubahan berubah menjadi 'In Progress' atau 'Implementing'. | ||
|
Mengapa ini penting
Aktivitas ini menandai awal periode penerapan. Jarak waktu antara tahap ini dan 'Change Implemented' menunjukkan durasi penerapan yang sebenarnya, salah satu komponen penting dalam total waktu siklus.
Sumber data
Disimpulkan dari riwayat audit objek Change Request. Waktu yang dicatat adalah saat kolom 'Status' diperbarui ke nilai seperti 'In Progress' atau 'Implementing'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'In Progress'.
Jenis peristiwa
inferred
|
|||
|
Perubahan diajukan untuk penilaian
|
Menandai pengajuan resmi permintaan perubahan yang baru dibuat untuk evaluasi awal. Aktivitas ini biasanya disimpulkan saat status permintaan perubahan beralih dari 'Baru' atau 'Draf' ke status seperti 'Sedang Dinilai'. | ||
|
Mengapa ini penting
Aktivitas ini menandai dimulainya proses perubahan resmi setelah data awal dimasukkan. Waktu antara pembuatan dan pengajuan dapat menunjukkan perlunya pelatihan pengguna atau adanya hambatan dalam proses.
Sumber data
Disimpulkan dari log audit atau riwayat objek Change Request dengan mencari stempel waktu saat kolom 'Status' berubah menjadi nilai seperti 'Sedang Dinilai' atau 'Diajukan'.
Pengumpulan data
Disimpulkan dari perubahan status dari 'Baru' menjadi 'Sedang Dinilai'.
Jenis peristiwa
inferred
|
|||
|
Perubahan dibatalkan
|
Menandai status akhir ketika permintaan perubahan yang telah disetujui atau sedang berjalan ditarik sebelum selesai. Peristiwa ini dicatat saat status diperbarui menjadi 'Cancelled'. | ||
|
Mengapa ini penting
Ini adalah titik akhir alternatif dalam proses. Analisis alasan dan waktu pembatalan perubahan dapat mengungkap masalah dalam perencanaan, alokasi sumber daya, atau perubahan prioritas bisnis.
Sumber data
Disimpulkan dari riwayat audit dengan mencatat waktu saat kolom 'Status' pada objek Change Request diperbarui menjadi 'Cancelled'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Cancelled'.
Jenis peristiwa
inferred
|
|||
|
Perubahan ditolak
|
Aktivitas ini menandai keputusan akhir untuk menolak permintaan perubahan pada tahap persetujuan. Aktivitas tercatat saat status permintaan perubahan diatur menjadi 'Ditolak'. | ||
|
Mengapa ini penting
Ini adalah titik akhir yang menandai kegagalan proses. Analisis terhadap perubahan yang ditolak dan alasannya membantu meningkatkan kualitas permintaan sejak awal serta mendukung KPI Tingkat Penolakan Permintaan Perubahan.
Sumber data
Disimpulkan dari stempel waktu saat kolom 'Status' pada objek Change Request diperbarui menjadi 'Ditolak' dalam riwayat audit.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Ditolak'.
Jenis peristiwa
inferred
|
|||
|
Perubahan menunggu persetujuan
|
Aktivitas ini menunjukkan periode saat permintaan perubahan secara resmi menunggu keputusan dari Change Advisory Board (CAB) atau pihak berwenang lainnya. Aktivitas ini disimpulkan dari status seperti 'Menunggu Persetujuan' atau 'Menunggu CAB'. | ||
|
Mengapa ini penting
Aktivitas ini merupakan waktu tunggu yang penting. Dengan menganalisis durasinya, Anda dapat menemukan hambatan dalam alur kerja persetujuan, yang sering menjadi penyebab keterlambatan dalam Change Management.
Sumber data
Diambil dari stempel waktu saat kolom 'Status' pada objek bisnis Change Request diperbarui menjadi 'Menunggu Persetujuan' atau nilai yang setara.
Pengumpulan data
Diidentifikasi saat status berubah menjadi 'Menunggu Persetujuan'.
Jenis peristiwa
inferred
|
|||
|
Rencana penerapan disusun
|
Menandai selesainya perencanaan terperinci untuk perubahan, termasuk penentuan tugas, sumber daya, dan rencana pemulihan. Aktivitas ini sering disimpulkan saat status perubahan beralih dari 'Disetujui' menjadi 'Dijadwalkan'. | ||
|
Mengapa ini penting
Durasi aktivitas ini menunjukkan efisiensi tahap perencanaan perubahan. Keterlambatan pada tahap ini dapat memengaruhi jadwal perubahan secara keseluruhan, bahkan setelah persetujuan diberikan.
Sumber data
Aktivitas ini dapat disimpulkan dari stempel waktu perubahan status dari 'Disetujui' menjadi 'Dijadwalkan'. Alternatifnya, aktivitas dapat dikaitkan dengan pengisian kolom perencanaan tertentu.
Pengumpulan data
Disimpulkan dari perubahan status dari 'Disetujui' menjadi 'Dijadwalkan'.
Jenis peristiwa
inferred
|
|||
|
Verifikasi perubahan dilakukan
|
Menandai fase pengujian dan validasi untuk memastikan perubahan berhasil dan tidak menimbulkan dampak buruk. Tahap ini disimpulkan dari perubahan status menjadi 'Verification' atau 'Testing'. | ||
|
Mengapa ini penting
Analisis frekuensi dan durasi aktivitas ini membantu memastikan langkah penjaminan kualitas tidak terlewat. Tahap ini penting untuk mencegah insiden akibat perubahan.
Sumber data
Dicatat dari waktu perubahan status pada objek Change Request, misalnya saat status berubah menjadi 'Verification' atau 'User Acceptance Testing'.
Pengumpulan data
Disimpulkan dari perubahan status menjadi 'Verification'.
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Gunakan templat ini untuk memulai analisis proses manajemen perubahan dan menemukan peluang perbaikan yang berarti. Mulai tingkatkan efisiensi pembaruan Anda hari ini.
Capai keberhasilan perubahan 95%: optimalkan Ivanti Cherwell sekarang
Atasi hambatan, kurangi risiko, dan capai tingkat keberhasilan perubahan 95%.
Tidak perlu kartu kredit. Anda bisa langsung memulai.