Strategi Penanganan Jika Terdapat Kerusakan Sistem Setelah Penerimaan

Dalam konteks umum pengembangan sistem, implementasi program dilakukan sesuai dengan konten yang telah ditentukan pada fase definisi persyaratan, dan pada akhirnya, baik pengguna maupun vendor memastikan apakah hasil akhir sesuai dengan spesifikasi atau tidak, dan proyek dianggap selesai setelah lulus penerimaan.

Namun, dalam kenyataannya, ada kemungkinan bahwa bug atau masalah yang tidak dapat ditemukan selama proses pengujian dan penerimaan dapat muncul selama fase operasional dan sebagainya. Jika Anda telah menerima pengiriman sekali, apa yang dapat Anda minta secara hukum?

Tidak Mengherankan Jika Masih Ada Bug Setelah Penerimaan atau Tahap Pengujian

Dari sudut pandang teknis, bukanlah hal yang jarang jika berbagai bug dan masalah muncul setelah proses pengujian berbagai jenis oleh pihak vendor selesai dan setelah penerimaan oleh pengguna. Biasanya, yang dilakukan pengguna dalam proses penerimaan adalah memeriksa input dan output yang dapat dilihat dari layar. Namun, sistem IT seringkali memiliki struktur yang rumit dan detail di bagian database dan program yang mengendalikan berbagai perhitungan dan kontrol, lebih dari apa yang dapat dilihat pengguna dari tampilan layar. Oleh karena itu, ada batasan pada apa yang dapat diperiksa dari pemeriksaan input dan output di layar dari perspektif pengguna. Oleh karena itu, tidak realistis untuk secara menyeluruh memverifikasi semua kemungkinan masalah yang dapat terjadi dalam fase operasional setelah pemeriksaan.

Situasi seperti di atas juga berlaku jika dilihat dari perspektif pihak vendor yang bertanggung jawab atas pengembangan. Misalnya, proses untuk memeriksa apakah ada bug atau masalah dalam konten program yang diimplementasikan adalah “tahap pengujian”. Namun, dalam tahap pengujian, tidak selalu mungkin untuk memverifikasi semua kemungkinan bug dan masalah. Bahkan setelah sistem yang dikembangkan mulai digunakan secara penuh dalam bisnis, masih memerlukan keahlian teknis yang luar biasa untuk membuat sistem yang dapat terus berfungsi tanpa hambatan, meski ada operasi yang tidak diantisipasi oleh pihak vendor, atau ketika banyak data mulai terdaftar, atau ketika banyak pengguna mulai mengakses secara bersamaan.

Anda harus memahami bahwa dalam tahap seperti penerimaan dan pengujian, tidak realistis untuk menemukan semua bug dan masalah, dan bahwa ada kemungkinan berbagai masalah muncul setelah mulai digunakan, yang merupakan karakteristik sistem IT.

Umumnya, Utang Itu Sendiri Dianggap Telah Dipenuhi

Lalu, bagaimana cara mengatasi masalah ini jika benar-benar terjadi? Mari kita uraikan berdasarkan urutan hukum.

Pertama, jika berbagai bug atau masalah ditemukan setelahnya, pengguna mungkin ingin menuntut tanggung jawab dari vendor yang telah mereka minta untuk melakukan pekerjaan hingga saat ini. Namun, biasanya, jika pengiriman sudah selesai dan telah lulus pemeriksaan, seringkali sulit untuk menuntut tanggung jawab berdasarkan pelanggaran kewajiban.

Pada dasarnya, kecuali ada perjanjian khusus, peraturan tentang implementasi program dalam kontrak pengembangan sistem adalah peraturan kontrak kerja dalam hukum sipil Jepang. Untuk penjelasan lebih lanjut tentang apa itu kontrak kerja, silakan lihat artikel berikut.

Dalam kontrak kerja, “penyelesaian pekerjaan” adalah syarat pemenuhan kewajiban. Untuk penjelasan lebih lanjut tentang apa yang dimaksud dengan “penyelesaian pekerjaan”, silakan lihat artikel berikut.

Di sini, kami menjelaskan bahwa dalam kasus hukum sebelumnya, “penyelesaian pekerjaan” dalam kontrak kerja, dalam konteks pengembangan sistem, berarti akhir dari semua proses pengembangan. Kami juga menjelaskan bahwa masalah bug atau masalah lainnya setelah semua proses pengembangan selesai adalah masalah tanggung jawab jaminan cacat dalam kontrak kerja.

Untuk merangkum, jika pengiriman telah diterima dan pemeriksaan telah lulus, biasanya, dengan asumsi bahwa kewajiban itu sendiri telah dipenuhi, masalah selanjutnya adalah masalah jaminan kualitas, yaitu, apakah tanggung jawab jaminan cacat dapat dituntut atau tidak.

Langkah-langkah Menuntut Tanggung Jawab Berdasarkan Tanggung Jawab Jaminan Cacat

Lalu, bagaimana urutan pertimbangan yang harus dilakukan jika Anda ingin meminta penanganan kepada vendor berdasarkan tanggung jawab jaminan cacat? Mari kita periksa bersama-sama di bawah ini.

Pertama, Periksa Tingkat Keparahan dan Seriusnya Bug atau Kerusakan

Ketika bug atau kerusakan terungkap setelahnya, dan itu merupakan “cacat” dalam hukum dan Anda mencari beberapa jaminan, tingkat keparahan bug atau kerusakan menjadi masalah. Masalah cacat hukum pada dasarnya dibagi menjadi tiga pola:

1. Meskipun itu bisa disebut bug atau kerusakan, itu hanya sepele dan tidak bisa disebut “cacat” dalam hukum
2. Itu sesuai dengan “cacat” dalam hukum, tetapi masih mungkin untuk mencapai tujuan kontrak
3. Itu sesuai dengan “cacat” dalam hukum, dan juga tidak mungkin untuk mencapai tujuan kontrak

Kemungkinan menuntut tanggung jawab berdasarkan tanggung jawab jaminan cacat dibagi oleh batas antara 1 dan 2, dan kemungkinan untuk membatalkan kontrak berdasarkan tanggung jawab jaminan cacat dibagi oleh batas antara 2 dan 3.

Pasal 634

1. Ketika ada cacat pada barang yang menjadi tujuan pekerjaan, pemesan dapat meminta kontraktor untuk memperbaiki cacat tersebut dalam jangka waktu yang wajar. Namun, ini tidak berlaku jika biaya untuk memperbaikinya berlebihan dan cacatnya tidak penting.

2. Pemesan dapat meminta ganti rugi sebagai pengganti atau bersamaan dengan perbaikan cacat. Dalam hal ini, ketentuan Pasal 533 diterapkan

Pasal 635

Ketika ada cacat pada barang yang menjadi tujuan pekerjaan dan karena itu tidak mungkin mencapai tujuan kontrak, pemesan dapat membatalkan kontrak. Namun, ini tidak berlaku untuk bangunan atau struktur tanah lainnya.

Untuk penjelasan lebih rinci tentang perbedaan tahap “cacat” ini, silakan lihat artikel di bawah ini.

https://monolith.law/corporate/defect-warranty-liability[ja]

Selanjutnya, Jelaskan Hal yang Harus Diminta kepada Vendor

Selanjutnya, Anda perlu menjelaskan apa yang harus Anda minta dari pihak lain. Jika Anda ingin membatalkan kontrak, tidak cukup hanya membuktikan bahwa itu adalah cacat, tetapi juga harus cukup serius untuk mengatakan bahwa “tidak mungkin mencapai tujuan kontrak”. Catatan rapat dan item yang tercantum dalam spesifikasi yang dilakukan pada awal proyek pengembangan sistem menjadi petunjuk penting dalam menentukan “tujuan” ini. Karena ada kemungkinan bug atau kerusakan akan terungkap setelah diterima, penting untuk menyimpan semua dokumen bahkan setelah proyek pengembangan selesai.

Selain pembatalan, hal yang dapat diminta sebagai isi tanggung jawab jaminan cacat termasuk permintaan ganti rugi dan permintaan perbaikan cacat.

Poin-Poin Lainnya

Perhatikan cara melakukan tindakan hukum seperti pembatalan kontrak

Jika Anda melakukan pembatalan kontrak sebagai bagian dari tanggung jawab jaminan cacat, Anda juga harus memahami cara melakukan prosedur administratif hukum untuk pembatalan. Efek pembatalan kontrak, cara melakukan pernyataan niat yang valid, dan cara memberikan pemberitahuan agar tidak menimbulkan masalah di kemudian hari, dijelaskan secara detail dalam artikel berikut.

Lebih baik menyelesaikan melalui negosiasi daripada perselisihan

Argumen hukum ini tidak hanya berarti ketika ada pengadilan. Penyelesaian perselisihan melalui pengadilan sangat memberatkan bagi kedua belah pihak. Sebaliknya, pengetahuan ini sangat berguna bahkan pada tahap negosiasi sebelum pengadilan. Artikel berikut menjelaskan bagaimana pengetahuan hukum ini sangat berarti dalam negosiasi selain pengadilan.

Harus membedakan antara bug dan kekurangan fungsi

Ada perbedaan dalam diskusi jika ada bug atau masalah dalam fungsi atau spesifikasi yang telah diimplementasikan, dan jika fungsi yang diperlukan tidak ada sama sekali. Jika fungsi yang diperlukan tidak ada, “penyelesaian pekerjaan” dalam kontrak kerja mungkin tidak diakui, dan pelaksanaan kewajiban mungkin tidak diakui.

Di sisi lain, meskipun fungsi atau spesifikasi yang diperlukan tidak disediakan, jika hasilnya adalah karena pengguna tidak memberikan informasi yang tepat pada tahap definisi persyaratan, mungkin tidak tepat untuk menganggapnya sebagai bagian dari isi kontrak.

Kesimpulan

Masalah yang muncul dalam proses proyek dapat terungkap selama proyek berlangsung atau bahkan setelahnya, seperti pada tahap operasional. Karakteristik proyek pengembangan sistem yang tidak selalu dapat memberikan rasa aman meskipun semua proses telah selesai, tampaknya diwakili oleh sistem yang disebut ‘Tanggung Jawab Jaminan Cacat’ (Japanese ~ ‘瑕疵担保責任’). Penting untuk memahami alur kerja ini sambil memastikan manajemen dokumen yang menyeluruh dengan mempertimbangkan hal-hal setelah penyelesaian proyek pengembangan sistem.