Apa Itu Kewajiban Kerjasama yang Harus Dipenuhi oleh Pengguna sebagai Pemesan Pengembangan Sistem

Pekerjaan pengembangan sistem, semakin besar sistem yang dikembangkan, semakin banyak tenaga dan waktu yang diperlukan. Oleh karena itu, bukan hanya pihak vendor yang menerima pengembangan, tetapi juga pihak pengguna yang memesan pengembangan sistem memiliki kewajiban kerjasama tertentu.

Ini berbeda dari hubungan pemesanan dan penerimaan biasa. Misalnya, jika Anda meminta penjahit untuk membuat setelan jas pesanan khusus bukan sistem IT, pihak pelanggan (pengguna) yang memesan tidak memiliki “kewajiban” khusus. “Kewajiban” terutama ada pada pihak penjahit (vendor). Struktur ini menunjukkan bahwa karena sistem IT membutuhkan banyak tenaga dan waktu, pengguna juga perlu “bekerja sama” dengan vendor.

Artikel ini menjelaskan tentang kewajiban hukum apa yang ada pada pihak pemesan dalam pengembangan sistem yang tidak bisa hanya diserahkan kepada vendor.

Sebagai sistem internal perusahaan, tidak bisa semuanya ‘diserahkan begitu saja’

Meskipun hanya satu proyek pengembangan sistem, seringkali banyak individu dan organisasi yang terlibat di dalamnya. Tentu saja, peran insinyur dan programmer yang mahir dalam teknik pemrograman sangat penting, tetapi untuk menggabungkan output dari semua personel ini menjadi satu hasil yang berarti, peran manajer proyek juga sangat penting.

Namun, tidak peduli seberapa tinggi keahlian teknis dan organisasi dari pihak vendor, pengembangan sistem tidak bisa diselesaikan hanya dengan kekuatan vendor saja. Misalnya, istilah-istilah internal yang hanya digunakan di dalam perusahaan dan pengetahuan bisnis yang unik untuk perusahaan tersebut, tidak bisa diketahui hanya dengan upaya sepihak dari pihak vendor. Semakin besar sistem yang dikembangkan, semakin umum bagi perusahaan yang akan menggunakan sistem tersebut untuk menjadi perusahaan besar yang memiliki banyak karyawan dan operasi. Untuk membawa proyek pengembangan sistem ke kesuksesan, sebenarnya seringkali penataan logika bisnis ini yang memiliki bobot besar, bahkan sebelum pekerjaan komputer.

Oleh karena itu, bukan hanya menjadi pasif dengan alasan “Saya bukan ahli teknologi IT”, pihak pengguna sebenarnya dapat memperlancar jalannya proyek dengan memberikan informasi secara proaktif. Dalam hal ini, peran yang dimainkan oleh pihak pengguna dalam proyek pengembangan sistem sebenarnya bukanlah hal yang kecil.

Kewajiban Kerjasama dari Sisi Pengguna Berdasarkan Putusan Pengadilan

Lalu secara spesifik, apa sebenarnya kewajiban kerjasama yang harus dipenuhi oleh pengguna dalam proyek pengembangan sistem? Banyak petunjuk yang bisa kita dapatkan dari putusan pengadilan sebelumnya.

Dalam pengadilan, dalam kasus di mana vendor (terdakwa) terlambat dalam penyerahan, apakah ada kewajiban kerjasama dari pengguna (penggugat) dalam pengembangan menjadi titik perdebatan, mengingat adanya keterlambatan dalam pengambilan keputusan oleh pengguna. Dalam hal ini, pengadilan mengakui pelanggaran kewajiban kerjasama dari sisi pengguna dan menolak tanggung jawab atas pelanggaran kewajiban oleh vendor. (Meskipun pembatalan kontrak diakui, namun juga diakui adanya pemotongan kesalahan sebesar 60%.)

Kontrak pengembangan sistem komputer ini adalah kontrak pengembangan sistem yang dibuat sesuai pesanan, dan dalam kontrak pengembangan sistem seperti ini, vendor saja tidak bisa menyelesaikan sistem, sehingga pengguna harus melakukan koordinasi pendapat internal dengan tepat dan menyatukan pandangan, dan menjelaskan dengan jelas kepada vendor tentang fungsi apa yang diinginkan, dan bersama vendor, mempertimbangkan fungsi yang diinginkan, menentukan fungsi akhir, dan selanjutnya, menentukan layar dan laporan, dan menerima hasil, dan lain-lain, peran ini harus dibagi.

Putusan Pengadilan Distrik Tokyo, 10 Maret 2004 (Tahun Heisei 16)

Putusan ini tidak hanya menunjukkan bahwa pengembangan sistem itu sendiri adalah kerja sama dengan pengguna, tetapi juga memberikan petunjuk yang sangat berharga tentang “poin apa yang harus dikerjakan bersama”.

Mari kita coba terjemahkan kata-kata dalam putusan pengadilan di atas ke dalam istilah IT pengembangan sistem.

Kita bisa merangkumnya seperti di atas. Semua ini adalah hal-hal yang tidak bisa dilakukan sendiri oleh vendor, tidak peduli seberapa tinggi keahlian mereka dalam sistem IT. Fungsi yang diinginkan dan tata letak layar adalah hal-hal yang harus dijelaskan oleh pengguna, dan hanya pengguna yang bisa memeriksa apakah hasilnya sesuai dengan yang diinginkan.

Sebagai catatan, sama seperti vendor memiliki kewajiban manajemen proyek, pengguna juga memiliki kewajiban kerjasama. Oleh karena itu, jika pengguna melanggar kewajiban kerjasama dalam proses seperti di atas, ada kemungkinan bahwa vendor akan mengajukan klaim ganti rugi kepada pengguna berdasarkan pelanggaran kewajiban atau tindakan ilegal.

Bagaimana Permintaan Perubahan Spesifikasi Setelahnya Ditafsirkan?

Jika kita menganggap bahwa proyek pengembangan sistem adalah kerja sama antara pengguna dan vendor, diskusi akan berkembang ke arah yang lebih maju. Pertanyaannya adalah, “Siapa yang bertanggung jawab jika pengguna meminta penambahan atau perbaikan fungsi setelahnya, dan hal tersebut membuat sulit untuk memenuhi tenggat waktu?”

Pengembangan sistem umumnya dimulai dengan definisi kebutuhan, diikuti oleh desain dasar, desain detail, pembuatan (implementasi program), dan pengujian, dengan tujuan untuk mencegah sebanyak mungkin kembalinya tangan (biasanya disebut model air terjun). Namun, dalam kenyataannya, sering kali terjadi bahwa jika ada kekurangan dalam proses sebelumnya karena beberapa alasan, tangan akan kembali ke proses tersebut.

Bagaimana kita harus memikirkan hal ini jika kita tidak dapat memenuhi tenggat waktu dalam kasus seperti ini? Dari membaca kasus sebelumnya, tampaknya ada perbedaan dalam kesimpulan tergantung pada kapan pekerjaan tambahan terjadi.

Jika Pekerjaan Tambahan Terjadi Sebelum Penjelasan Spesifikasi Desain Eksternal, dll.

Dalam kasus sebelumnya, ada permintaan untuk pengembangan tambahan dari pengguna selama desain dasar (sebelum tahap implementasi program), dan pada saat yang sama, menunjukkan bahwa tidak ada pelanggaran kewajiban kerjasama hanya dengan mengajukan permintaan tersebut.

Untuk pengguna untuk membuat berbagai permintaan kepada vendor tentang sistem yang akan dibangun selama pekerjaan desain dasar, ini adalah hal yang biasa dalam proses pengembangan sistem seperti ini, dan selain itu, bagi pengguna asli yang tidak memiliki pengetahuan khusus, apakah permintaan tersebut memerlukan biaya tambahan atau penundaan tenggat waktu, dll., atau apakah itu akan mengganggu proses kerja, sulit untuk membuat penilaian yang tepat. Oleh karena itu, tidak dapat dikatakan bahwa pengguna asli harus menahan diri dari permintaan yang akan menghasilkan biaya tambahan atau penundaan tenggat waktu, dll. Sebaliknya, jika pengguna asli membuat permintaan yang memerlukan biaya tambahan atau penundaan tenggat waktu, dll., maka tergantung pada terdakwa yang memiliki kewajiban manajemen proyek, mereka harus memberi tahu pengguna asli tentang hal ini, meminta diskusi tentang penarikan permintaan atau penundaan tenggat waktu, dll., dan memastikan bahwa tidak ada gangguan dalam pekerjaan pengembangan.

Putusan Pengadilan Distrik Tokyo, 10 Maret 2004 (2004)

Dalam putusan ini, sementara mengakui bahwa ada kewajiban kerjasama tertentu pada sisi pengguna, juga menunjukkan bahwa pengguna sendiri bukanlah ahli dalam pengembangan sistem dan harus dipertimbangkan. Dengan kata lain, pengguna yang memesan bukanlah ahli dalam pengembangan sistem, jadi selama periode hingga konten sistem yang akan dikembangkan menjadi jelas, tidak aneh jika mereka membuat pesanan secara bertahap (bahkan jika mereka tidak terbiasa memesan), dan lebih jauh lagi, jika konten pesanan tersebut memerlukan revisi tenggat waktu, dll., adalah kejam untuk mengatakan bahwa mereka harus “menyadari hal itu sendiri”.

Namun, kewajiban yang dikenakan pada sisi vendor di sini pada dasarnya adalah upaya komunikasi, seperti meminta penundaan tenggat waktu, dll. (atau, jika tenggat waktu tidak dapat dipindahkan, menyarankan untuk menarik permintaan tambahan itu sendiri). Oleh karena itu, tidak berarti bahwa semua kewajiban termasuk dalam hal ini, seperti menerima semua permintaan pengguna dan memberikan pada tanggal yang ditentukan sejak awal, jadi perlu berhati-hati dalam hal ini.

Jika Pekerjaan Tambahan Terjadi Setelah Spesifikasi Pembuatan atau Pengujian Dikonfirmasi

Jika Anda membalik konten putusan di atas, Anda dapat sejauh ini memprediksi apa kesimpulannya jika itu adalah pengembangan tambahan setelah spesifikasi telah dikonfirmasi. Dalam hal ini, permintaan tersebut akan sulit untuk diterima. Memang, baik pengguna maupun vendor, tingkat pemahaman tentang pekerjaan pengembangan memiliki kesenjangan besar, baik sebelum maupun setelah konfirmasi spesifikasi.

Namun, mengubah atau menambahkan konten pesanan setelah spesifikasi dikonfirmasi memiliki kemungkinan tinggi untuk memaksa pekerjaan untuk dilakukan ulang. Dalam banyak kasus, sulit untuk membela keterlambatan pengiriman yang terjadi bahkan dalam kasus ini dengan mengatakan, “Ini adalah pelanggan, jadi wajar untuk membuat berbagai permintaan”. Selain itu, situasi di mana banyak perubahan spesifikasi dan penambahan fungsi terjadi setelahnya memunculkan pertanyaan apakah ada pelanggaran kewajiban kerjasama pengguna di proses hulu seperti desain dasar yang seharusnya sudah selesai sebelumnya.

Dari sudut pandang ini, tidak realistis untuk menganggap keterlambatan pengiriman yang disebabkan oleh perubahan spesifikasi yang dilakukan setelah spesifikasi dikonfirmasi sebagai tanggung jawab vendor. Dari teks putusan sebelumnya, dapat diterima untuk membaca makna seperti itu pada saat yang sama.

Selain itu, keputusan seperti ini cenderung dibuat berdasarkan bukti seperti catatan rapat yang disesuaikan dengan kemajuan pengembangan sistem, bukan hanya kontrak. Catatan rapat dijelaskan secara detail dalam artikel di bawah ini.

Artikel terkait: Bagaimana Cara Meninggalkan Catatan Rapat dalam Pengembangan Sistem dari Perspektif Hukum[ja]

Kesimpulan: Penting untuk tidak melupakan bahwa definisi persyaratan adalah proses dari sisi pengguna

Definisi persyaratan adalah tempat di mana vendor menunjukkan kemampuannya, namun seharusnya kita sadar bahwa ini pada dasarnya adalah tugas dari sisi pengguna. Mengingat ini adalah sistem yang digunakan oleh perusahaan kita sendiri, bahkan jika kita membangunnya dengan bantuan ahli eksternal, secara hukum dianggap sebagai area yang seharusnya berada di bawah tata kelola perusahaan kita sendiri.

Jika pihak pengguna tidak kooperatif dalam proses pengembangan, kita harus menyadari bahwa bahkan jika proyek mengalami kegagalan besar, pengadilan mungkin akan memberikan pandangan yang keras terhadap pihak pengguna.