Apa itu Cara Pengurusan Perubahan dalam Pembangunan Sistem dari Perspektif Undang-Undang?

Dalam projek pembangunan sistem, sering kali berlaku situasi di mana pengguna mengubah kandungan yang telah diterangkan sebelumnya seiring dengan kemajuan kerja. Oleh itu, sebagai vendor yang menerima kerja, terdapat keperluan untuk mematuhi perubahan dalam kontrak yang telah ditandatangani sebelum ini.

Artikel ini menjelaskan bagaimana untuk menangani fenomena ‘perubahan’ yang berlaku selepas itu dari perspektif undang-undang terhadap projek pembangunan sistem yang sukar untuk berjalan seperti yang dijangka.

Mengapa Projek Pembangunan Sistem Sering ‘Diubah’ Selepasnya?

Pembangunan Sistem adalah Kerjasama antara Vendor dan Pengguna

Pembangunan sistem biasanya melalui peringkat perancangan dan cadangan, di mana keperluan pembangunan didefinisikan dan kontrak ditandatangani. Selepas kontrak ditandatangani, proses melibatkan pelbagai reka bentuk dan pelaksanaan mengikut reka bentuk, diikuti oleh ujian sebelum berakhir. Sepanjang proses ini, vendor yang menerima tugas memikul tanggungjawab yang luas sebagai pakar pembangunan sistem, tetapi pengguna juga mempunyai tanggungjawab kerjasama tertentu. Kerjasama pengguna sangat penting dalam proses seperti penentuan fungsi sistem yang perlu dibuat (=definisi keperluan), penampilan dan rasa operasi dari sisi skrin (=reka bentuk asas), dan pengesahan sama ada keperluan telah dipenuhi (=ujian atau penerimaan). Untuk penjelasan umum tentang tanggungjawab yang ditanggung oleh pengguna dalam pembangunan sistem, sila rujuk artikel berikut.

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

Walaupun Ada Tanggungjawab Kerjasama, Pengguna Sering Minta Perubahan

Namun, pengguna yang bukan pakar dalam pembangunan sistem tidak selalu dapat menyampaikan informasi yang diperlukan untuk pembangunan sistem kepada vendor secara lengkap dan menyeluruh. Dalam kenyataannya, kerana kerja ini adalah detail dan teliti, seringkali pengguna tidak dapat meramalkan fakta apa yang mungkin mempunyai makna penting dalam proses selanjutnya. Oleh itu, ironisnya, fakta yang paling penting sering kali muncul secara beransur-ansur. Dalam konteks ini, dalam projek sebenar, walaupun “penyampaian sekaligus dari proses hulu ke proses hilir” adalah ideal, perubahan yang berbagai-bagai sering dilakukan selepasnya dengan asumsi ini, dan bagaimana “pengurusan perubahan” dilakukan menjadi penting.

Apa itu Dokumen Pengurusan Perubahan

Keadaan di mana Dokumen Pengurusan Perubahan digunakan

Dokumen Pengurusan Perubahan adalah dokumen yang digunakan oleh pengguna untuk meminta perubahan spesifikasi atau penambahan fungsi kepada vendor berdasarkan kandungan penjelasan yang telah diberikan sebelumnya. Seperti yang telah disebutkan sebelumnya, dalam fasa seperti definisi keperluan dan reka bentuk asas, pengguna juga mempunyai tanggungjawab untuk bekerjasama dengan kerja vendor, tetapi permintaan yang berbeza boleh timbul dalam proses yang berikutnya.

Contoh situasi di mana Dokumen Pengurusan Perubahan diperlukan termasuk:

• Apabila terdapat kekurangan dalam perbincangan semasa definisi keperluan atau reka bentuk asas, dan permintaan penambahan fungsi dibuat selepas itu
• Apabila perubahan dalam polisi perniagaan dan sebagainya diperlukan semasa pembangunan

Ini adalah beberapa contoh yang boleh dipertimbangkan.

Sehubungan dengan topik seperti penambahan fungsi dan perubahan spesifikasi, apa yang paling menarik bagi pihak yang menerima kerja adalah sama ada perubahan dalam jumlah anggaran diiktiraf secara undang-undang. Kami telah menjelaskan secara terperinci mengenai perkara ini dalam artikel lain.

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

Dokumen Pengurusan Perubahan menjadi asas untuk menilai kewajaran anggaran kandungan semasa melakukan peningkatan anggaran selepas itu. Apabila membuat tuntutan berdasarkan anggaran yang telah dinaikkan kemudian, penting untuk membuat Dokumen Pengurusan Perubahan untuk mengelakkan perselisihan dengan pihak lain (dan juga untuk memberikan kekuatan persuasif kepada hujah anda jika terjadi perselisihan).

Perkara yang perlu dicatat dalam Dokumen Pengurusan Perubahan

Jadi, apa yang perlu dicatat dalam Dokumen Pengurusan Perubahan dari segi undang-undang? Mekanisme kontrak yang menggunakan Dokumen Pengurusan Perubahan untuk mematuhi perubahan spesifikasi dan penambahan fungsi sudah dikenali secara umum. Oleh itu, dengan memeriksa templat klausa kontrak yang ditunjukkan oleh agensi kerajaan seperti Model Kontrak Kementerian Ekonomi, Perdagangan dan Industri, anda boleh memahami secara kasar apa yang perlu dicatat sebagai rekod.

(Prosedur Pengurusan Perubahan)
Perkara 37 Jika A atau B menerima cadangan perubahan berdasarkan Perkara 34 (Perubahan pada Dokumen Spesifikasi Sistem, dll.), Perkara 35 (Persetujuan Pengguna terhadap Bahan Pertengahan), Perkara 36 (Pengendalian Isu yang Belum Ditentukan), mereka harus memberikan dokumen (selanjutnya disebut “Dokumen Pengurusan Perubahan“) yang mencatat perkara-perkara berikut kepada pihak lain dalam tempoh ○ hari dari tarikh penerimaan tersebut, dan A dan B harus berunding mengenai sama ada perubahan tersebut boleh dilakukan di Majlis Perhubungan yang ditentukan dalam Perkara 12.
① Nama perubahan
② Ketua yang bertanggungjawab atas cadangan
③ Tarikh
④ Sebab perubahan
⑤ Butiran terperinci perubahan termasuk spesifikasi yang berkaitan dengan perubahan
⑥ Jika perubahan memerlukan kos, jumlahnya
⑦ Jadual kerja perubahan termasuk tempoh pertimbangan
⑧ Kesan lain yang diberikan oleh perubahan kepada syarat-syarat kontrak ini dan kontrak individu (tempoh kerja atau tarikh penyerahan, yuran komisen, klausa kontrak, dll.)

Dengan membaca teks undang-undang secara langsung dan mengesahkan item yang disyorkan untuk dicatat, tidak ada penjelasan lebih lanjut yang diperlukan. Untuk mengelakkan masalah “saya katakan / saya tidak katakan” kemudian, anda harus mencatat sejarah perubahan secara terperinci dan konkrit.

Dengan mencatat perkara-perkara ini dengan jelas, dan dengan menetapkan tandatangan atau cap pengurus dan pengambil keputusan vendor dan pengguna, jika ada perbicaraan, ia akan mempunyai makna yang sama dengan kontrak sebagai bukti.

Perkara yang Baik untuk Diketahui Mengenai Pengurusan Perubahan

Pengurusan Perubahan Biasanya Dilakukan Bersama dengan Pengurusan Isu

Alasan untuk membuat dokumen pengurusan perubahan adalah untuk mengurus sejarah perubahan, yang dapat membantu mencapai projek (atau, jika tidak dapat dicapai, untuk mengelakkan tanggungjawab yang tidak adil). Dalam praktiknya, pembuatan dokumen pengurusan perubahan sering dilakukan bersama dengan pembuatan dan pengemaskinian senarai pengurusan isu. Dengan kata lain, setelah sejarah perubahan dikelola dalam jadual pengurusan perubahan, item perubahan yang telah disepakati akan dimasukkan ke dalam item senarai pengurusan isu sebagai isu yang perlu ditangani di masa depan.

Lebih Baik Juga Menetapkan Cara Melakukan Perbincangan Perubahan

Tidak hanya cara pengurusan perubahan, tetapi juga cara melakukan perbincangan tentang perubahan, jika anda menetapkan peraturan untuk itu, anda dapat mengharapkan penanganan perubahan berjalan lancar. Ini adalah titik yang sangat penting, terutama jika anda menggunakan metode pengembangan seperti pengembangan agile, di mana berbagai perubahan dibuat setelahnya. Dalam praktiknya, ada banyak contoh di mana peraturan ditetapkan, seperti berapa lama pihak lain harus merespon perbincangan jika ada permintaan untuk perbincangan tentang pengurusan perubahan.

Perbincangan Perubahan dan Kewajiban Kejujuran

Jika kedua pihak setuju untuk mengubah kontrak yang telah disepakati, ini juga berarti membuat kontrak baru. Dari sudut pandang bahwa kontrak didasarkan pada kehendak bebas individu, secara prinsip, vendor tidak memiliki kewajiban untuk menyetujui kontrak perubahan. Namun, jika hak ini ditekankan terlalu banyak, mungkin ada kekhawatiran bahwa projek pengembangan sistem tidak akan berjalan lancar dalam praktiknya.

Oleh itu, dalam praktiknya, sering kali ditulis dalam kontrak bahwa “ada kewajiban untuk merespon perbincangan perubahan dengan jujur”, dan ada juga contoh di mana jika vendor tidak merespon perubahan dengan jujur, klaim ganti rugi mungkin dimungkinkan.

Sebagai contoh penulisan, contohnya adalah seperti berikut (dikutip dari “Rancangan Kontrak Dasar/Individu ff” yang dibuat oleh Organisasi Promosi Pengolahan Informasi, sebuah badan hukum administratif independen).

Perenggan 3 Artikel 4 Dalam perbincangan perubahan, kedua pihak akan membincangkan dengan jujur tentang objek perubahan, kemungkinan perubahan, pengaruh perubahan terhadap harga dan tarikh penghantaran, dan lain-lain.

Peraturan Mengenai Cara Mengubah

Seperti yang disebutkan sebelumnya, ketika melakukan perubahan, secara hukum, lebih “selamat” untuk mengadakan perbincangan tentang perubahan setiap kali. Namun, dalam projek berskala kecil, mungkin ada kasus di mana anda tidak perlu menetapkan cara melakukan perbincangan tentang perubahan. Dalam hal ini, bukannya menetapkan peraturan untuk perbincangan, anda mungkin mempertimbangkan cara di mana perubahan pertama kali dibuat dengan menandatangani dan mengecap dokumen pengurusan perubahan oleh pengurus bertanggungjawab pengguna dan vendor, tanpa perbincangan. Jika anda membiarkan perubahan dilakukan dengan mudah hanya dengan persetujuan lisan, apakah perubahan telah dibuat atau tidak akan menjadi samar-samar, dan ini mungkin menjadi masalah besar di kemudian hari, jadi pengurusan dokumen harus dilakukan dengan teliti.

Namun, mungkin juga ada kasus di mana bahkan persiapan dokumen tambahan untuk pengurusan perubahan setiap kali adalah beban yang berat, dan anda ingin memberi penekanan lebih pada penanganan yang fleksibel. Dalam kasus seperti itu, mungkin satu opsi adalah untuk mendokumentasikan isu-isu yang berkaitan dengan perubahan dalam minit mesyuarat pengembangan sistem. Cara meninggalkan minit mesyuarat dalam pengembangan sistem dijelaskan secara terperinci dalam artikel berikut.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Rumusan

Di tempat kerja di mana perubahan spesifikasi sering berlaku, memang ada risiko masalah dan perselisihan yang mungkin timbul. Walau bagaimanapun, di tempat kerja di mana fleksibiliti diperlukan, walaupun menekankan pentingnya ‘pengurusan’ secara kaku, seringkali sukar untuk mengambil tindakan yang realistik.

Soalan tentang bagaimana untuk mencapai keseimbangan antara kecepatan yang diperlukan dalam perniagaan dan persiapan untuk situasi terburuk, seringkali jawapan yang paling sesuai berbeza-beza bergantung kepada situasi syarikat dan kandungan projek. Walaupun mempertimbangkan kandungan seperti dalam artikel ini, sikap mencari cara yang sesuai untuk setiap syarikat dan projek juga penting.