Apa Solusi Jika Pengembangan Sistem Terhenti Karena Alasan Pengguna?

Pekerjaan pengembangan sistem biasanya sering kali berbentuk proyek jangka panjang. Jika dalam proses tersebut, pengguna secara sepihak menyatakan “sistem tersebut tidak lagi diperlukan, jadi tidak perlu dibuat”, apa yang bisa dilakukan oleh pihak vendor yang telah menerima pekerjaan tersebut?

Artikel ini akan menjelaskan karakteristik khusus dari kontrak pengembangan sistem dan strategi penanganan dalam kasus tersebut.

Makna Memikirkan tentang Penghentian karena Alasan Pengguna

Ada beberapa karakteristik yang patut disebut dalam kontrak pengembangan sistem. Salah satunya adalah periode kerja yang biasanya berlangsung lama, dan sebagai bagian dari kewajiban manajemen proyek, pihak vendor juga memiliki kewajiban besar bersama dengan diskresi yang besar. Konten keseluruhan tentang kewajiban manajemen proyek yang ditanggung oleh pihak vendor dijelaskan secara detail dalam artikel berikut.

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

Selain itu, satu lagi adalah bahwa pengguna, meskipun mereka adalah pelanggan, memiliki kewajiban untuk bekerja sama secara luas dengan pekerjaan vendor. Karena ini adalah sistem yang digunakan di dalam perusahaan, hal tersebut tidak bisa diselesaikan hanya dengan ‘menyerahkan’ kepada pihak vendor. Dari dalam perusahaan juga, ada kewajiban untuk bekerja sama sesuai kebutuhan, sehingga vendor dapat menunjukkan keahliannya dan bekerja. Hal ini dijelaskan secara detail dalam artikel berikut.

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

Jika kita merangkum konten di atas secara singkat, antara vendor dan pengguna, selain hubungan timbal balik antara ‘pemberi kerja luar’ yang mengembangkan sistem dan ‘pelanggan’ yang membayar kompensasi, ada juga aspek seperti ‘rekan’ yang harus bekerja sama menuju tujuan bersama yaitu pencapaian proyek. Kompleksitas hubungan ini biasanya tidak ada pada penjahit pakaian jadi, dan ini adalah ciri khas besar dari kontrak yang berkaitan dengan pengembangan sistem. Konflik yang berkaitan dengan pengembangan sistem karena kompleksitas hubungan ini, jika sekali terjerat, bagaimana harus mengatur hubungan antara kedua belah pihak secara hukum menjadi rumit dan cenderung memburuk.

Memikirkan masalah bagaimana memahami hubungan hak dan kewajiban antara kedua belah pihak jika pengguna berubah pikiran dan tiba-tiba mengatakan, “Sistem itu akhirnya tidak diperlukan, jadi tidak perlu melanjutkan proyek lagi,” memiliki makna dalam menunjukkan contoh nyata dari berpikir hukum di hadapan hubungan kontrak yang rumit ini. Di bawah ini, kami akan mengatur hal-hal yang harus dipertimbangkan setelahnya dengan mengasumsikan kasus seperti itu.

Pertama, Susun Alasan Mengapa Anda Mengajukan Pembatalan

Dari sudut pandang vendor, mungkin ada kasus di mana “pengguna secara sepihak ingin menghentikan proyek,” tetapi pemahaman ini tidak selalu dapat dibagi antara pengguna dan vendor. Sebagai contoh, mari kita anggap kasus di mana proyek untuk mengembangkan sistem yang mengelola personil yang bekerja di kantor cabang luar negeri telah dimulai, tetapi kemudian rencana ekspansi ke luar negeri itu sendiri ditarik, membuat pengembangan sistem tersebut menjadi tidak perlu. Memang, jika Anda hanya melihat penjelasan ini, Anda mungkin berpikir bahwa ini adalah perubahan pikiran sepihak dari pihak pengguna.

Namun, bagaimana jika ada fakta bahwa vendor juga memiliki pelanggaran kewajiban manajemen proyek seperti penundaan di setiap tahap, dan bahwa kesulitan dalam kemajuan pengembangan itu sendiri juga merupakan salah satu faktor dalam perubahan kebijakan perusahaan?

Seperti yang telah disebutkan sebelumnya, pengembangan sistem adalah sesuatu yang dilakukan dengan kerjasama erat antara vendor dan pengguna, dengan keduanya memiliki banyak kewajiban. Oleh karena itu, meskipun pengguna yang memulai pembicaraan tentang penghentian dan vendor mungkin berpikir bahwa ini adalah pembatalan karena alasan pribadi pengguna, penting untuk menyadari bahwa ada kemungkinan vendor dapat ditunjuk sebagai penyebab dan dapat dikembalikan dengan argumen seperti pembatalan berdasarkan pelanggaran kewajiban atau pembatalan dengan persetujuan.

Apakah ini pembatalan karena alasan pribadi, pembatalan berdasarkan pelanggaran kewajiban, atau pembatalan dengan persetujuan, perbedaan ini seringkali ditentukan secara individual untuk setiap kasus, tergantung pada kemajuan proyek dan riwayat negosiasi sebelumnya. Oleh karena itu, jika vendor melanjutkan penanganan pasca-proyek dengan pemahaman bahwa ini adalah pembatalan karena alasan pribadi pengguna, penting untuk meninggalkan catatan yang jelas tentang hal ini dalam risalah rapat, dll., untuk mencegah perselisihan tentang hal ini nantinya.

Mengkonfirmasi Pasal Dasar Klaim Biaya dan Ganti Rugi Selanjutnya

Mengingat poin-poin di atas, jika pembicaraan dapat dilanjutkan sebagai pembatalan atas keinginan pengguna sendiri, selanjutnya, kita akan mempertimbangkan apakah vendor dapat mengajukan klaim biaya atau ganti rugi kepada pengguna berdasarkan persentase penyelesaian.

Pasal yang harus dirujuk dalam kasus seperti ini berbeda tergantung pada jenis kontrak. Kontrak pengembangan sistem dapat dibedakan menjadi kontrak pekerjaan dan kontrak kuasa.

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

Dan, dalam kasus kontrak kuasa dan kontrak pekerjaan, Hukum Sipil Jepang (Japanese Civil Code) menetapkan hal berikut:

a.) Dalam kasus kontrak kuasa
Klaim Biaya: Pasal 648 Ayat 3 Hukum Sipil Jepang
Jika kuasa berakhir di tengah jalan karena alasan yang tidak dapat diatribusikan kepada penerima kuasa, penerima kuasa dapat mengajukan klaim biaya sesuai dengan persentase pelaksanaan yang telah dilakukan.
Klaim Ganti Rugi: Pasal 651 Hukum Sipil Jepang
1. Kuasa dapat dibatalkan oleh masing-masing pihak kapan saja.
2. Jika salah satu pihak membatalkan kuasa pada waktu yang merugikan pihak lain, pihak tersebut harus mengganti kerugian pihak lain. Namun, ini tidak berlaku jika ada alasan yang tidak dapat dihindari.

b.) Dalam kasus kontrak pekerjaan
Klaim Ganti Rugi: Pasal 641 Hukum Sipil Jepang
Selama pekerja tidak menyelesaikan pekerjaannya, pemesan dapat membatalkan kontrak kapan saja dengan memberikan ganti rugi.

Perlu dicatat bahwa cakupan ganti rugi berdasarkan Pasal 641 Hukum Sipil Jepang tidak hanya mencakup biaya yang sudah dikeluarkan, tetapi juga dianggap mencakup “keuntungan yang akan diperoleh jika kontrak tidak dibatalkan”. Ini mencerminkan pemikiran bahwa memaksa penyelesaian pekerjaan yang tidak lagi diperlukan oleh pemesan adalah sia-sia, dan dalam kasus seperti itu, lebih masuk akal untuk menjamin keuntungan pihak penerima pesanan dengan membayar kompensasi yang sama.

Namun, dalam banyak kasus, ganti rugi berdasarkan Pasal 641 Hukum Sipil Jepang dikecualikan dalam kontrak individu antara vendor dan pengguna. Dalam kasus seperti itu, janji antara pihak-pihak yang dibuat secara individu (yaitu, kontrak) akan menjadi prioritas, dan peraturan Hukum Sipil seperti ini mungkin tidak berlaku, jadi perlu berhati-hati.

Memajukan Pembuktian Volume dan Kerugian

Dalam kasus pembatalan karena alasan pribadi dari pihak pengguna, yang sering terlihat dalam kontrak adalah klaim atas biaya komisi untuk volume (yaitu bagian yang telah selesai) dan klaim atas ganti rugi. Oleh karena itu, biasanya, dari pihak vendor, diperlukan untuk melakukan pembuktian tentang volume dan kerugian untuk melakukan klaim ganti rugi.

Namun, pembuktian volume ini, yaitu pembuktian persentase penyelesaian, diperkirakan akan menjadi tugas yang sangat berat jika dilakukan secara nyata. Sebab, terkait sejauh mana item pekerjaan telah selesai, terutama jika ada beberapa subkontraktor, jumlah wawancara untuk konfirmasi kemajuan, jika dilakukan secara nyata, dapat dipikirkan menjadi cukup besar. Selain itu, jika harus melakukan semua hal seperti pembuatan dokumen untuk mendukung hasil wawancara dan dokumentasi isi wawancara itu sendiri, beban kerja akan menjadi sangat besar. Jika ada risiko bahwa pembuktian masih tidak cukup meskipun telah melakukan semua itu, usaha yang dikeluarkan untuk persiapan pembuktian bisa menjadi sia-sia, dan ada banyak kesulitan.

Mengingat hal ini, sebagai langkah-langkah, pada tahap kontrak awal, dapat dipertimbangkan untuk melakukan hal-hal seperti mencantumkan dari awal bahwa jika pembatalan dilakukan di tengah jalan, akan dihitung secara prorata berdasarkan jumlah hari hingga saat pembatalan, untuk membuat perhitungan menjadi lebih sederhana. Selain itu, mengingat bahwa klaim atas volume memerlukan banyak usaha untuk pembuktian, metode lain yang dapat dipertimbangkan adalah menyerah pada klaim atas volume itu sendiri dan melakukan klaim atas “biaya yang diperlukan untuk pengembangan bagian yang telah selesai”. Jika ini adalah biaya pengembangan internal, seringkali dapat dengan mudah dihitung dengan rumus sederhana “jam kerja x tarif”. Terutama untuk proyek dengan tingkat keuntungan rendah, dengan memprioritaskan klaim berbasis biaya daripada volume, diharapkan dapat melakukan penggantian kerugian sambil mempertimbangkan kemudahan pemulihan piutang, yang seringkali menjadi langkah penyelamatan yang lebih realistis.

Apa yang harus dipertimbangkan dari sisi pengguna?

Sebagai catatan, ada beberapa hal yang harus dipertimbangkan oleh pengguna yang ingin membatalkan kontrak atas keinginan sendiri. Hal tersebut adalah memastikan perkiraan jumlah kompensasi kerugian yang harus dibayar kepada vendor. Mengapa kita menggunakan kata ‘perkiraan’? Karena tujuannya adalah untuk memberikan gambaran umum yang akan membantu dalam negosiasi selanjutnya (meskipun penentuan keinginan untuk membatalkan kontraknya sendiri terlambat akan menjadi sia-sia, jadi jumlah yang tepat tidak diperlukan).

Jika jumlah perkiraan yang telah dikonfirmasi dianggap tidak wajar, Anda harus meminta penjelasan. Namun, jika Anda mencoba melakukan negosiasi yang tidak masuk akal untuk menekan jumlah pembayaran, ada risiko bahwa situasi akan menjadi lebih rumit karena tuntutan hukum yang tidak berarti. Jika negosiasi antara kedua belah pihak tampak sulit, mungkin menjadi pilihan untuk berkonsultasi dengan pengacara.

Selain itu, dalam artikel ini, kami telah menjelaskan dengan asumsi bahwa kontrak terkait pengembangan sistem telah disepakati. Namun, dalam kenyataannya, dalam pengembangan sistem, seringkali ada perselisihan tentang apakah kontrak telah berlaku secara efektif. Kami telah menjelaskan secara detail tentang hal ini dalam artikel di bawah ini.

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

Kesimpulan

Dalam artikel ini, kami telah menjelaskan alur penanganan kasus penundaan proyek karena alasan pribadi pengguna. Namun, poin utama dari artikel ini adalah, “Apakah benar-benar bisa dikatakan bahwa ini adalah karena alasan pribadi pengguna?” dan “Apakah benar-benar tidak ada kesalahan di pihak vendor?” perlu dipertimbangkan.

Fitur khas dari proyek pengembangan sistem adalah bahwa vendor dan pengguna sama-sama memiliki kewajiban besar dalam melanjutkannya. Oleh karena itu, jika Anda tidak mempertimbangkan dengan baik sebelumnya apakah benar-benar mungkin untuk menyalahkan pihak lain secara sepihak, Anda harus menyadari bahwa ini bisa menjadi situasi yang semakin memperburuk keadaan.