Sejauh Mana Fungsi yang Tidak Tercantum dalam Spesifikasi Pengembangan Sistem Harus Diimplementasikan Menurut Hukum?

Proyek pengembangan sistem IT yang digunakan dalam perusahaan pada prinsipnya dibuat sesuai dengan spesifikasi yang telah ditentukan sebelumnya. Namun, di sisi lain, jika kita mempertimbangkan arti dari vendor yang diberi tanggung jawab penuh sebagai ahli pengembangan sistem, harapan dari pengguna mungkin tidak sekecil itu hanya dengan mengimplementasikan apa yang ditulis dalam spesifikasi secara mekanis. Dalam artikel ini, kami akan menjelaskan sejauh mana kewajiban untuk mengimplementasikan program yang “tidak ditulis dalam spesifikasi, tetapi perlu diimplementasikan dengan mempertimbangkan tujuan pengembangan”.

Masalah Hukum yang Muncul dari Implementasi yang Tidak Ada dalam Spesifikasi

Discretion Diperlukan dalam Pekerjaan Vendor

Salah satu ciri khas besar dari kontrak yang berkaitan dengan proyek pengembangan sistem dan berbagai masalah hukum yang menyertainya adalah bahwa vendor yang menerima pekerjaan memiliki banyak ‘discretion’.

Artikel terkait: Apa itu Kewajiban Manajemen Proyek dalam Pengembangan Sistem[ja]

Namun, ‘discretion’ yang dimaksud di sini tidak selalu berlaku untuk semua proses pengembangan sistem. Setelah mengidentifikasi setiap proses dan memajukan identifikasi tugas-tugas kecil, mungkin ada banyak pekerjaan yang mirip dengan pekerjaan sederhana. Namun, umumnya, sebelum pemecahan masalah seperti ini, yaitu semakin banyak pekerjaan di proses hulu, semakin sulit untuk melaksanakan pekerjaan tanpa memiliki banyak ‘discretion’. Alasan lain mengapa kontrak semacam ini sering kali cocok dengan proses hulu adalah karena hal ini.

Artikel terkait: Perbedaan dan Distingsi antara Kontrak Pengadaan dan Kontrak Kuasi-Mandat dalam Pengembangan Sistem[ja]

Discretion Juga Harus Diterapkan dalam Proses Pengembangan yang Ketat

Namun, meskipun vendor yang mengembangkan sistem memiliki banyak ‘discretion’, menerima permintaan klien secara sembarangan dapat menyebabkan kerusakan besar pada proses selanjutnya. Satu sistem IT terdiri dari kumpulan komponen kecil, sehingga meskipun hanya perubahan kecil pada penampilan, mungkin diperlukan perubahan besar dalam jumlah pekerjaan dari perspektif pengembang. Selain itu, ada artikel yang menjelaskan cara mengelola perubahan dalam spesifikasi pengembangan sistem dari perspektif hukum. Artikel berikut menjelaskan cara mengelola perubahan, tetapi juga membahas sejauh mana perubahan spesifikasi dari perspektif teknisi dapat memiliki dampak besar pada pekerjaan.

Artikel terkait: Cara Mengelola Perubahan dalam Pengembangan Sistem dari Perspektif Hukum[ja]

Apa yang Harus Dilakukan Sebagai Spesialis, Tanpa Terikat oleh Spesifikasi?

Untuk melancarkan proyek pengembangan sistem, penting untuk mendefinisikan persyaratan pengembangan sebelumnya dan melanjutkannya secara terencana sesuai dengan itu. Di sisi lain, hanya melakukan apa yang dikatakan sesuai dengan persyaratan yang telah ditentukan sebelumnya mungkin ada situasi di mana Anda tidak dapat memenuhi peran Anda sebagai spesialis pengembangan sistem. Dalam dilema seperti ini, masalah “Apa yang harus diimplementasikan meskipun tidak ditunjukkan dalam spesifikasi” menjadi nyata.

Kewajiban hukum ditentukan berdasarkan ‘maksud’ dari spesifikasi dan kontrak

Isi dari apa yang harus diimplementasikan, meskipun tidak tertulis dalam kontrak atau spesifikasi, tetap ditentukan berdasarkan ‘maksud’ dari hal-hal yang tertulis dalam kontrak atau spesifikasi tersebut. Artinya, ‘apa maksud dan tujuan dari penentuan tersebut’. Mari kita lihat beberapa contoh kasus pengadilan di bawah ini.

Contoh Kasus Pengadilan yang Menyangkal Kewajiban Implementasi karena Tidak Ada Catatan

Contoh kasus pengadilan yang kami kutip di bawah ini berkaitan dengan sistem yang dikembangkan oleh vendor, yang telah mencapai tahap operasional sementara, namun diklaim tidak memiliki fungsi yang cukup, sehingga memicu permintaan pembatalan kontrak dan berujung pada perselisihan. Fungsi yang diklaim pengguna kurang adalah “fungsi pembaruan otomatis data”, yang diklaim sebagai salah satu poin penjualan utama sistem ini, namun pengadilan tidak mengakui kewajiban implementasi ini.

Seperti yang telah diakui di atas, dalam kontrak ini dan dalam dokumen desain dasar dan detail, tidak ada catatan yang menunjukkan bahwa fungsi ③ adalah target pengembangan sistem ini.

Plaintif berpendapat bahwa fungsi ③ adalah salah satu poin penjualan utama sistem ini kepada tergugat, dan menekankan kebutuhan fungsi tersebut, namun jika argumen tersebut benar, seharusnya hal tersebut dicantumkan secara jelas dalam kontrak dan dokumen lainnya, dan sulit untuk berpikir bahwa pengembangan fungsi tersebut telah disepakati tanpa catatan tersebut.

Putusan Pengadilan Distrik Tokyo, 18 Februari Heisei 21 (2009)

Memang, jika kita hanya mengambil kesimpulan dari putusan tersebut secara sederhana, kita bisa mengatakan, “Jika tidak ada catatan dalam dokumen desain, kita tidak perlu membuat apa yang tidak ada.” Namun, jika kita berbicara lebih tepat, bukan fakta formal seperti apakah ada catatan dalam dokumen desain atau tidak, tetapi penilaian berdasarkan ‘maksud’ catatan dalam dokumen desain dan kontrak. Dengan kata lain, “Mengingat alasan mengapa tidak ada catatan dalam dokumen desain dan kontrak, wajar untuk berpikir bahwa tidak ada persetujuan yang sesuai dengan catatan tersebut.”

Contoh Kasus Hukum yang Mengesahkan Kewajiban Implementasi Meskipun Tidak Tercantum

Di sisi lain, ada juga contoh kasus hukum yang menegaskan kewajiban untuk melaksanakan implementasi, meskipun tidak tercantum dalam kontrak atau dokumen spesifikasi. Contoh kasus yang akan saya kutip di bawah ini berkaitan dengan pengembangan sistem untuk mengelola riwayat penggunaan obat, di mana tidak dapat melakukan migrasi data dari sistem lama ke sistem baru, sehingga pengguna tidak dapat memanfaatkan sistem baru dan memutuskan untuk membatalkan kontrak. Namun, pihak vendor berpendapat bahwa migrasi data bukanlah bagian dari lingkup pekerjaan mereka, yang kemudian memicu perselisihan.

Pengembangan sistem baru seringkali melibatkan penghapusan sistem lama dan migrasi data. Kami telah menjelaskan secara detail tentang pentingnya pekerjaan semacam ini dan masalah hukum yang terkait dengannya dalam artikel berikut.

Artikel terkait: Masalah Hukum yang Muncul Dalam Migrasi dari Sistem Lama dalam Pengembangan Sistem[ja]

Data pasien lebih dari 50.000 orang telah disimpan dalam sistem lama, dan penggugat telah menggunakan data ini untuk meningkatkan efisiensi pekerjaan. Jika tidak dapat memindahkan data pasien dari sistem lama ke sistem baru, akan jelas mengganggu operasional di apotek, dan dapat dipikirkan bahwa perwakilan penggugat pasti telah menyadari hal ini. Sebelum kontrak ini ditandatangani, perwakilan penggugat telah bertanya kepada perwakilan tergugat tentang kemungkinan migrasi data, dan perwakilan tergugat juga mengakui hal ini. Oleh karena itu, sulit untuk berpikir bahwa perwakilan penggugat memutuskan untuk mengimplementasikan sistem ini meskipun menyadari bahwa kemungkinan besar mereka harus memasukkan data pasien lebih dari 50.000 orang secara manual. Selain itu, seperti yang disebutkan di atas, tergugat tidak dapat memindahkan data riwayat obat dari sistem lama ke sistem baru, dan mereka mencetak data tersebut dan mengubahnya menjadi file PDF, meskipun migrasi data tidak diasumsikan dalam kontrak ini, sulit untuk berpikir bahwa tergugat melakukan pekerjaan yang memakan waktu ini sebagai layanan.

Putusan Pengadilan Distrik Tokyo, 18 November 2010 (Tahun 22 era Heisei)

Yang menjadi penting di sini adalah ‘tujuan’ kontrak dan ‘makna’ dari item yang tercantum dalam kontrak. Jika kedua pihak menandatangani kontrak dengan pemahaman bahwa migrasi data bukan bagian dari lingkup pekerjaan, maka pengadilan menunjukkan bahwa kedua pihak, pengguna dan vendor, telah menandatangani kontrak dengan niat yang tidak wajar. Artinya, pengguna telah menerima pekerjaan manual dalam jumlah besar, dan vendor telah mendekati proyek dengan pengetahuan bahwa ini akan mengganggu pekerjaan pengguna di masa depan, yang merupakan cerita yang sangat tidak rasional.

Apa yang dapat dipahami dari kedua putusan tersebut?

Meskipun tidak ada catatan tentang migrasi data dalam kontrak atau dokumen spesifikasi, latar belakang dari kewajiban implementasi yang diterima adalah, sebagian, karena ini adalah masalah yang tidak muncul dalam penampilan layar, yaitu “data”. “Kekurangan fungsi penting” yang disebutkan sebelumnya adalah sesuatu yang muncul langsung pada layar atau penampilan sistem. Oleh karena itu, bahkan jika Anda adalah pemula dalam pengembangan sistem, tidak terlalu sulit untuk menemukan kekurangan dalam penulisan dokumen spesifikasi. Di sisi lain, masalah migrasi data memiliki karakteristik sulitnya pemula dalam pengembangan sistem untuk mengenali pentingnya proses tersebut, tingkat kesulitan pekerjaan, dan jumlah waktu yang diperlukan. Oleh karena itu, ada juga situasi di mana vendor dianggap harus menangani masalah ini dengan lancar dengan keahlian mereka.

Jika Anda memikirkannya dengan cara ini, kekurangan dalam penulisan dokumen spesifikasi dan kontrak adalah masalah yang erat kaitannya dengan “kewajiban kerjasama” pengguna. Dengan kata lain, apakah pengguna benar-benar telah memenuhi “kewajiban kerjasama” mereka dalam membuat kontrak dan dokumen spesifikasi. Untuk penjelasan umum tentang kewajiban hukum yang harus dipenuhi oleh pengguna dalam proyek pengembangan sistem, silakan lihat artikel di bawah ini.

Artikel terkait: Apa itu kewajiban kerjasama yang harus dipenuhi oleh pengguna sebagai pemesan pengembangan sistem[ja]

Jika Anda juga memeriksa artikel di atas, Anda mungkin akan memahami bahwa permintaan kerjasama dari pengguna, seperti identifikasi layar dan fungsi penting, dan kegagalan dalam mempertimbangkan migrasi data, adalah dua hal yang sangat berbeda.

Bagaimana Cara Memandang Upah untuk Pengembangan yang Tidak Tercantum dalam Spesifikasi?

Hal lain yang mungkin menarik perhatian Anda sehubungan dengan topik artikel ini adalah apakah hukum mengizinkan penagihan upah tambahan jika Anda membuat sesuatu yang tidak tercantum dalam spesifikasi. Kami telah menjelaskan secara detail tentang apakah penambahan upah diizinkan dan bagaimana cara menghitung jumlah perkiraan jika diizinkan, dalam artikel berikut.

Artikel terkait: Apakah Mungkin untuk Meningkatkan Jumlah Perkiraan Pengembangan Sistem Setelah Fakta[ja]

Dalam artikel di atas, kami menjelaskan bahwa apakah ada pekerjaan yang melebihi cakupan pekerjaan yang berhubungan dengan upah dan kompensasi adalah penting. Dengan kata lain, dalam konteks artikel ini, jika vendor menanggapi pengembangan sesuatu yang tidak termasuk dalam spesifikasi awal (dalam hal ini, contoh negatif dalam artikel ini), mereka dapat meminta upah tambahan.

Ringkasan

Dalam pengembangan sistem, peran yang harus dilakukan oleh vendor sejatinya ditentukan berdasarkan isi kontrak dan dokumen spesifikasi. Namun, jika mempertimbangkan bahwa mereka adalah ahli yang dipercaya untuk melakukan tugas dengan tingkat keahlian tinggi, kita dapat memahami bahwa kenyataannya tidak selalu ditentukan berdasarkan formalitas. Namun, dalam memahami realitas ini, kita harus memahami bahwa hukum memainkan peran penting.