MONOLITH LAW OFFICE+81-3-6262-3248Hari kerja 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Apa itu Hukum Jika Upah Pengembangan Sistem Tidak Dibayar

IT

Apa itu Hukum Jika Upah Pengembangan Sistem Tidak Dibayar

Bagi pihak vendor yang menerima proyek pengembangan sistem, risiko terbesar dalam beberapa hal adalah situasi di mana “meskipun telah melakukan pengiriman, pengguna tidak membayar imbalan”. Biaya yang diperlukan untuk pengembangan sistem seringkali sebagian besar adalah tenaga kerja yang memiliki keterampilan seperti programmer, sehingga seringkali biaya tenaga kerja cukup besar. Keterlambatan dalam penagihan penjualan bisa menjadi masalah hidup atau mati. Dalam artikel ini, kami akan menjelaskan dari sudut pandang hukum tentang hal-hal yang harus dipertimbangkan oleh pihak vendor dalam situasi di mana pengguna tidak menanggapi pembayaran imbalan.

Pertama, Periksa Apakah Anda Dapat Mengajukan Klaim Biaya

  • Vendor telah menyerahkan hasil kerja kepada pengguna, namun pengguna tidak menerima penyerahan tersebut, sehingga proses klaim biaya pun terhambat.
  • Meskipun dianggap telah selesai hingga tahap penerimaan, ada beberapa kesalahpahaman antara persepsi vendor dan pengguna, dan pengguna tidak bersedia membayar biaya.

Situasi seperti ini sangat mungkin terjadi dalam kenyataannya.

Perlu dicatat, pengguna memeriksa spesifikasi sistem yang telah selesai dan menerima penyerahan disebut “penerimaan” dalam istilah pengembangan sistem. Arti dan hal-hal yang perlu dipertimbangkan ketika proses penerimaan tidak berjalan dengan baik dijelaskan secara detail dalam artikel berikut.

Artikel terkait: Apa itu Penerimaan dan Aplikasi Klausul Penerimaan Diperkirakan dalam Pengembangan Sistem[ja]

Meskipun penjelasan umum tentang penerimaan itu sendiri diserahkan kepada artikel di atas, dari sudut pandang hukum, perlu dipertimbangkan apakah penerimaan pengguna telah selesai atau tidak, dengan mempertimbangkan juga ketentuan “Klausul Penerimaan Diperkirakan”.

Dengan mempertimbangkan hal ini, hal pertama yang perlu dipertimbangkan jika pengguna tidak bersedia membayar biaya adalah sebagai berikut.

  1. Apakah pekerjaan telah selesai atau masih belum selesai
  2. Apakah Tanggung Jawab Jaminan Cacat (Pasal 635 Hukum Sipil Jepang) dapat diterapkan atau tidak

Alasan mengapa perlu memeriksa dua poin di atas terlebih dahulu adalah karena jika pekerjaan belum selesai dan Tanggung Jawab Jaminan Cacat (Pasal 635 Hukum Sipil Jepang) tidak berlaku, bahkan jika Anda mengajukan gugatan, Anda tidak dapat mengharapkan pembayaran biaya.

Lalu, apa yang harus diperiksa oleh pihak vendor untuk mempertimbangkan dua poin di atas? Mari kita lihat dokumen apa saja yang perlu diperiksa.

Dokumen yang Harus Diperiksa untuk Menentukan Kelayakan Klaim Pembayaran

Faktur
Jika tidak ada faktur, ini dapat dianggap sebagai indikasi bahwa pengiriman belum selesai dan pekerjaan belum selesai.
Dokumen Pemberitahuan Hasil Penerimaan
Ini adalah dokumen paling penting saat menentukan apakah pekerjaan dapat dianggap selesai. Selain itu, jika penerimaan ditunda karena alasan pengguna, akan baik untuk memeriksa bagaimana “Klausul Penerimaan Dianggap” ditulis dalam kontrak.
Daftar Manajemen Tugas
Ini adalah dokumen untuk mengetahui jenis tugas apa yang telah ditemukan dan bagaimana mereka telah ditangani. Ini juga menjadi dokumen untuk memahami kondisi kerusakan atau masalah yang muncul setelah pengiriman, dan status perbaikan untuk itu.
Dokumen Definisi Kebutuhan, Dokumen Desain, dan Dokumen Manajemen Perubahan, serta Catatan Rapat, dll.
Ini adalah dokumen yang menjelaskan apa yang harus disebut sebagai kerusakan atau masalah dengan memperjelas pemahaman awal antara pengguna dan vendor.

Selain itu, kami telah memberikan penjelasan rinci dalam artikel lain tentang bagaimana mengelola perubahan spesifikasi sistem yang harus dikembangkan dan cara membuat dokumen manajemen perubahan.

Artikel terkait: Bagaimana Mengelola Perubahan dalam Pengembangan Sistem dari Perspektif Hukum[ja]

Surat Pemberitahuan Pemutusan atau Dokumen yang Menyatakan Niat Pengguna
Ini adalah cara untuk mengetahui apa niat pengguna jika mereka tidak ingin melanjutkan penerimaan (atau tidak mau membayar kompensasi).

Selanjutnya, periksa berapa banyak klaim yang dapat diajukan

Bagaimana cara menghitung ulang jumlah klaim setelah perubahan spesifikasi?

Sebagai prinsip, berapa banyak klaim yang dapat diajukan biasanya ditulis dalam kontrak. Namun, dalam kasus di mana perubahan spesifikasi atau sejenisnya telah dilakukan setelahnya, mungkin ada situasi di mana tidak ada kontrak yang tepat (atau dokumen yang setara) yang tersisa. Cara menghitung ulang estimasi berdasarkan alasan yang muncul setelah perubahan spesifikasi atau penambahan fungsi dijelaskan secara detail dalam artikel berikut.

Artikel terkait: Apakah mungkin untuk meningkatkan jumlah perkiraan pengembangan sistem setelahnya[ja]

Metode penghitungan ulang estimasi adalah seperti yang dijelaskan dalam artikel ini, tetapi terutama dari sudut pandang mempertimbangkan apakah mungkin untuk meningkatkan jumlah klaim,

  1. Ketersediaan dan isi estimasi untuk pengembangan tambahan dan perbaikan fungsi
  2. Respon pengguna terhadap estimasi
  3. Ketersediaan persetujuan tentang situasi yang menyebabkan pengembangan tambahan dan perbaikan fungsi yang tercatat dalam daftar manajemen masalah, dan jumlahnya

Anda akan melihat terutama pada poin-poin tersebut. Intinya adalah, apakah ada kesepakatan dengan pengguna tentang “mengorder pekerjaan dengan jumlah itu” (dengan kata lain, dapat dikatakan bahwa kontrak telah dibuat) dan memeriksa titik tersebut.

Terakhir, Pertimbangkan Isu-isu Penting Saat Melakukan Tuntutan Hukum

Perhatikan Kemungkinan Tuntutan Balik

Dalam pengembangan sistem, sering kali ketika satu pihak (baik pengguna atau vendor) mengajukan tuntutan hukum terhadap pihak lain, pihak yang dituntut justru mengajukan tuntutan balik. Artinya, dalam situasi di mana pembayaran tidak dilakukan, biasanya pihak pengguna juga memiliki alasan tersendiri.

Pada dasarnya, dalam pengembangan sistem, pihak pengguna juga memiliki kewajiban untuk bekerja sama dalam berbagai hal. Namun, yang perlu diingat adalah bahwa pihak vendor, sebagai ahli dalam pengembangan sistem, memiliki diskresi yang luas dan tanggung jawab yang besar. Kami telah menjelaskan secara detail tentang kewajiban manajemen proyek yang harus dipenuhi oleh pihak vendor dalam pengembangan sistem di artikel berikut.

Artikel terkait: Apa itu Kewajiban Manajemen Proyek dalam Pengembangan Sistem[ja]

Dengan kata lain, apakah mungkin untuk menyalahkan pihak pengguna yang secara sepihak tidak membayar adalah hal yang perlu dipertimbangkan sebelumnya. Jika kita melihat kasus hukum sebelumnya, sering kali meskipun awalnya pihak vendor yang mengajukan tuntutan pembayaran, pihak pengguna justru mengajukan tuntutan balik berupa kewajiban untuk mengembalikan keadaan semula atau klaim ganti rugi.

Pertimbangkan Juga Apakah Ada Keuntungan Bisnis

Meskipun argumen pihak vendor diterima dan tuntutan pembayaran diakui dalam persidangan, jika situasi sampai pada tahap tuntutan hukum, diperkirakan akan sulit untuk melanjutkan transaksi di masa depan. Selain itu, meskipun argumen Anda diterima dalam persidangan, Anda harus siap bahwa mungkin membutuhkan waktu yang cukup lama untuk menerima pembayaran. Mengingat biaya dan usaha yang diperlukan untuk melakukan tuntutan hukum tidaklah kecil, sering kali lebih baik untuk berusaha menemukan titik kompromi.

Kesimpulan

Jika pengguna tidak mau membayar imbalan, untuk mempertimbangkan masalah ini secara hukum, Anda perlu memeriksa berbagai jenis dokumen. Selain itu, bukan hanya manajemen dokumen yang harus dilakukan dengan baik, tetapi juga perlu dipertimbangkan risiko dan kerugian organisasional apa yang akan dihadapi jika akhirnya memutuskan untuk mengajukan gugatan.

Memang, peningkatan manajemen dokumen sehari-hari biasanya merupakan bagian dari pekerjaan tingkat lapangan. Namun, jika Anda memutuskan untuk mengajukan gugatan berdasarkan dokumen dan materi yang disimpan, ini bisa menjadi keputusan bisnis yang signifikan. Anda harus memahami alur proses ini, bersama dengan fakta bahwa kekuatan dan organisasi antara manajemen dan lapangan akan diuji dalam situasi yang tidak biasa ini.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Kembali ke atas