Apa itu Manajemen Perubahan dalam Pengembangan Sistem dari Perspektif Hukum?

Dalam proyek pengembangan sistem, sering kali terjadi bahwa konten yang telah dijelaskan oleh pengguna sebelumnya berubah seiring berjalannya pekerjaan. Oleh karena itu, bahkan sebagai vendor yang menerima pekerjaan, mungkin perlu untuk menyesuaikan dengan perubahan dalam isi kontrak yang telah disepakati sebelumnya.

Artikel ini menjelaskan bagaimana harus menangani fenomena ‘perubahan’ yang terjadi setelahnya dari perspektif hukum terhadap proyek pengembangan sistem yang sulit berjalan sesuai rencana.

Mengapa Proyek Pengembangan Sistem Sering ‘Diubah’ Setelahnya?

Pengembangan Sistem adalah Kerja Sama antara Vendor dan Pengguna

Pengembangan sistem umumnya melalui tahap perencanaan dan proposal, di mana persyaratan pengembangan didefinisikan dan kontrak ditandatangani. Setelah kontrak ditandatangani, proses biasanya melibatkan berbagai tahap desain, implementasi sesuai desain, dan akhirnya pengujian sebelum selesai. Seluruh proses ini, tentu saja, memerlukan vendor yang menerima pekerjaan untuk memikul tanggung jawab yang luas sebagai ahli pengembangan sistem, tetapi juga memerlukan kerjasama dari pengguna. Dalam tahap seperti definisi persyaratan (yaitu, mengidentifikasi fungsi yang harus dimiliki oleh sistem), desain dasar (yaitu, tampilan dan nuansa antarmuka pengguna), dan konfirmasi apakah hasilnya sesuai dengan persyaratan (yaitu, pengujian atau penerimaan), kerjasama dari pengguna sangat penting. Untuk penjelasan umum tentang kewajiban yang harus dipenuhi pengguna dalam pengembangan sistem, silakan lihat artikel berikut.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Meskipun Ada Kewajiban untuk Bekerja Sama, Pengguna Sering Minta Perubahan

Namun, pengguna yang bukan ahli pengembangan sistem tidak selalu dapat menyampaikan informasi yang diperlukan untuk pengembangan sistem kepada vendor secara lengkap dan komprehensif. Karena pekerjaan ini sangat detail dan rumit, seringkali pengguna tidak dapat memprediksi fakta apa yang mungkin memiliki arti penting dalam tahap selanjutnya. Ironisnya, semakin penting fakta tersebut, semakin mungkin mereka akan muncul secara bertahap. Oleh karena itu, dalam proyek nyata, meskipun idealnya adalah “melalui semua tahap dari hulu ke hilir”, asumsi bahwa berbagai perubahan dapat dilakukan setelahnya membuat “manajemen perubahan” menjadi penting.

Apa itu Dokumen Manajemen Perubahan

Kapan Dokumen Manajemen Perubahan Digunakan

Dokumen Manajemen Perubahan adalah dokumen yang digunakan oleh pengguna untuk meminta perubahan spesifikasi atau penambahan fungsi kepada vendor dari apa yang telah dijelaskan sebelumnya. Seperti yang telah disebutkan sebelumnya, dalam fase seperti definisi persyaratan dan desain dasar, pengguna juga memiliki kewajiban untuk bekerja sama dengan pekerjaan vendor, tetapi permintaan yang berbeda dapat muncul dalam proses selanjutnya.

Contoh situasi di mana Dokumen Manajemen Perubahan diperlukan, misalnya,

• Ketika ada kebocoran dalam diskusi tentang definisi persyaratan dan desain dasar, dan permintaan penambahan fungsi dibuat setelahnya
• Ketika ada revisi kebijakan bisnis, dll. selama pengembangan, dan perubahan spesifikasi diperlukan

dan sebagainya.

Sehubungan dengan topik seperti penambahan fungsi dan perubahan spesifikasi, apa yang paling menarik bagi pihak yang menerima pekerjaan adalah apakah perubahan dalam jumlah perkiraan diizinkan secara hukum. Kami menjelaskan secara detail tentang hal ini dalam artikel lain.

https://monolith.law/corporate/increase-of-estimate[ja]

Dokumen Manajemen Perubahan menjadi dasar untuk menilai keadilan perkiraan konten ketika meningkatkan perkiraan setelahnya. Saat membuat tagihan berdasarkan perkiraan yang ditingkatkan nanti, penting untuk membuat Dokumen Manajemen Perubahan agar tidak menimbulkan perselisihan dengan pihak lain (dan juga untuk memberikan kekuatan persuasif pada argumen Anda jika terjadi perselisihan).

Isi Dokumen Manajemen Perubahan

Lalu, apa saja item yang harus dicantumkan dalam Dokumen Manajemen Perubahan menurut hukum? Mekanisme kontrak yang menggunakan Dokumen Manajemen Perubahan untuk menanggapi perubahan spesifikasi dan penambahan fungsi sudah dikenal secara umum. Oleh karena itu, dengan memeriksa model klausul kontrak yang ditunjukkan oleh lembaga pemerintah seperti Kementerian Ekonomi, Perdagangan dan Industri, Anda dapat memahami apa yang harus dicatat sebagai catatan.

(Prosedur Manajemen Perubahan)
Pasal 37 Jika A atau B menerima proposal perubahan berdasarkan Pasal 34 (Perubahan Spesifikasi Sistem, dll.), Pasal 35 (Persetujuan Pengguna atas Dokumen Antara), Pasal 36 (Penanganan Isu yang Belum Ditentukan), dalam waktu ○ hari sejak tanggal penerimaan tersebut, mereka harus memberikan dokumen tertulis yang mencantumkan item berikut (selanjutnya disebut “Dokumen Manajemen Perubahan.”) kepada pihak lain, dan A dan B harus mendiskusikan apakah perubahan tersebut dapat diterima di Dewan Komunikasi yang ditentukan dalam Pasal 12.
① Nama Perubahan
② Penanggung Jawab Proposal
③ Tanggal
④ Alasan Perubahan
⑤ Detail Perubahan termasuk Spesifikasi yang Terkait dengan Perubahan
⑥ Jika Perubahan Memerlukan Biaya, Jumlahnya
⑦ Jadwal Pekerjaan Perubahan termasuk Periode Pertimbangan
⑧ Dampak Lain dari Perubahan pada Syarat Kontrak dan Kontrak Individu (Periode Pekerjaan atau Tanggal Pengiriman, Biaya, Klausul Kontrak, dll.)

Jika Anda membaca teks langsung dan memeriksa item yang disarankan untuk dicantumkan, tidak perlu penjelasan lebih lanjut. Untuk menghindari masalah “saya mengatakan / saya tidak mengatakan” nanti, Anda harus mencatat detail dan rincian perubahan.

Dengan mencantumkan item-item ini secara jelas, dan dengan menambahkan tanda tangan atau cap dari manajer / pembuat keputusan vendor dan pengguna, jika terjadi perselisihan yang berujung pada pengadilan, ini akan memiliki arti yang sama dengan kontrak sebagai bukti.

Hal yang Baik untuk Diketahui Mengenai Manajemen Perubahan

Manajemen Perubahan Biasanya Dilakukan Bersamaan dengan Manajemen Isu

Alasan membuat dokumen manajemen perubahan adalah untuk mengelola riwayat perubahan, yang dapat membantu dalam mencapai proyek atau menghindari pengejaran tanggung jawab yang tidak adil jika proyek tidak berhasil. Dalam prakteknya, pembuatan dokumen manajemen perubahan sering dilakukan bersamaan dengan pembuatan dan pembaruan daftar manajemen isu. Artinya, setelah mengelola riwayat perubahan dalam tabel manajemen perubahan, item perubahan yang telah disepakati akan diintegrasikan ke dalam daftar manajemen isu sebagai isu yang harus ditangani di masa depan.

Lebih Baik Juga Menetapkan Cara Melakukan Diskusi Perubahan

Tidak hanya cara melakukan manajemen perubahan, tetapi juga cara melakukan diskusi tentang perubahan harus ditetapkan untuk memastikan penanganan perubahan berjalan lancar. Hal ini sangat penting, terutama dalam pengembangan agile, di mana berbagai perubahan diharapkan terjadi setelahnya. Dalam prakteknya, seringkali ada aturan yang menentukan kapan pihak lain harus merespons permintaan diskusi tentang manajemen perubahan.

Diskusi Perubahan dan Kewajiban Kejujuran

Ketika kedua pihak setuju untuk mengubah kontrak yang telah disepakati, ini sebenarnya sama dengan membuat kontrak baru. Dari perspektif bahwa kontrak didasarkan pada kehendak bebas individu, secara prinsip, vendor tidak memiliki kewajiban untuk menyetujui perubahan kontrak. Namun, jika hak ini terlalu ditekankan, mungkin ada kekhawatiran bahwa proyek pengembangan sistem tidak akan berjalan lancar.

Oleh karena itu, dalam prakteknya, seringkali ada klausul dalam kontrak yang menyatakan “kewajiban untuk merespons dengan jujur terhadap diskusi perubahan”. Jika vendor tidak merespons dengan jujur terhadap perubahan, ada kemungkinan klaim ganti rugi, dan ada juga contoh yang ditulis seperti itu.

Sebagai contoh penulisan, misalnya, ada contoh klausul berikut (dikutip dari “Rancangan Kontrak Dasar/Individu ff” yang dibuat oleh Organisasi Promosi Pengolahan Informasi, sebuah badan administrasi independen).

Pasal 4 Ayat 3 Dalam diskusi perubahan, kedua pihak harus membahas dengan jujur tentang objek perubahan, apakah perubahan dapat dilakukan, pengaruh perubahan terhadap harga dan tenggat waktu, dan apakah perubahan harus dilakukan.

Ketentuan tentang Cara Melakukan Perubahan

Seperti yang telah disebutkan sebelumnya, secara hukum, lebih “aman” untuk mengadakan diskusi tentang perubahan setiap kali perubahan akan dilakukan. Namun, dalam proyek berskala kecil, mungkin tidak perlu menentukan cara melakukan diskusi tentang perubahan. Dalam hal ini, bukan menetapkan aturan tentang diskusi, tetapi dengan menandatangani dan memberi cap dokumen manajemen perubahan oleh pemimpin dari pengguna dan vendor, perubahan baru dapat dilakukan. Jika perubahan dapat dilakukan hanya dengan persetujuan lisan, apakah perubahan telah dilakukan atau tidak akan menjadi ambigu, dan ini dapat menyebabkan masalah besar di kemudian hari. Dalam hal ini, manajemen dokumen harus dilakukan secara menyeluruh.

Namun, mungkin ada kasus di mana bahkan persiapan dokumen terpisah untuk manajemen perubahan setiap kali menjadi beban, dan Anda ingin memberikan prioritas pada respons yang fleksibel. Dalam kasus seperti itu, mungkin baik untuk mendokumentasikan isu-isu terkait perubahan dalam catatan rapat. Tentang cara meninggalkan catatan rapat dalam pengembangan sistem, kami menjelaskannya secara detail dalam artikel berikut.

Kesimpulan

Memang, di tempat kerja di mana perubahan spesifikasi sering dilakukan, risiko masalah dan perselisihan cenderung menjadi hal yang biasa. Namun, di tempat kerja yang membutuhkan fleksibilitas seperti ini, meskipun kita menekankan pentingnya “manajemen”, seringkali sulit untuk mengambil tindakan praktis.

Pertanyaan tentang bagaimana mencapai keseimbangan antara kecepatan yang dibutuhkan dalam bisnis dan persiapan untuk situasi terburuk, seringkali solusi optimal berbeda tergantung pada situasi perusahaan dan konten proyek. Meskipun mempertimbangkan konten artikel ini, penting juga untuk mencari cara yang tepat untuk setiap perusahaan dan proyek.