Apakah Cara Menghadapi Situasi Bila Operasi Pembangunan Sistem Terhenti Kerana Keadaan Pengguna?

Tugas seperti pembangunan sistem biasanya melibatkan projek jangka panjang. Jadi, bagaimana jika, setelah memulakan pembangunan sistem, pihak pengguna secara sepihak berkata, “Sistem itu tidak lagi diperlukan, jadi anda tidak perlu membuatnya”? Apa yang dapat dilakukan oleh pihak vendor yang telah menerima tugas tersebut?

Artikel ini akan mengatur ciri-ciri khas kontrak pembangunan sistem dan menjelaskan langkah-langkah yang harus diambil dalam situasi tersebut.

Makna Memikirkan Mengenai Penyekatan Kerana Sebab Pengguna

Perjanjian pembangunan sistem mempunyai beberapa ciri yang unik apabila dilihat dari sudut perjanjian. Salah satunya adalah tempoh kerja yang biasanya berlangsung lama, dan sebagai tanggungjawab pengurusan projek, pihak vendor juga memikul tanggungjawab yang besar dengan budi bicara yang luas. Kandungan keseluruhan mengenai tanggungjawab pengurusan projek yang ditanggung oleh pihak vendor dijelaskan dengan lebih terperinci dalam artikel berikut.

https://monolith.law/corporate/project-management-duties[ja]

Selain itu, satu lagi ciri adalah pengguna, walaupun mereka adalah pelanggan, mempunyai tanggungjawab yang luas untuk bekerjasama dengan kerja vendor. Sistem yang digunakan di dalam syarikat sendiri tidak boleh diselesaikan hanya dengan ‘menyerahkan’ kepada pihak vendor. Dari dalam syarikat juga, ada tanggungjawab untuk bekerjasama sewajarnya agar vendor dapat menunjukkan kepakaran mereka dalam kerja. Ini dijelaskan dengan lebih terperinci dalam artikel berikut.

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

Jika kita ringkaskan kandungan di atas, antara vendor dan pengguna, selain hubungan timbal balik antara ‘pembekal luar’ yang membangunkan sistem dan ‘pelanggan’ yang membayar upah, pada masa yang sama, ada juga aspek seperti ‘rakan’ yang harus bekerjasama ke arah matlamat bersama iaitu pencapaian projek. Keadaan rumit ini biasanya tidak ada pada penjahit baju yang dibuat khusus, dan ini adalah ciri utama kontrak yang berkaitan dengan pembangunan sistem. Konflik yang berkaitan dengan pembangunan sistem disebabkan oleh keadaan rumit ini, dan jika ia menjadi rumit, ia cenderung menjadi rumit dan sukar untuk menyelesaikan hubungan antara kedua-dua pihak dari segi undang-undang.

Apabila pengguna berubah fikiran dan tiba-tiba berkata, “Sistem itu akhirnya tidak diperlukan, jadi projek tidak perlu diteruskan lagi”, memikirkan bagaimana hubungan hak dan tanggungjawab antara kedua-dua pihak harus difahami, dalam erti kata lain, memberikan contoh penggunaan pemikiran undang-undang di hadapan hubungan kontrak yang rumit ini. Di bawah ini, kami akan mengatur perkara yang perlu dipertimbangkan selepas itu dengan menganggap situasi seperti ini.

Pertama, susun semula sebab penamatan kontrak

Dari perspektif vendor, mungkin ada kes di mana “pengguna secara sepihak ingin menangguhkan projek”, tetapi persepsi ini mungkin tidak selalu dikongsi dengan pengguna. Sebagai contoh, anggaplah ada projek untuk membangunkan sistem pengurusan sumber manusia untuk pekerja yang ditempatkan di luar negara. Kemudian, rancangan untuk memperluaskan perniagaan ke luar negara ditarik balik, menjadikan pembangunan sistem tersebut tidak lagi diperlukan. Memang, jika hanya melihat penjelasan ini, ia boleh dianggap sebagai perubahan pendirian sepihak oleh pengguna.

Namun, bagaimana jika ada sejarah keputusan tersebut yang juga melibatkan vendor, seperti pelanggaran kewajipan pengurusan projek seperti kelewatan dalam setiap proses, dan kesukaran dalam kemajuan pembangunan itu sendiri juga menjadi salah satu sebab perubahan dasar syarikat?

Sebagaimana yang telah disebutkan sebelumnya, pembangunan sistem adalah sesuatu yang memerlukan vendor dan pengguna untuk memikul tanggungjawab yang besar dan bekerjasama dengan rapat. Oleh itu, walaupun pengguna yang memulakan penangguhan dan vendor menganggapnya sebagai penamatan kontrak atas kehendak sendiri, vendor harus menyedari bahawa mereka mungkin dituduh sebab-sebab yang boleh dipertanggungjawabkan oleh vendor, dan mungkin mendakwa bahawa ia adalah penamatan berdasarkan kegagalan untuk melaksanakan kewajipan atau penamatan persetujuan.

Perbezaan antara penamatan kontrak atas kehendak sendiri, penamatan berdasarkan kegagalan untuk melaksanakan kewajipan, atau penamatan persetujuan, cenderung untuk ditentukan secara individu berdasarkan keadaan kemajuan projek dan sejarah rundingan sebelum ini. Oleh itu, jika vendor meneruskan proses pasca-projek dengan persepsi bahawa ia adalah penamatan kontrak atas kehendak sendiri oleh pengguna, adalah penting untuk meninggalkan rekod yang jelas tentang hal ini dalam minit mesyuarat dan lain-lain, untuk mengelakkan pertikaian mengenai perkara ini di masa depan.

Memeriksa Peruntukan Undang-Undang untuk Tuntutan Bayaran dan Pampasan

Mengambil kira perkara di atas, jika pembatalan dilakukan atas sebab sendiri oleh pengguna, seterusnya kita perlu mempertimbangkan sama ada vendor boleh membuat tuntutan bayaran berdasarkan peratusan penyelesaian, atau membuat tuntutan pampasan.

Peruntukan undang-undang yang perlu dirujuk dalam kes ini berbeza-beza mengikut jenis kontrak. Kontrak pembangunan sistem secara kasarnya boleh dibezakan kepada kontrak perkhidmatan dan kontrak kuasa-kuasa tertentu.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Undang-Undang Sivil Jepun (Japanese Civil Code) menetapkan peruntukan berikut untuk kontrak kuasa-kuasa tertentu dan kontrak perkhidmatan:

a.) Dalam kes kontrak kuasa-kuasa tertentu
Tuntutan Bayaran: Undang-Undang Sivil 648(3) (Japanese Civil Code 648(3))
Jika kuasa-kuasa tertentu berakhir di tengah jalan kerana sebab yang tidak dapat dikaitkan dengan penerima kuasa, penerima kuasa boleh membuat tuntutan bayaran berdasarkan peratusan penyelesaian.
Tuntutan Pampasan: Undang-Undang Sivil 651 (Japanese Civil Code 651)
1. Kuasa-kuasa tertentu boleh dibatalkan oleh mana-mana pihak pada bila-bila masa.
2. Jika salah satu pihak membatalkan kuasa-kuasa tertentu pada masa yang tidak menguntungkan pihak lain, pihak tersebut perlu membayar pampasan kepada pihak lain. Namun, ini tidak berlaku jika ada sebab yang tidak dapat dielakkan.

b.) Dalam kes kontrak perkhidmatan
Tuntutan Pampasan: Undang-Undang Sivil 641 (Japanese Civil Code 641)
Selagi pekerjaan belum selesai, pelanggan boleh membayar pampasan dan membatalkan kontrak pada bila-bila masa.

Perlu diingat, lingkungan pampasan berdasarkan Undang-Undang Sivil 641 (Japanese Civil Code 641) tidak hanya melibatkan kos yang telah dibelanjakan, tetapi juga ‘keuntungan yang akan diperoleh jika kontrak tidak dibatalkan’. Ini kerana, menurut undang-undang, memaksa penyelesaian kerja yang tidak lagi diperlukan oleh pelanggan adalah sia-sia. Oleh itu, dalam kes seperti ini, lebih rasional untuk menjamin keuntungan pihak yang menerima pesanan dengan membayar jumlah yang sama.

Walau bagaimanapun, dalam banyak kes, pampasan berdasarkan Undang-Undang Sivil 641 (Japanese Civil Code 641) mungkin tidak termasuk dalam kontrak individu antara vendor dan pengguna. Dalam kes seperti ini, perjanjian individu antara pihak-pihak (kontrak) akan mengatasi peruntukan undang-undang ini, dan peruntukan undang-undang ini mungkin tidak berlaku. Oleh itu, berhati-hatilah dalam hal ini.

Memajukan Bukti Volume dan Kerugian

Dalam kes pembatalan atas inisiatif pengguna, apa yang biasanya dilihat dalam kontrak adalah klaim untuk bayaran komisen volume (iaitu bahagian yang telah selesai) dan klaim untuk ganti rugi. Oleh itu, biasanya, pihak vendor perlu membuktikan volume dan kerugian untuk membuat tuntutan ganti rugi.

Walau bagaimanapun, pembuktian volume ini, atau kadar penyelesaian, boleh menjadi tugas yang sangat mencabar jika dilakukan. Ini kerana, terutama jika terdapat beberapa subkontraktor, jumlah wawancara yang diperlukan untuk memeriksa kemajuan, jika dilakukan, boleh menjadi sangat besar. Selain itu, jika anda perlu membuat semua dokumen untuk menyokong hasil wawancara dan mendokumentasikan isi wawancara itu sendiri, kerja yang diperlukan akan menjadi sangat banyak. Jika ada risiko bahawa bukti masih tidak mencukupi walaupun anda telah melakukan semua ini, usaha yang anda lakukan untuk mempersiapkan bukti mungkin menjadi sia-sia, dan ada banyak masalah lainnya.

Mengambil kira perkara-perkara ini, langkah-langkah yang boleh diambil termasuk membuat perjanjian awal pada tahap kontrak bahawa jika kontrak dibatalkan di tengah jalan, ia akan dikira secara pro-rata berdasarkan jumlah hari sehingga pembatalan, dan membuat perhitungan semudah mungkin. Selain itu, mengingat bahawa klaim terhadap volume memerlukan banyak usaha untuk membuktikan, anda mungkin juga ingin mempertimbangkan pendekatan seperti menyerah pada klaim terhadap volume itu sendiri dan membuat klaim terhadap “kos yang diperlukan untuk pembangunan bahagian yang telah selesai”. Jika ini adalah kos pembangunan dalaman, seringkali mudah untuk mengira dengan formula sederhana “jumlah jam x kadar”. Terutama untuk projek dengan margin keuntungan yang rendah, dengan memberi keutamaan kepada klaim berdasarkan kos bukan volume, anda boleh mengharapkan untuk menggantikan kerugian sambil mempertimbangkan kemudahan pengumpulan hutang, yang seringkali menjadi langkah pemulihan yang lebih realistik.

Apakah yang perlu dipertimbangkan dari pihak pengguna?

Sekadar makluman, terdapat beberapa perkara yang perlu dipertimbangkan oleh pengguna yang ingin membatalkan kontrak atas sebab peribadi. Antara perkara tersebut adalah untuk memastikan jumlah kira-kira pampasan yang perlu dibayar kepada vendor. Tujuan ‘kira-kira’ ini adalah untuk memberikan panduan kasar yang dapat membantu dalam proses rundingan seterusnya (walaupun jumlah yang tepat tidak diperlukan, lambat menunjukkan niat untuk membatalkan akan menjadi sia-sia).

Jika jumlah kira-kira yang telah disahkan dianggap tidak wajar, anda harus meminta penjelasan. Namun, jika anda cuba untuk merunding secara tidak wajar untuk mengurangkan jumlah pembayaran, ini boleh membawa kepada tindakan undang-undang yang tidak perlu dan situasi boleh menjadi lebih rumit. Jika rundingan antara dua pihak sukar, mungkin perlu untuk berunding dengan peguam.

Selain itu, dalam artikel ini, kami telah menjelaskan dengan anggapan bahawa kontrak berkaitan dengan pembangunan sistem telah ditubuhkan. Namun, dalam realiti pembangunan sistem, terdapat banyak kes di mana pertikaian berlaku mengenai sama ada kontrak telah ditubuhkan dengan sah. Kami telah menjelaskan secara terperinci mengenai perkara ini dalam artikel di bawah.

https://monolith.law/corporate/system-development-contract[ja]

Rumusan

Dalam artikel ini, kami telah menjelaskan aliran cara menghadapi situasi di mana projek dihentikan kerana sebab-sebab yang berkaitan dengan pengguna. Walau bagaimanapun, titik utama dalam artikel ini adalah, “sama ada benar-benar boleh dikatakan bahawa ini adalah atas sebab-sebab pengguna sendiri” dan “sama ada benar-benar tidak ada kesalahan di pihak vendor”, perlu dipertimbangkan dari sudut ini.

Ciri-ciri projek pembangunan sistem adalah bahawa kedua-dua vendor dan pengguna memikul tanggungjawab yang besar. Oleh itu, jika anda tidak mempertimbangkan dengan baik sama ada benar-benar mungkin untuk menyalahkan pihak lain secara sepihak sebelumnya, anda harus menyedari bahawa ini boleh menjadi situasi yang menambahkan minyak ke dalam api.