Apa itu Tanggungjawab Kerjasama yang Harus Dipikul oleh Pengguna sebagai Pemberi Perintah Pembangunan Sistem

Pekerjaan pembangunan sistem memerlukan banyak tenaga kerja dan waktu, terutamanya jika sistem yang dibangunkan adalah berskala besar. Oleh itu, bukan sahaja pihak vendor yang bertanggungjawab untuk pembangunan, tetapi juga pihak pengguna yang memesan pembangunan sistem mempunyai tanggungjawab untuk bekerjasama.

Ini adalah sesuatu yang berbeza daripada hubungan pesanan biasa. Sebagai contoh, jika anda memesan baju buatan khusus dari penjahit, pihak pelanggan (pengguna) tidak mempunyai ‘tanggungjawab’ tertentu. ‘Tanggungjawab’ terletak pada pihak penjahit (vendor). Struktur ini menunjukkan bahawa pengguna juga perlu ‘bekerjasama’ dengan vendor kerana sistem IT memerlukan banyak tenaga kerja dan waktu.

Dalam artikel ini, kami akan menjelaskan tentang tanggungjawab undang-undang yang ada pada pihak pengguna dalam pembangunan sistem yang tidak boleh diserahkan sepenuhnya kepada vendor.

Sebagai sistem syarikat sendiri, segalanya tidak boleh diselesaikan hanya dengan ‘menyerahkan sepenuhnya’

Walaupun hanya satu projek pembangunan sistem, seringkali terdapat banyak individu dan organisasi yang terlibat. Selain daripada jurutera dan pengaturcara yang mahir dalam teknologi kod, peranan pengurus projek juga penting untuk menggabungkan hasil kerja semua individu ini menjadi satu hasil yang berjaya.

Namun, walaupun pihak vendor memiliki keupayaan teknikal dan organisasi yang tinggi, pembangunan sistem tidak boleh dilakukan hanya dengan kekuatan vendor sahaja. Misalnya, istilah-istilah khusus yang digunakan hanya dalam syarikat itu atau pengetahuan kerja khusus syarikat itu tidak dapat diketahui hanya dengan usaha sepihak dari pihak vendor. Semakin besar skala pembangunan sistem, semakin biasa bagi syarikat yang menggunakan sistem tersebut untuk menjadi syarikat besar yang memiliki banyak individu dan tugas. Untuk membawa kejayaan projek pembangunan sistem, sebenarnya, pengaturan logik perniagaan ini seringkali memegang berat yang besar sebelum kerja komputer.

Oleh itu, bukan sahaja pihak pengguna menjadi pasif dengan alasan “saya bukan pakar teknologi IT”, sebaliknya, dengan memberikan maklumat secara proaktif, projek dapat berjalan dengan lancar. Dalam konteks ini, peranan yang dimainkan oleh pihak pengguna dalam projek pembangunan sistem sebenarnya bukanlah sesuatu yang kecil.

Apa itu Tanggungjawab Kerjasama dari Pihak Pengguna Berdasarkan Kes-kes Sebelumnya

Jadi secara spesifik, dalam projek pembangunan sistem, apa sebenarnya tanggungjawab kerjasama yang dipegang oleh pihak pengguna? Banyak petunjuk tentang hal ini telah ditinggalkan dalam kes-kes sebelumnya.

Dalam perbicaraan, isu tentang adanya tanggungjawab kerjasama pengguna terhadap pembangunan telah menjadi titik perdebatan, berdasarkan keterlambatan dalam pengambilan keputusan pengguna (plaintif) dalam hal keterlambatan pengiriman oleh pihak vendor (defendan). Dalam hal ini, mahkamah mengakui pelanggaran tanggungjawab kerjasama oleh pihak pengguna dan menolak tanggungjawab vendor atas kegagalan dalam melaksanakan tanggungjawabnya. (Walaupun pembatalan kontrak diakui, namun juga diakui adanya penyeimbangan kesalahan sebanyak 60%.)

Kontrak pembangunan sistem komputer dalam kes ini adalah kontrak pembangunan sistem yang dibuat khusus, di mana dalam kontrak pembangunan sistem yang dibuat khusus ini, tidak mungkin bagi penerima kontrak (vendor) untuk menyelesaikan sistem sendirian, dan pemberi kontrak (pengguna) perlu berperan dalam proses pembangunan, dengan melakukan koordinasi pendapat internal secara tepat, menyatukan pandangan, menyampaikan dengan jelas kepada penerima kontrak tentang fungsi apa yang diinginkan, bersama-sama dengan penerima kontrak, membahas tentang fungsi yang diinginkan, akhirnya menentukan fungsi, dan selanjutnya, menentukan skrin dan dokumen, menerima hasil kerja dan sebagainya.

Keputusan Mahkamah Tokyo, 10 Mac 2004 (Tahun 16 Era Heisei)

Keputusan ini, selain menunjukkan bahwa pembangunan sistem itu sendiri adalah kerjasama dengan pihak pengguna, juga memberikan petunjuk yang sangat berharga tentang “pada titik mana harus bekerjasama secara spesifik”.

Mari kita cuba menterjemahkan kata-kata dalam keputusan ini ke dalam istilah IT pembangunan sistem.

Kita boleh mengatur seperti di atas. Semua ini, tidak kira seberapa tinggi keahlian dalam sistem IT, tidak dapat dilakukan sendirian tanpa kerjasama pengguna. Fungsi yang diinginkan dan reka bentuk skrin adalah sesuatu yang harus diperjelaskan oleh pengguna, dan hanya pengguna yang dapat memeriksa apakah hasilnya telah direalisasikan seperti yang diinginkan.

Selain itu, sama seperti tanggungjawab pengurusan projek yang dikenakan kepada vendor, kerana tanggungjawab kerjasama juga dikenakan kepada pengguna, jika pengguna melanggar tanggungjawab kerjasama dalam proses seperti di atas, vendor mungkin mengajukan tuntutan ganti rugi berdasarkan kegagalan dalam melaksanakan tanggungjawab atau tindakan haram terhadap pengguna.

Bagaimanakah Permintaan Ubah Spesifikasi Selepas Projek Ditafsirkan?

Jika kita menganggap bahawa projek pembangunan sistem adalah kerjasama antara pengguna dan vendor, perbincangan akan berkembang ke arah yang lebih maju. Iaitu, “Siapakah yang bertanggungjawab jika pengguna meminta penambahan atau pengubahsuaian fungsi selepas projek dan ini menyebabkan kesukaran dalam memenuhi tarikh penyerahan?”

Pembangunan sistem biasanya bermula dengan definisi keperluan, diikuti oleh reka bentuk asas, reka bentuk terperinci, pembuatan (implementasi program), dan ujian, dengan tujuan untuk mengelakkan sebarang kembali ke belakang sebanyak mungkin (biasanya dikenali sebagai model air terjun). Namun, dalam kenyataan, jika terdapat kekurangan dalam proses sebelumnya, ia seringkali menyebabkan kembali ke belakang dalam proses.

Bagaimana kita harus memikirkan jika kita tidak dapat memenuhi tarikh penyerahan dalam kes seperti ini? Dari membaca kes-kes sebelumnya, kesimpulannya mungkin berbeza bergantung pada bila kerja tambahan berlaku.

Jika Kerja Tambahan Berlaku Sebelum Penjelasan Spesifikasi Seperti Reka Bentuk Luar

Kes yang disebutkan sebelum ini menunjukkan bahawa permintaan untuk pembangunan tambahan dari pengguna semasa reka bentuk asas (sebelum tahap implementasi program) tidak melanggar kewajipan kerjasama.

Adalah perkara biasa bagi pengguna untuk membuat pelbagai permintaan kepada vendor mengenai sistem yang akan dibina semasa proses reka bentuk asas, dan bahkan, adalah sukar bagi pengguna tanpa pengetahuan pakar untuk menentukan sama ada permintaan tersebut memerlukan bayaran tambahan atau penundaan tarikh penyerahan, atau sama ada ia akan mengganggu proses kerja. Oleh itu, tidak dapat dikatakan bahawa pengguna harus menahan diri dari membuat permintaan yang akan membawa kepada bayaran tambahan atau penundaan tarikh penyerahan. Sebaliknya, jika pengguna membuat permintaan yang memerlukan bayaran tambahan atau penundaan tarikh penyerahan, vendor yang mempunyai kewajipan pengurusan projek harus memberitahu pengguna tentang hal ini, meminta perbincangan tentang penarikan balik permintaan atau penundaan tarikh penyerahan, dan sebagainya, dan memastikan bahawa kerja pembangunan tidak terganggu.

Keputusan Mahkamah Tokyo, 10 Mac 2004 (2004)

Keputusan ini menunjukkan bahawa walaupun pengguna mempunyai kewajipan kerjasama tertentu, pengguna bukanlah pakar dalam pembangunan sistem dan harus mempertimbangkan hal ini. Dengan kata lain, pengguna yang membuat pesanan mungkin bukan pakar dalam pembangunan sistem, dan sebelum kandungan sistem yang akan dibangunkan menjadi jelas, mereka mungkin membuat pesanan secara berasingan dan berulang kali (mungkin mereka tidak biasa membuat pesanan), dan bahawa adalah tidak adil untuk mengatakan bahawa mereka harus menyedari sendiri bahawa kandungan pesanan tersebut memerlukan semakan tarikh penyerahan dan sebagainya.

Walau bagaimanapun, kewajipan yang dikenakan kepada vendor di sini pada dasarnya merujuk kepada usaha komunikasi seperti meminta penundaan tarikh penyerahan (atau, jika tarikh penyerahan tidak dapat dipindahkan, mencadangkan bahawa permintaan tambahan itu sendiri ditarik balik). Oleh itu, ia tidak bermaksud bahawa ia termasuk kewajipan untuk menerima semua permintaan dari pengguna dan menyerahkan semuanya pada tarikh asal, jadi perlu berhati-hati tentang perkara ini.

Jika Kerja Tambahan Berlaku Selepas Penentuan Spesifikasi dalam Proses Pembuatan atau Ujian

Jika kita membalikkan kandungan keputusan di atas, kita dapat meramalkan apa yang akan berlaku jika ada pembangunan tambahan selepas spesifikasi telah ditentukan. Dalam kes ini, permintaan tersebut mungkin sukar untuk diterima. Memang benar bahawa tidak ada perbezaan dalam tahap pemahaman tentang kerja pembangunan antara pengguna dan vendor, sama ada sebelum atau selepas penentuan spesifikasi.

Namun, mengubah atau menambah kandungan pesanan selepas penentuan spesifikasi mungkin akan memaksa kerja untuk diulang. Dalam kebanyakan kes, adalah sukar untuk mempertahankan bahawa “adalah wajar untuk membuat pelbagai permintaan kerana mereka adalah pelanggan” jika penundaan tarikh penyerahan berlaku dalam situasi seperti ini. Selain itu, jika banyak perubahan spesifikasi dan penambahan fungsi berlaku selepas fakta, ini mungkin menimbulkan pertanyaan tentang sama ada ada pelanggaran kewajipan kerjasama dari pihak pengguna dalam proses hulu seperti reka bentuk asas yang sepatutnya telah selesai sebelumnya.

Dari sudut pandang ini, adalah tidak realistik untuk menganggap penundaan tarikh penyerahan yang disebabkan oleh perubahan spesifikasi yang dibuat selepas penentuan spesifikasi sebagai tanggungjawab vendor. Dari teks keputusan yang disebutkan sebelum ini, adalah wajar untuk membaca makna ini pada masa yang sama.

Selain itu, keputusan seperti ini cenderung dibuat berdasarkan bukti seperti minit mesyuarat yang disesuaikan dengan kemajuan pembangunan sistem, bukan hanya kontrak. Untuk maklumat lanjut tentang minit mesyuarat, sila lihat artikel di bawah ini.

Artikel Berkaitan: Cara Menyimpan Minit Mesyuarat dalam Pembangunan Sistem dari Perspektif Undang-Undang

Rumusan: Penting untuk tidak lupa bahawa definisi keperluan adalah proses dari pihak pengguna

Definisi keperluan adalah tempat di mana kemahiran pihak vendor ditunjukkan, tetapi pada dasarnya, kita harus menyedari bahawa ia adalah proses kerja dari pihak pengguna. Selagi ia adalah sistem yang digunakan oleh syarikat kita, walaupun kita menggunakan kekuatan pakar luar untuk membina sistem tersebut, ia dianggap sebagai bidang yang sepatutnya dikuasai oleh tadbir urus syarikat kita dari segi undang-undang.

Jika pihak pengguna tidak bekerjasama dalam proses pembangunan, kita harus pertama-tama menyedari bahawa ada kemungkinan besar mahkamah akan menunjukkan pandangan yang keras terhadap pihak pengguna, walaupun projek tersebut gagal.