Apa itu Undang-Undang yang Berkaitan dengan 'Kegagalan' dalam Projek Pembangunan Sistem

Projek pembangunan sistem bukanlah sesuatu yang dapat dicapai dalam sekelip mata, tetapi memerlukan pelaburan sumber yang banyak seperti bilangan orang dan organisasi yang ramai, dana yang besar, dan tempoh pembangunan yang panjang. Dalam artikel ini, kami akan menjelaskan bagaimana fenomena ‘kebakaran’ dalam projek pembangunan sistem dapat diatur dalam kerangka hukum, dan kami akan merangkum garis panduan untuk penyelesaian.

Mengapa Projek ‘Terbakar’

Satu sistem IT, walaupun bukan projek berskala besar, hanya akan berfungsi dengan betul apabila terdapat penumpukan fail program dan kod sumber yang banyak. Dari segi operasi yang dilihat dari skrin, ia seringkali jauh lebih rumit daripada yang dapat kita bayangkan (atau sebaliknya, sistem IT yang operasinya tampak sederhana dan ringkas dari skrin), dan seringkali dibuat dengan teliti dan rapi.

• Tempoh penyerahan sahaja yang telah ditentukan terlebih dahulu, manakala spesifikasi dan keperluan masih kabur walaupun masa telah berlalu
• Ahli pasukan terlalu terfokus pada isu politik dalam syarikat, dan banyak ahli yang menarik diri di tengah jalan disebabkan tekanan hubungan antara manusia
• Ada kekurangan kemampuan rundingan di kalangan lapisan pengurusan termasuk PM, dan ahli pasukan tidak diminta untuk membuat laporan, komunikasi, dan rundingan yang sesuai

Sebagai contoh, sebab-sebab spesifik mengapa projek ‘terbakar’ mungkin berbeza-beza mengikut projek. Namun, dari segi undang-undang, sebab-sebab projek ‘terbakar’ boleh disusun dengan relatif mudah mengikut beberapa jenis yang berbeza.

Jenis Kebakaran 1: Projek Terhenti di Pertengahan Jalan

Sebagai contoh tipikal sebab projek pembangunan sistem terhenti di tengah jalan, kita boleh sebutkan kegagalan komunikasi antara pihak pengguna dan pihak vendor. Projek pembangunan sistem pada dasarnya memerlukan bukan sahaja kekuatan teknikal dan organisasi yang dimiliki oleh pihak vendor, tetapi juga kerjasama dari pihak pengguna yang akan menggunakan sistem tersebut pada akhirnya.

Oleh itu, jika projek berjalan dengan peranan masing-masing tidak jelas, dan jika terjadi sesuatu seperti ‘pertukaran tugas’ antara kedua-dua pihak, kemajuan projek akan terganggu. Untuk pertimbangan undang-undang mengenai tanggungjawab pihak pengguna dan pihak vendor, sila rujuk artikel di bawah.

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

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

Untuk keterangan lanjut mengenai tanggungjawab yang perlu dipikul oleh masing-masing, sila rujuk artikel di atas. Intipati perbincangan di sini adalah bahawa dalam satu projek pembangunan sistem, pengguna dan vendor masing-masing mempunyai tanggungjawab tertentu. Secara kasar, pengadilan dan preseden masa lalu telah mengakui kewajipan kerjasama pengguna dalam hal-hal seperti definisi keperluan, reka bentuk luaran seperti skrin (iaitu reka bentuk asas), dan penerimaan yang tidak dapat diselesaikan tanpa kerjasama pengguna.

Di sisi lain, pihak vendor juga mempunyai tanggungjawab menyeluruh untuk memastikan kemajuan lancar projek dan penemuan dan penyingkiran faktor penghalang, setelah menerima kerjasama dari pihak pengguna seperti yang disebutkan di atas (dan pada masa yang sama, melakukan usaha komunikasi untuk meminta kerjasama tersebut).

Berdasarkan pemikiran ini, pengadilan telah menunjukkan sikap untuk menangani semua konflik secara adil, dengan menunjukkan kewajipan pengguna untuk mengawal tadbir urus dari dalam sebagai sistem dalaman, dan kewajipan vendor untuk menunjukkan kepakaran dan kekuatan teknikal sebagai pakar luaran dan menjalankan tugas mereka.

Tempat di mana ‘kegagalan’ ini cenderung berlaku adalah semasa penerimaan. Untuk penjelasan lebih lanjut mengenai penerimaan, sila rujuk artikel di bawah.

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

Dalam kes seperti ini, sekiranya berlaku konflik, bukti yang dapat disahkan secara objektif seperti perubahan projek masa lalu dan kandungan perbincangan mesyuarat akan diberi penekanan. Oleh itu, dokumen yang telah direkodkan sebelumnya sering mempunyai makna yang besar. Untuk tidak merugikan kedudukan anda sendiri, penting untuk mengurus dokumen dengan teliti. Untuk penjelasan lebih lanjut mengenai kepentingan pengurusan dokumen dalam pembangunan sistem, sila rujuk artikel di bawah.

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

Jenis Kebakaran 2: Apabila Pengguna Membatalkan Atas Sebab Sendiri

Kita juga perlu mempertimbangkan situasi di mana projek dihentikan atas permintaan pengguna di tengah jalan. Sebagai contoh, anggaplah syarikat telah memulakan pembinaan sistem IT untuk menguruskan sumber manusia secara keseluruhan, termasuk cawangan luar negara, tetapi strategi pengembangan pasaran melalui penubuhan cawangan luar negara telah ditarik balik. Dalam situasi seperti ini, pembangunan sistem yang baru sahaja dimulakan mungkin tidak lagi diperlukan oleh pengguna.

Pada asasnya, soalan tentang bagaimana sistem IT yang digunakan dalam syarikat harus dibina tidak dapat dipisahkan dari soalan tentang jenis perniagaan apa yang ada dalam syarikat tersebut. Oleh itu, adalah mungkin bahawa keperluan sistem (atau ketiadaan keperluan) berubah selepas perubahan besar dalam struktur organisasi, pengorganisasian bahagian perniagaan, atau semakan semula strategi secara menyeluruh.

Apabila projek dihentikan di tengah jalan kerana sebab-sebab seperti ini, pelbagai isu undang-undang mungkin timbul. Dalam kes seperti ini, biasanya, kerana ini adalah atas sebab sendiri pengguna, hak-hak undang-undang tertentu seperti permintaan bayaran berdasarkan peratusan penyelesaian mungkin diakui kepada pihak vendor. Walaupun terdapat perbezaan dalam peruntukan yang menjadi asas bergantung pada jenis kontrak yang diambil, kandungannya boleh disusun seperti berikut:

・Dalam kes kontrak kerja: Artikel 641 Undang-Undang Sivil Jepun (Japanese Civil Code)
Artikel 641 Undang-Undang Sivil Jepun (Japanese Civil Code)
→Selagi pekerjaan tidak selesai, pemesan boleh membatalkan kontrak pada bila-bila masa dengan membayar ganti rugi.
・Dalam kes kontrak kuasa: Artikel 648(3) Undang-Undang Sivil Jepun (Japanese Civil Code) (bergantung pada keadaan, permintaan ganti rugi berdasarkan Artikel 651 juga mungkin)
Artikel 648 Undang-Undang Sivil Jepun (Japanese Civil Code)
→Apabila pelaksanaan dihentikan di tengah jalan kerana sebab yang tidak dapat dikaitkan dengan penerima kuasa, penerima kuasa boleh meminta bayaran berdasarkan peratusan pelaksanaan yang telah dilakukan.
Artikel 651 Undang-Undang Sivil Jepun (Japanese Civil Code)
→1. Kuasa boleh dibatalkan oleh mana-mana pihak pada bila-bila masa.
→2. Jika salah satu pihak membatalkan kuasa pada masa yang merugikan pihak lain, pihak tersebut harus membayar ganti rugi kepada pihak lain. Walau bagaimanapun, ini tidak berlaku jika ada sebab yang tidak dapat dielakkan.

Jenis Kebakaran 3: Apabila Kekurangan Sistem yang Dihantar Ditemui Kemudian

Pihak pengguna biasanya memahami kualiti sistem melalui pengalaman operasi pada skrin, tetapi dari sudut pandang pihak yang menerima kerja, yang lebih rumit adalah reka bentuk pangkalan data, dan mengenal pasti item ujian dengan mempertimbangkan semua kaedah operasi.

Dengan kata lain, walaupun sistem tampak berfungsi dengan baik pada awal penggunaan, masalah seperti:

• Kecepatan pemprosesan menjadi perlahan seiring dengan peningkatan jumlah data yang didaftarkan
• Walaupun sistem tampak berfungsi dengan baik dalam operasi asas harian, bug mungkin timbul dalam operasi khusus yang berlaku beberapa bulan atau beberapa tahun sekali
• Walaupun hasil keluaran tampaknya dilakukan dengan betul pada permukaan, logik sebenarnya mungkin tidak betul (Sebagai contoh yang mudah, walaupun “2” keluar dengan betul untuk input “1+1” dari pengguna, ini tidak semestinya berarti bahawa proses pengiraan dilakukan dengan betul. Kesalahan logik seperti ini sering tidak dapat ditemui hanya dengan operasi skrin secara acuh tak acuh. Dalam proses ujian ini juga, boleh dikatakan bahawa “keupayaan teknikal” tertentu diperlukan.)

Boleh berlaku dalam realiti. Jika kita menganalisis kes-kes seperti ini dari sudut pandangan undang-undang, kemungkinannya adalah pelanggaran kewajipan pengurusan projek pihak vendor, atau dengan kata lain, masalah pelaksanaan tidak lengkap di bawah undang-undang sivil.

Dalam kes ini, jika tidak ada peraturan khusus dalam kontrak, peraturan biasa mengenai kontrak akan berlaku.

Poin yang perlu dipertimbangkan dalam kes ini adalah seperti berikut:

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

Boleh disusun seperti ini.

Rumusan

Setiap projek pembangunan sistem akan melalui pelbagai cabaran dan perubahan. Namun, apabila berbicara tentang ‘kegagalan’ projek dari segi undang-undang, kerangka yang telah kami huraikan dalam artikel ini boleh menjadi panduan. Memang benar bahawa isu-isu undang-undang yang berkaitan dengan pembangunan sistem melibatkan pelbagai tema.

Sama seperti bagaimana tugas pembangunan sistem memerlukan pemikiran yang konstruktif, pengurusan risiko yang berkaitan dengannya juga dapat dilakukan dengan lebih konstruktif jika kita tidak kehilangan gambaran keseluruhan bidang ini.