Apa Itu Hukum yang Berhubungan dengan 'Kegagalan' Proyek Pengembangan Sistem

Proyek pengembangan sistem bukanlah sesuatu yang dapat dicapai dalam sekejap, melainkan membutuhkan banyak sumber daya seperti sejumlah besar individu dan organisasi, dana yang sangat besar, dan periode pengembangan yang panjang. Dalam artikel ini, kami akan menjelaskan bagaimana fenomena ‘kebakaran’ dalam proyek pengembangan sistem dapat diatur dalam kerangka hukum, dan merangkum pedoman untuk solusi.

Mengapa Proyek Sering ‘Gagal’

Satu sistem IT, meskipun bukan proyek skala besar, hanya dapat berfungsi dengan benar jika ada penumpukan file program dan kode sumber yang dibuat dalam jumlah besar. Dari perspektif operasional layar, seringkali sulit dibayangkan (atau lebih tepatnya, semakin sederhana dan ringkas operasional layar pada sistem IT, semakin sering) bahwa sistem tersebut dibuat dengan detail dan presisi yang tinggi.

• Deadline sudah ditentukan terlebih dahulu, sementara spesifikasi dan persyaratan masih samar-samar dan waktu terus berlalu
• Anggota terlalu terfokus pada masalah politik internal perusahaan, banyak anggota yang putus asa dan keluar di tengah jalan karena stres hubungan interpersonal
• Ada kekurangan kemampuan negosiasi di tingkat manajemen, termasuk PM, dan anggota tidak diminta untuk melaporkan, berkomunikasi, dan berkonsultasi dengan tepat

Alasan kegagalan proyek mungkin berbeda-beda untuk setiap proyek. Namun, dari perspektif hukum, alasan kegagalan proyek dapat disederhanakan menjadi beberapa tipe umum.

Jenis Kebakaran 1: Ketika Proyek Terhenti di Tengah Jalan

Salah satu alasan umum mengapa proyek pengembangan sistem terhenti di tengah jalan adalah kegagalan komunikasi antara pihak pengguna dan pihak vendor. Sebuah proyek pengembangan sistem pada dasarnya membutuhkan keahlian teknis dan organisasional dari pihak vendor, tetapi juga membutuhkan kerjasama dari pihak pengguna yang akan menggunakan sistem tersebut.

Oleh karena itu, jika peran masing-masing pihak dalam proyek tidak jelas dan proyek berjalan dengan asumsi tersebut, hal ini dapat menghambat kelancaran proyek dan menciptakan situasi di mana tugas-tugas dipertukarkan. Untuk penjelasan hukum lebih lanjut tentang kewajiban pihak pengguna dan pihak vendor, silakan merujuk ke artikel berikut.

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

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

Untuk detail tentang tanggung jawab yang harus diambil oleh masing-masing pihak, silakan merujuk ke artikel di atas. Inti dari pembahasan di sini adalah bahwa dalam satu proyek pengembangan sistem, baik pengguna maupun vendor memiliki tanggung jawab tertentu. Secara umum, pengguna bertanggung jawab atas definisi kebutuhan, desain tampilan (yaitu, desain dasar), dan penerimaan, dan hukum dan preseden sebelumnya telah mengakui kewajiban kerjasama pengguna dalam hal-hal ini.

Di sisi lain, vendor juga memiliki kewajiban komprehensif untuk memastikan kelancaran proyek dan mengidentifikasi dan menghilangkan hambatan, setelah menerima kerjasama pengguna dalam hal-hal di atas (dan pada saat yang sama, melakukan upaya komunikasi untuk meminta kerjasama tersebut).

Dengan pemikiran ini, pengadilan telah menunjukkan sikap untuk menangani semua konflik secara adil, dengan menunjukkan kewajiban pengguna untuk menerapkan tata kelola dari dalam sebagai sistem internal, dan kewajiban vendor untuk menunjukkan keahlian dan kemampuan teknis sebagai ahli eksternal dan bekerja dalam bisnis tersebut.

Keadaan di mana “kegagalan” ini cenderung terjadi adalah saat penerimaan. Untuk penjelasan lebih rinci tentang penerimaan, silakan merujuk ke artikel berikut.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Dalam kasus seperti ini, jika konflik terjadi, bukti yang dapat diverifikasi secara objektif, seperti perkembangan proyek sebelumnya dan isi pertemuan, sering kali menjadi penting. Oleh karena itu, dokumen yang telah direkam sebelumnya sering kali memiliki arti yang besar. Untuk tidak merugikan posisi Anda sendiri, penting untuk mengelola dokumen dengan cermat. Untuk penjelasan lebih rinci tentang pentingnya manajemen dokumen dalam pengembangan sistem, silakan merujuk ke artikel berikut.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Tipe Kebakaran 2: Kasus Pembatalan karena Alasan Pribadi Pengguna

Ada kemungkinan juga bahwa proyek dapat dihentikan di tengah jalan atas permintaan pengguna. Misalnya, perusahaan mulai membuat sistem IT untuk mengelola sumber daya manusia secara keseluruhan, termasuk kantor cabang di luar negeri, tetapi strategi ekspansi ke luar negeri itu sendiri ditarik kembali. Dalam kasus seperti itu, pengembangan sistem yang baru dimulai mungkin sudah tidak lagi diperlukan oleh pengguna.

Pertanyaan tentang bagaimana sistem IT yang digunakan di perusahaan harus dibangun, pada dasarnya tidak dapat dipisahkan dari pertanyaan tentang jenis pekerjaan apa yang ada di perusahaan tersebut. Oleh karena itu, sangat mungkin bahwa persyaratan sistem yang diperlukan (atau tidak diperlukan) berubah setelahnya, dipengaruhi oleh perubahan besar dalam struktur organisasi, reorganisasi departemen bisnis, atau revisi fundamental strategi.

Sebagai akibat dari situasi seperti ini, berbagai masalah hukum dapat muncul jika proyek dihentikan di tengah jalan. Dalam kasus seperti itu, biasanya, karena ini adalah alasan pribadi pengguna, vendor juga diberikan beberapa hak hukum, seperti permintaan pembayaran berdasarkan persentase penyelesaian. Meskipun ada perbedaan dalam pasal yang menjadi dasar tergantung pada jenis kontrak yang diadopsi, isi dari hal tersebut dapat diorganisir sebagai berikut:

・Dalam kasus kontrak kerja: Pasal 641 Hukum Sipil Jepang
Pasal 641 Hukum Sipil Jepang
→Selama pekerjaan belum selesai, pemesan dapat membatalkan kontrak kapan saja dengan membayar ganti rugi.
・Dalam kasus kontrak kuasa: Pasal 648 ayat 3 Hukum Sipil Jepang (tergantung pada situasi, permintaan ganti rugi berdasarkan Pasal 651 juga mungkin)
Pasal 648 Hukum Sipil Jepang
→Jika kuasa berakhir di tengah pelaksanaan karena alasan yang tidak dapat diatribusikan kepada penerima kuasa, penerima kuasa dapat meminta pembayaran berdasarkan persentase pelaksanaan yang telah dilakukan.
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 membayar ganti rugi kepada pihak lain. Namun, ini tidak berlaku jika ada alasan yang tidak dapat dihindari.

Tipe Kebakaran 3: Ketika Ketidaksempurnaan Sistem yang Dikirim Terungkap Kemudian

Sebagian besar pengguna memahami kualitas sistem dari perasaan operasional di sisi layar, tetapi dari sudut pandang penerima pekerjaan, yang lebih rumit adalah desain basis data, dan mengidentifikasi item tes dengan mempertimbangkan semua metode operasi.

Dengan kata lain, meskipun sistem tampak berfungsi dengan baik pada awal penggunaan,

• Seiring bertambahnya jumlah data yang terdaftar, kecepatan pemrosesan mulai melambat
• Sistem yang tampaknya berfungsi dengan baik dalam operasi bisnis sehari-hari juga, bug muncul dalam operasi khusus yang terjadi beberapa bulan atau beberapa tahun sekali
• Meskipun tampaknya hasil yang benar sedang diproduksi di permukaan, logika sebenarnya mungkin salah (Sebagai contoh yang akrab, meskipun “2” diproduksi dengan benar untuk input “1 + 1” dari pengguna, itu tidak berarti bahwa proses perhitungan dilakukan dengan benar. Kesalahan logika sering tidak dapat ditemukan hanya dengan mengoperasikan layar tanpa berpikir. Dalam proses pengujian ini, dapat dikatakan bahwa “kemampuan teknis” tertentu diperlukan.)

Hal-hal seperti ini benar-benar bisa terjadi. Jika Anda menganalisis kasus seperti ini dari sudut pandang hukum, ada kemungkinan bahwa ini bisa menjadi masalah pelanggaran kewajiban manajemen proyek dari pihak vendor, yaitu masalah pelaksanaan yang tidak lengkap dalam hukum sipil.

Dalam hal ini, jika tidak ada aturan khusus dalam kontrak, biasanya akan berlaku ketentuan tentang kontrak pekerjaan.

Poin yang harus dipertimbangkan dalam hal ini diatur sebagai berikut.

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

Hal-hal tersebut diatur seperti di atas.

Ringkasan

Setiap proyek pengembangan sistem pasti akan melalui berbagai rintangan dan tantangan yang beragam. Namun, jika berbicara tentang ‘kegagalan’ proyek dalam konteks hukum, kerangka kerja yang telah kami sampaikan dalam artikel ini dapat menjadi panduan. Memang, masalah hukum yang terkait dengan pengembangan sistem mencakup berbagai tema yang sangat beragam.

Namun, sama seperti pekerjaan pengembangan sistem yang membutuhkan pemikiran konstruktif, manajemen risiko yang terkait dengan itu juga dapat dilakukan secara lebih konstruktif jika kita tidak kehilangan gambaran keseluruhan dari bidang tersebut. Bukan begitu?