Apa itu Undang-Undang Jepun apabila Bayaran untuk Pembangunan Sistem Tidak Dibayar
Bagi pihak vendor yang menerima tugas pembangunan sistem, risiko terbesar dalam satu ertinya mungkin adalah situasi di mana “pengguna tidak membayar upah walaupun telah diserahkan”. Kos yang diperlukan untuk pembangunan sistem seringkali melibatkan tenaga kerja yang mahir seperti pengaturcara, oleh itu, seringkali banyak kos tenaga kerja yang terlibat. Kegagalan dalam mengumpul pendapatan boleh menjadi masalah hidup mati. Dalam artikel ini, kami akan membincangkan isu yang perlu dipertimbangkan oleh pihak vendor dalam situasi di mana pengguna tidak membayar upah, dari perspektif undang-undang.
Pertama sekali, perlu disahkan sama ada keadaan membolehkan tuntutan bayaran
- Walaupun vendor telah menyerahkan hasil kerja kepada pengguna, pengguna tidak menerima penyerahan tersebut, dan akibatnya, proses tuntutan bayaran juga terbantut.
- Walaupun vendor beranggapan bahawa proses penerimaan telah selesai, terdapat ketidaksepadanan dengan pengertian pengguna, dan pengguna enggan membayar bayaran yang dituntut.
Keadaan seperti ini adalah sesuatu yang sangat mungkin berlaku dalam realiti.
Selain itu, proses di mana pengguna memeriksa spesifikasi sistem yang telah siap dan menerima penyerahan dikenali sebagai ‘penerimaan’ dalam istilah pembangunan sistem. Makna dan perkara yang perlu dipertimbangkan apabila proses penerimaan ini tidak berjalan lancar dijelaskan secara terperinci dalam artikel berikut.
Artikel Berkaitan: Apa itu Penerimaan dan Klausa Penerimaan Anggaran dalam Pembangunan Sistem[ja]
Walaupun penjelasan keseluruhan tentang penerimaan itu sendiri diserahkan kepada artikel di atas, dari segi undang-undang, sama ada penerimaan oleh pengguna telah selesai atau tidak perlu dipertimbangkan dengan mempertimbangkan juga peruntukan ‘Klausa Penerimaan Anggaran’.
Dengan mempertimbangkan perkara ini, perkara pertama yang perlu dipertimbangkan apabila menghadapi situasi di mana pengguna enggan membayar bayaran adalah seperti berikut:
- Sama ada kerja itu telah selesai atau masih belum selesai
- Sama ada Tanggungjawab Jaminan Kecacatan (Perkara 635 Undang-Undang Sivil Jepun) boleh dikenakan atau tidak
Alasan mengapa perlu mengesahkan dua perkara di atas terlebih dahulu adalah kerana jika kerja itu belum selesai dan Tanggungjawab Jaminan Kecacatan (Perkara 635 Undang-Undang Sivil Jepun) tidak dikenakan, tidak ada harapan untuk mendapatkan pembayaran walaupun tuntutan dibuat.
Jadi, apa yang perlu diperiksa oleh pihak vendor untuk mempertimbangkan dua perkara di atas? Mari kita lihat apa jenis dokumen yang perlu disemak di bawah.
Dokumen yang Perlu Disemak untuk Menyiasat Kelayakan Tuntutan Bayaran
Invois Penghantaran Jika tiada invois penghantaran, ini menunjukkan bahawa penghantaran belum selesai dan kerja belum siap, yang menguatkan anggapan ini. |
Dokumen yang Mengumumkan Hasil Penerimaan Ini adalah dokumen yang paling penting apabila menentukan sama ada kerja telah selesai atau tidak. Selain itu, jika penerimaan ditangguhkan kerana sebab-sebab pengguna, anda juga harus memeriksa bagaimana ‘klausa penerimaan anggap’ ditulis dalam kontrak. |
Senarai Pengurusan Isu Ini adalah dokumen yang membolehkan anda mengetahui isu apa yang telah ditemui sebelum ini dan bagaimana mereka ditangani. Ini juga merupakan dokumen untuk memahami keadaan kerosakan atau kecacatan yang ditemui selepas penghantaran, dan status pembaikan mereka. |
Dokumen Definisi Keperluan, Dokumen Reka Bentuk dan Dokumen Pengurusan Perubahan, Minat Mesyuarat, dll. Ini adalah dokumen yang menjelaskan apa yang harus dipanggil kerosakan atau kecacatan dengan menjelaskan apa yang difahami oleh pengguna dan vendor pada awalnya. |
Selain itu, kami telah memberikan penjelasan terperinci dalam artikel lain mengenai bagaimana mengurus perubahan spesifikasi sistem yang harus dibangunkan dan bagaimana membuat dokumen pengurusan perubahan.
Artikel Berkaitan: Bagaimana Mengurus Perubahan dalam Pembangunan Sistem dari Perspektif Undang-undang[ja]
Surat Pemberitahuan Pembatalan atau Dokumen yang Menyatakan Niat Pengguna Ini adalah cara untuk mengetahui apa niat pengguna jika mereka tidak mahu meneruskan penerimaan (atau tidak mahu membayar bayaran). |
Seterusnya, periksa berapa banyak tuntutan bayaran yang boleh dibuat
Sebagai prinsip, berapa banyak tuntutan yang boleh dibuat biasanya ditulis dalam kontrak. Walau bagaimanapun, jika terdapat perubahan spesifikasi atau sebagainya selepas itu, mungkin ada situasi di mana tiada kontrak yang tepat (atau dokumen yang setara) yang tersedia. Cara pengiraan semula anggaran berdasarkan sebab-sebab yang timbul selepas itu seperti perubahan spesifikasi atau penambahan fungsi dijelaskan secara terperinci dalam artikel berikut.
Artikel berkaitan: Adakah mungkin untuk meningkatkan jumlah anggaran pembangunan sistem selepas itu?[ja]
Walaupun kaedah pengiraan semula anggaran adalah seperti yang dinyatakan dalam artikel ini, terutamanya dari sudut pandang mempertimbangkan sama ada jumlah tuntutan boleh ditingkatkan atau tidak,
- Kewujudan dan kandungan anggaran untuk pembangunan tambahan atau pengubahsuaian fungsi
- Reaksi pengguna terhadap anggaran
- Kewujudan persetujuan mengenai situasi yang menyebabkan pembangunan tambahan atau pengubahsuaian fungsi yang dicatat dalam senarai pengurusan isu, dan jumlahnya
Anda perlu melihat terutamanya pada aspek-aspek ini. Intinya adalah untuk menyiasat sama ada ada persetujuan antara pengguna mengenai “menempah kerja dengan jumlah itu” (dengan kata lain, sama ada kontrak telah ditubuhkan) atau tidak.
Akhir sekali, mempertimbangkan isu-isu penting dalam melaksanakan tuntutan
Berhati-hati dengan kemungkinan tuntutan balas
Dalam pembangunan sistem, apabila pengguna atau vendor mengajukan tuntutan terhadap pihak lain, seringkali tuntutan balas diajukan oleh pihak yang dituntut. Ini bermakna, dalam situasi di mana pembayaran upah tidak dilakukan, pengguna juga mungkin mempunyai alasan mereka sendiri.
Pada dasarnya, dalam pembangunan sistem, pengguna juga mempunyai pelbagai kewajipan kerjasama, tetapi pertama-tama, kita tidak boleh lupa bahawa vendor, sebagai pakar dalam pembangunan sistem, mempunyai budi bicara yang luas dan tanggungjawab yang besar. Kami telah menjelaskan secara terperinci tentang kewajipan pengurusan projek yang ditanggung oleh pihak vendor dalam pembangunan sistem dalam artikel berikut.
Artikel berkaitan: Apa itu Kewajipan Pengurusan Projek dalam Pembangunan Sistem[ja]
Dengan kata lain, sama ada mungkin untuk menyalahkan pengguna yang tidak membayar upah secara sepihak perlu dipertimbangkan dengan baik sebelumnya. Jika kita melihat kes-kes mahkamah sebelum ini, terdapat banyak kes di mana vendor asalnya menuntut pembayaran upah dan mengajukan tuntutan, tetapi pengguna sebaliknya, menuntut kewajipan pemulihan keadaan asal dan tuntutan ganti rugi.
Pertimbangkan juga sama ada ada keuntungan dalam bisnis
Walaupun tuntutan vendor diterima dan tuntutan upah diakui dalam tuntutan, jika situasi menjadi rumit sehingga tuntutan diajukan, adalah dijangka bahawa kesinambungan transaksi seterusnya akan menjadi sukar dalam praktiknya. Selain itu, walaupun tuntutan anda diterima dalam tuntutan, anda harus bersedia untuk menghabiskan banyak masa sebelum anda benar-benar dapat menerima upah. Jika anda mempertimbangkan bahawa usaha dan kos yang terlibat dalam melaksanakan tuntutan tidak kecil, mungkin lebih baik untuk berusaha mencari titik kompromi.
Rumusan
Jika pengguna tidak mematuhi pembayaran ganjaran, untuk mempertimbangkan masalah ini secara undang-undang, anda perlu memeriksa pelbagai jenis dokumen. Selain itu, bukan hanya pengurusan dokumen yang teliti, tetapi juga perlu mempertimbangkan risiko dan kelemahan organisasi jika anda memutuskan untuk mengambil tindakan undang-undang.
Memang, pengurusan dokumen sehari-hari biasanya termasuk dalam tugas-tugas peringkat lapangan. Namun, jika anda memutuskan untuk mengambil tindakan undang-undang berdasarkan dokumen dan bahan yang disimpan, ini boleh menjadi keputusan pengurusan yang penting. Anda harus memahami seluruh proses ini, bersama dengan fakta bahawa kekuatan dan organisasi antara pihak lapangan dan pengurusan diuji dalam situasi luar biasa ini.
Category: IT
Tag: ITSystem Development