Apakah Mungkin untuk Menaikkan Estimasi Biaya Pengembangan Sistem Setelahnya?

Pekerjaan pengembangan sistem melibatkan banyak orang, baik dari pihak pengguna yang memesan maupun pihak vendor yang menerima pesanan. Oleh karena itu, bukanlah hal yang mudah untuk semua orang berjalan seiring dalam menjalankan proyek. Tentu saja, perencanaan sangat penting dalam pekerjaan ini, tetapi pada saat yang sama, apakah pengguna yang memesan dapat merangkum informasi yang tepat dan menyampaikannya secara jelas kepada vendor? Kebenarannya, tidak selalu demikian. Jika, setelah proses pengembangan telah berlangsung cukup jauh, pengguna meminta perubahan spesifikasi atau penambahan fungsi, apakah vendor dapat menambahkan biaya tersebut ke estimasi biaya awal? Ini adalah pertanyaan yang sangat penting bagi pihak yang menerima pekerjaan.

Bagaimana hak-hak ini diakui dalam hukum, dan dalam situasi apa? Bagaimana cara menentukan jumlah kompensasi untuk pengembangan tambahan dan perbaikan fungsi? Artikel ini akan membahas berbagai pertanyaan tersebut.

Kapan bisa dikatakan sebagai Pengembangan Tambahan atau Perbaikan Fungsi?

Dalam proyek pengembangan sistem, jenis kontrak yang biasanya digunakan saat menerima pekerjaan adalah kontrak kerja atau kontrak kuasa. Dalam jenis kontrak ini, apa yang harus dilakukan oleh pihak yang menerima pekerjaan (yaitu kewajiban) dan kompensasi yang terkait dengan itu (yaitu hak) akan ditunjukkan dalam kontrak sebagai pasangan. Oleh karena itu, jika ada pekerjaan yang tidak termasuk dalam pekerjaan yang menjadi dasar jumlah kompensasi ditambahkan nantinya, itu dapat dikatakan sebagai pengembangan tambahan atau perbaikan fungsi. Sebaliknya, jika pekerjaan tersebut termasuk, itu akan dianggap sebagai sesuai dengan spesifikasi awal (yaitu dalam kerangka kontrak sebelumnya).

Untuk penjelasan lebih lanjut tentang perbedaan antara kontrak kerja dan kontrak kuasa, silakan lihat artikel lainnya.

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

Namun, jika kita mengatakan bahwa semua hal, termasuk penyesuaian halus font yang ditampilkan di layar, adalah pengembangan tambahan kecuali jika ditentukan dalam spesifikasi sebelumnya, itu bisa menghambat transaksi bisnis yang lancar. Oleh karena itu, tidak mudah untuk menarik garis yang sama untuk semua masalah, termasuk diskusi tentang detail spesifikasi ini. Namun, jika kita harus memberikan pedoman umum,

• Jika diperintahkan untuk menambahkan lebih banyak fungsi setelah spesifikasi telah dikonfirmasi
• Jika diperintahkan untuk memperbaiki program setelah implementasinya selesai

dalam kasus seperti itu, klaim tersebut mungkin memiliki validitas hukum yang cukup tinggi.

Kasus Pengadilan di mana Apakah ini bisa disebut Pengembangan Tambahan atau Perbaikan Fungsi Menjadi Titik Perselisihan

Contoh Positif: Kasus Perubahan Spesifikasi Desain Dasar Setelah Fakta

Contoh berikut adalah kasus di mana spesifikasi diubah setelah fakta.

Pengembangan perangkat lunak melalui proses pengembangan yang melibatkan ① definisi persyaratan, ② desain eksternal, ③ desain internal, ④ pembuatan program sumber (desain program, pengkodean), ⑤ berbagai jenis pengujian (pengujian unit, pengujian kombinasi, pengujian sistem) (omisi) Spesifikasi awal (omisi) direalisasikan melalui pekerjaan setelah desain internal, dan ini adalah lingkup pekerjaan yang berhubungan dengan hak klaim pembayaran berdasarkan kontrak pengembangan ini. Permintaan perubahan spesifikasi secara hukum dianggap sebagai aplikasi kontrak pengembangan baru yang melebihi lingkup pekerjaan berdasarkan kontrak awal oleh klien, dan jika kontraktor menyelesaikan pekerjaan yang berkaitan dengan penugasan tambahan tanpa menunjukkan jumlah biaya konstruksi tambahan dan tanpa persetujuan jumlah biaya tambahan, kontrak baru tanpa penentuan jumlah biaya dianggap telah dibentuk antara klien dan kontraktor, dan kewajiban pembayaran biaya pengembangan tambahan yang wajar muncul.

Putusan Pengadilan Distrik Osaka, 29 Agustus 2002 (Tahun Heisei 14)

Memahami kata kunci seperti “hubungan pembayaran” dan “kontrak baru” akan membantu Anda memahami putusan ini lebih dalam.

Sebagai catatan, putusan ini juga menunjukkan poin yang sangat menarik lainnya. Yaitu, penyesuaian detail seperti penempatan tombol dan jenis huruf tidak termasuk dalam perubahan spesifikasi yang disebutkan di sini. Bagian yang relevan adalah sebagai berikut.

Namun, dalam pengembangan perangkat lunak, mengingat bahwa biasanya, detail seperti jenis huruf yang digunakan untuk menampilkan teks di layar dan penempatan tombol tidak ditentukan pada tahap desain eksternal, dan detail tersebut biasanya dapat dimodifikasi sedikit melalui diskusi antara pihak-pihak setelah spesifikasi dikonfirmasi, tidak wajar untuk menganggap permintaan untuk detail spesifikasi sebagai perubahan spesifikasi.

Putusan Pengadilan Distrik Osaka, 29 Agustus 2002 (Tahun Heisei 14)

Putusan ini menggunakan kata yang menarik, “detail spesifikasi”.

• Kasus di mana sesuatu yang seharusnya sudah ditentukan dibalik setelahnya
• Kasus di mana sesuatu yang bisa ditentukan seiring berjalannya waktu dibiarkan tidak ditentukan dan diproses

Ini mungkin juga menunjukkan bahwa perlakuan hukum yang berbeda harus diberikan tergantung pada kasus tersebut.

Contoh Positif Lainnya

Selain itu, dalam kasus yang diakui sebagai pengembangan tambahan atau perbaikan fungsi, terdapat:

• Kasus di mana jumlah program yang disampaikan meningkat sekitar dua kali lipat dari rencana awal (Putusan Pengadilan Distrik Tokyo, 22 April 2017)
• Kasus di mana periode kerja diperpanjang sekitar tiga kali lipat (Putusan Pengadilan Distrik Tokyo, 22 Januari 2010 (Tahun Heisei 22))

Sebagai contoh. Dengan melihat dari perspektif ini, dapat dilihat bahwa pendekatan yang mempertimbangkan perpanjangan periode kerja sebagai pengembangan tambahan dalam arti luas, dan memberikan perlindungan hukum tertentu, telah diadopsi.

“Persetujuan Pengembangan Tambahan dan Kenaikan Upah” dan “Pembentukan Kontrak Awal” adalah Masalah yang Berbeda

Sebagai catatan, berikut adalah poin penting terkait masalah ini:

1. “Apakah kontrak pengembangan sistem (kontrak awal) antara dua perusahaan telah resmi dibentuk?”
2. “Setelah kontrak pengembangan sistem resmi dibentuk, apakah kontrak terkait pengembangan tambahan juga telah dibentuk?”

Standar penilaian pengadilan berbeda dalam kedua situasi ini. Secara singkat, pengadilan:

• Cenderung ketat terhadap poin 1 (sulit untuk mengakui pembentukan kontrak jika tidak ada dokumen kontrak)
• Cenderung lebih fleksibel terhadap poin 2 (meskipun tidak ada dokumen kontrak untuk pengembangan tambahan, pengadilan cenderung mengakui kenaikan upah dan hal-hal lainnya)

Untuk poin 1, kami telah menjelaskannya secara detail dalam artikel lain.

Contoh Penolakan: Kasus di mana konten komisi yang sama diperlakukan sebagai termasuk dalam hukum

Namun, di sisi lain, ada juga kasus pengadilan di mana peningkatan remunerasi tidak diizinkan. Dalam kasus yang dikutip dalam putusan berikut, setelah kontrak pengembangan sistem ditandatangani, konten pekerjaan berubah, dan apakah peningkatan remunerasi dapat diizinkan atau tidak menjadi sengketa.

Poin perdebatan dalam kasus ini adalah, (1) apa isi pekerjaan yang diterima oleh penggugat dalam kontrak ini, (2) apakah ada kesepakatan antara penggugat dan terdakwa untuk memperluas skala dan meningkatkan biaya untuk pekerjaan yang diterima, (omisi), dan sebagainya. (omisi)

Pada dasarnya, kontrak ini adalah kontrak pengadaan yang menyetujui bahwa jumlah biaya adalah kompensasi yang ditentukan untuk pekerjaan yang diterima oleh penggugat, dan jumlah langkah, tarif, dan sebagainya yang berkaitan dengan pekerjaan yang diterima hanyalah dokumen internal yang digunakan untuk menghitung jumlah biaya pengadaan di dalam penggugat, dan peningkatan jumlah langkah dan sebagainya tidak ada hubungannya dengan biaya pengadaan. (omisi)

Seperti yang telah diakui, pekerjaan yang diterima oleh penggugat berubah pada tanggal 25 Februari 1987 (Showa 62), dan hanya terbatas pada manajemen sistem, perhitungan biaya konstruksi, dan sebagian dari utilitas, dan sisanya ditangani oleh terdakwa, tetapi pekerjaan penggugat setelah perubahan tersebut masih dalam lingkup pekerjaan pengembangan sesuai dengan kontrak awal, dan kompensasi untuk pekerjaan tersebut ditutupi oleh jumlah biaya komisi yang telah disepakati sebagai biaya yang ditentukan pada awal kontrak ini.

Putusan Pengadilan Distrik Tokyo, 12 Juni 1995 (Heisei 7)

Dalam putusan tersebut, meskipun konten pekerjaan yang diberikan kepada vendor telah berubah, konten pengembangan tersebut dianggap berada dalam lingkup konten kontrak awal, dan diputuskan bahwa itu harus ditutupi dalam remunerasi yang dijanjikan awalnya.

Pada akhirnya, berdasarkan pertimbangan tentang apa yang menjadi dasar penentuan jumlah remunerasi, untuk pekerjaan yang tidak termasuk di dalamnya, tampaknya pendekatan akan mengizinkan permintaan remunerasi tambahan.

Dan, apa yang menjadi dasar penentuan jumlah remunerasi tidak selalu hanya kontrak, tetapi juga risalah rapat dan lainnya akan dianggap sebagai bukti. Detail tentang pentingnya risalah rapat dijelaskan dalam artikel di bawah ini.

Bagaimana Menentukan Jumlah Imbalan untuk Pengembangan Tambahan dan Perbaikan Fungsi

Di lapangan pengembangan sistem, bukanlah hal yang jarang jika spesifikasi yang tampaknya telah ditetapkan berubah kemudian. Setiap kali hal seperti ini terjadi, tidak realistis untuk menyiapkan kontrak tertulis baru dan melanjutkan urusan kontrak. Bagaimana jika proyek gagal tanpa bisa melakukan prosedur seperti ini, bagaimana kita harus menghitung jumlah imbalan untuk hal-hal yang harus ditambahkan atau diperbaiki?

Sebagai pasal yang harus dijadikan referensi dalam kasus seperti ini, ada Pasal 512 dari Hukum Dagang Jepang (bagian yang digarisbawahi adalah bagian yang digarisbawahi oleh penulis).

Pasal 512 Hukum Dagang Jepang: Ketika seorang pedagang melakukan tindakan untuk orang lain dalam lingkup bisnisnya, dia dapat meminta imbalan yang wajar.

Masalahnya adalah berapa jumlah “imbalan yang wajar” dalam pasal ini, dalam konteks situasi konkret. Melihat dari preseden hukum di masa lalu, tampaknya pendekatan yang menganggap bahwa biaya harus ditanggung sebanding dengan jumlah kerja, volume, atau durasi telah diadopsi. Ini mungkin karena pengembangan sistem adalah jenis layanan, dan biaya dasarnya adalah biaya tenaga kerja.

Oleh karena itu, meskipun tingkat abstraksi frasa “imbalan yang wajar” dalam hukum dagang, mengestimasi harga pasar untuk jumlah imbalan tambahan dalam konteks seperti ini tidak memerlukan perhitungan yang sulit. Mari kita lihat beberapa preseden hukum di bawah ini.

Kasus 1: Contoh Kasus yang Mengakui Tambahan Upah yang Proporsional dengan Peningkatan Jam Kerja

Jumlah jam kerja pengembangan berdasarkan perubahan spesifikasi ini adalah total 257,5 hari kerja per orang, yang wajar untuk dianggap sebagai jumlah tersebut. Jika kita mengkonversi ini dengan biaya pengembangan per hari per orang yang sama dengan kontrak pengembangan ini, yaitu 32.500 yen (dalam kasus A3, tarifnya adalah 650.000 yen per orang per bulan, dan jika kita menganggap bahwa ada 20 hari kerja dalam sebulan, biaya pengembangan per hari per orang menjadi 32.500 yen.), biaya pengembangan tambahan berdasarkan permintaan perubahan spesifikasi ini adalah 83.687.500 yen, yang wajar untuk dianggap sebagai jumlah tersebut.

Putusan Pengadilan Distrik Osaka, 29 Agustus Tahun Heisei 14 (2002)

“Per orang per hari” adalah kata kunci di sini. Ini menunjukkan bahwa jam kerja digunakan sebagai dasar untuk menghitung upah tambahan.

Kasus 2: Contoh Kasus yang Mengakui Tambahan Upah yang Proporsional dengan Jumlah Program

Jika kita mempertimbangkan jumlah upah yang layak termasuk tambahan dalam kasus ini, sebagian besar biaya asli pengembangan sistem komputer adalah biaya tenaga kerja teknisi, dan biaya tenaga kerja ini umumnya proporsional dengan jumlah program yang dibuat. Oleh karena itu, jika kita membagi jumlah kontrak awal sebesar 23.250.000 yen dengan jumlah program yang telah selesai hingga pemeriksaan kedua, yaitu 206 program, dan mengalikan jumlah ini dengan jumlah program yang telah melalui pemeriksaan ketiga, yaitu 414 program, kita mendapatkan jumlah 46.725.728 yen (23.250.000 ÷ 206 x 414 = 46.725.728) yang dianggap layak.

Putusan Pengadilan Distrik Tokyo, 22 April 2005 (Tahun 17 Era Heisei)

Meskipun banyak angka yang muncul, jika Anda membaca dengan tenang, Anda akan melihat bahwa tidak ada perhitungan yang rumit. Berdasarkan konten kontrak awal, mereka hanya melakukan perkalian sederhana “harga per program x jumlah” setelah memastikan “berapa harga per program yang mereka perkirakan dalam pembicaraan mereka”.

Kasus 3: Contoh Kasus yang Mengakui Tambahan Upah yang Proporsional dengan Durasi

Dalam kontrak A3, upah untuk pekerjaan sebagai kuasa hukum selama tiga bulan dari Januari hingga Maret tahun Heisei 17 (2005) ditetapkan sebesar 60 juta yen. Sementara itu, pekerjaan yang dilakukan secara gratis termasuk dalam pekerjaan setelah April tahun yang sama, namun, seperti tahun sebelumnya, diharapkan volume pekerjaan akan meningkat setelah April tahun yang sama karena dimulainya semester baru dan sistem pendaftaran kursus mulai beroperasi. Dengan mempertimbangkan hal-hal ini, berdasarkan 60 juta yen yang ditetapkan sebagai upah untuk pekerjaan selama tiga bulan, upah yang wajar untuk pekerjaan selama enam bulan dari April hingga September tahun Heisei 17 (2005) adalah 120 juta yen.

Putusan Pengadilan Distrik Tokyo, 22 Januari tahun Heisei 22 (2010)

Putusan di atas menunjukkan bahwa upah tambahan juga dihitung dengan perhitungan proporsional sederhana untuk periode yang diperpanjang.

Rangkuman

Seperti yang telah dijelaskan di atas melalui beberapa contoh kasus, tampaknya kita dapat melihat beberapa pola dan kesamaan dalam perlakuan hukum terhadap kompensasi tambahan untuk pekerjaan programmer dan insinyur. Dalam prinsip, tampaknya ada sikap untuk menghitung sebanyak mungkin berdasarkan indikator yang relatif objektif, seperti jumlah jam kerja yang dihabiskan, volume kerja formal (seperti program yang disampaikan), dan waktu atau durasi kerja.

Mungkin tampak tidak menarik bahwa kompensasi tambahan muncul hanya sebanding dengan jumlah tenaga kerja yang diinvestasikan, volume kerja formal yang dilakukan, atau waktu yang dihabiskan, terutama jika kita mempertimbangkan bahwa penambahan pengembangan atau perbaikan fungsi ini terjadi karena kegagalan dalam prosedur yang tepat atau estimasi jam kerja yang sempurna. Namun, dari perspektif pihak yang menerima kontrak, bahkan jika tujuannya adalah untuk menjalankan bisnis dengan memprioritaskan keuntungan pelanggan, fakta bahwa hak-hak semacam ini mungkin diakui secara hukum mungkin penting dalam konteks manajemen krisis.