Apa Arti Hukum dari Tujuan Manajemen & Tujuan Numerik dalam Proyek Pengembangan Sistem?

Proyek pengembangan sistem sering kali erat kaitannya dengan peningkatan bisnis skala besar di perusahaan atau tempat kerja. Dalam hal ini, mungkin diperlukan sikap yang berkontribusi terhadap penyelesaian masalah manajemen perusahaan dari sisi pengguna, atau pencapaian target numerik. Namun, apakah berkomitmen terhadap tujuan manajemen seperti ini benar-benar merupakan kewajiban hukum? Masalahnya adalah apa arti hukum dari target numerik atau tujuan manajemen. Dalam artikel ini, kami akan menjelaskan masalah hukum yang terkait dengan berbagai “tujuan” dan “target” dalam pengembangan sistem.

Mengapa Tujuan dan Sasaran Pengembangan Sistem Menjadi Sumber Konflik?

Karena masalah ini berada di antara kewajiban kerjasama pengguna dan diskresi vendor

Dalam konteks transaksi bisnis, ada beberapa karakteristik unik dalam proyek pengembangan sistem. Pertama, proyek pengembangan sistem oleh vendor bukanlah sesuatu yang dapat dilakukan oleh vendor sendiri, tetapi memerlukan kerjasama dari pengguna. Kewajiban ini dikenal dalam hukum preseden sebagai “kewajiban kerjasama”. Terutama dalam fase seperti ① definisi persyaratan ② desain dasar ③ penerimaan hasil, pengguna juga diminta untuk bekerja sama dalam pengembangan sistem.

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

Yang lainnya adalah bahwa vendor biasanya diminta untuk menggunakan diskresi yang besar dalam menjalankan tugasnya. Ada istilah hukum yang merangkum apa yang harus dilakukan oleh vendor dalam proyek pengembangan sistem, yaitu “kewajiban manajemen proyek”. Ini dijelaskan secara detail dalam artikel berikut.

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

Jika kita merangkum konten di atas, kita dapat menunjukkan dua poin penting di sini.

• Pengguna diminta dalam praktek untuk memberikan informasi yang diperlukan kepada vendor dan bekerja sama dengan pekerjaan pengembangan vendor.
• Vendor diminta dalam praktek untuk memahami tujuan dan sasaran proyek bagi pengguna dan melakukan upaya yang sesuai.

Karena dua situasi ini, masalahnya adalah sejauh mana pencapaian tujuan bisnis dan tujuan numerik yang dijelaskan sebelumnya oleh pengguna dapat menjadi kewajiban hukum vendor. Dengan kata lain, ada aspek di mana pengguna memiliki kewajiban untuk merangkum apa yang harus dilakukan oleh vendor (bukan hal-hal yang ambigu seperti tujuan) dalam spesifikasi dan menunjukkannya, tetapi di sisi lain, vendor juga memiliki kewajiban sebagai profesional untuk memberikan apa yang benar-benar diinginkan oleh pengguna (bukan hanya melakukan apa yang dikatakan). Konflik antara kedua pihak dengan pandangan yang bertentangan ini adalah karakteristik konflik seputar “tujuan” dan “tujuan” pengembangan sistem. Dari sudut pandang hukum, menunjukkan pedoman untuk penyelesaian konflik yang adil bagi kedua belah pihak adalah tantangan dalam praktek.

Contoh Konkrit Bagaimana Tujuan Pengguna Mempengaruhi Proyek

Proyek pengembangan sistem seringkali terkait dengan upaya peningkatan dan efisiensi pekerjaan skala besar di perusahaan dan tempat kerja, dan seringkali ada wawancara tentang masalah bisnis dan tujuan bisnis bahkan pada tahap perencanaan dan proposal. Di sana, pertukaran tentang biaya-efektivitas pengembangan sistem dan pertukaran melalui berbagai tujuan numerik dapat dipertimbangkan.

• Pengurangan biaya tenaga kerja karena efisiensi
• Peningkatan penjualan dan pendapatan
• Pemendekan waktu kerja

Misalnya, dalam kasus di mana item-item di atas menjadi tujuan akhir proyek, vendor mungkin menjelaskan efek investasi pengembangan sistem dari posisi seperti konsultan sebelumnya dan melakukan penjualan.

Kasus Hukum di Mana Tujuan Manajemen yang Ditetapkan oleh Pengguna Menjadi Masalah

Namun, vendor biasanya adalah ahli pengembangan sistem. Jika semua tanggung jawab ditumpuk pada tujuan manajemen pengguna, hal ini bisa menjadi beban yang terlalu berat.

Kasus di Mana Peningkatan Kecepatan Operasional Ditetapkan Sebagai Tujuan

Sehubungan dengan hal ini, dalam kasus yang dikutip dalam putusan berikut, tujuan dan target proyek pengembangan sistem ditulis dalam proposal yang dibuat saat proyek dimulai. Namun, setelah sistem selesai dan mulai beroperasi, tujuan dan target tersebut tidak dapat dicapai, yang mengakibatkan perselisihan. Dalam proposal awal, setelah sistem selesai dan mulai digunakan, ditulis bahwa tujuan adalah untuk mencapai kondisi berikut.

• Mengurangi waktu input manual oleh manusia sebesar 50%
• Membuat proses administrasi menggunakan sistem IT ini dapat diselesaikan dalam jangka waktu yang ditentukan

Pengguna mencoba menuntut tanggung jawab atas pelanggaran kewajiban dan jaminan cacat terhadap vendor karena tidak dapat mencapai hasil ini. Namun, pengadilan tidak menerima klaim ini (bagian yang digarisbawahi dan dicetak tebal ditambahkan oleh penulis).

Dan, (omisi) berdasarkan seluruh inti argumen, ① tujuan kasus ini adalah “peningkatan efisiensi operasional”, “pembuatan dasar CRM”, “melakukan manajemen yang terlihat”, dll., yang bersifat abstrak, dan targetnya juga, “meningkatkan titik kontak dengan pelanggan”, “mengalokasikan tenaga kerja administrasi untuk kontrol internal dan dukungan penjualan”, “dapat membuat perkiraan penjualan lebih akurat”, “mengendalikan diskon penjualan yang berlebihan”, dll., banyak yang bersifat abstrak, dan “mengurangi waktu input sebesar 50%”, “mengurangi waktu pembuatan estimasi sebesar 50%”, “melakukan pengungkapan hukum dalam batas waktu hukum”, dll., adalah target yang tergantung pada cara manajemen dan operasi bisnis terdakwa setelah pengenalan SBO, dan bukanlah sesuatu yang perusahaan pengembangan sistem yang mendukung pengenalan perangkat lunak paket, yaitu penggugat, dapat mengambil alih pencapaiannya, ② dalam catatan rapat setelah kick-off proyek ini, tidak ada catatan yang membahas secara spesifik tentang pencapaian tujuan dan target ini, ③ dalam rencana proyek ini, “menjadi perusahaan publik”, dll., adalah ekspresi yang tidak dapat dikatakan memiliki sifat kontrak itu sendiri, (omisi) mengingat keadaan ini, penggugat membuat deskripsi tujuan ini dalam rencana proyek ini berdasarkan penjelasan terdakwa, untuk mencegah proyek ini gagal, itu adalah untuk mendapatkan pemahaman bersama tentang tujuan dan hasil proyek ini, dan terdakwa, terhadap penggugat, tidak dapat diakui bahwa mereka telah memberikan pengembangan sistem untuk mencapai tujuan ini. (omisi) Oleh karena itu, tidak dapat diakui bahwa penggugat telah mengambil alih pengembangan sistem untuk mencapai tujuan ini dari terdakwa, (omisi) klaim tanggung jawab atas pelanggaran kewajiban dan jaminan cacat tidak memiliki alasan.

Putusan Pengadilan Distrik Tokyo, 28 Desember 2010 (Tahun Heisei 22)

Apa Arti Hukum Tujuan Manajemen dan Target Numerik yang Dapat Dibaca dari Kasus Hukum?

Seperti yang disebutkan dalam putusan ini, apakah tujuan pengembangan sistem atau target yang dikuantifikasi secara numerik dapat dicapai atau tidak biasanya dipengaruhi oleh berbagai faktor, seperti upaya manajemen dari pengguna yang memanfaatkan sistem tersebut. Oleh karena itu, batas tanggung jawab vendor harus dianggap sangat tinggi. Pertama-tama, jika tanggung jawab vendor atas pelanggaran kewajiban dan jaminan cacat diakui, itu berarti bahwa pencapaian “tujuan” dan “target” telah dimasukkan sebagai bagian dari isi kontrak. Namun, dalam kasus ini, “tujuan” dan “target” adalah,

• Untuk hal-hal yang abstrak dan tidak jelas, sulit untuk dianggap sebagai bagian dari isi kontrak karena tidak sesuai dengan sifat kewajiban hukum
• Untuk hal-hal yang memerlukan upaya bantuan diri sendiri dari pihak pengguna, terutama dari sisi manajemen, sulit untuk dianggap sebagai bagian dari kewajiban kontrak karena vendor tidak dapat mengendalikannya, dan tidak tepat untuk menyalahkan vendor

Hasilnya adalah penilaian hukum seperti ini.

Apa yang Dapat Dibaca Lebih Lanjut dari Putusan Ini

Putusan ini juga berisi beberapa konten yang menarik lainnya.

• Poin bahwa pengadilan juga mempertimbangkan kemungkinan bahwa berbagi “tujuan” dan “target” proyek pengembangan sistem hanyalah bagian dari upaya komunikasi untuk mendapatkan “pemahaman bersama” antara pengguna dan vendor.
• Poin bahwa catatan rapat, dll., juga digunakan sebagai referensi ketika mempertimbangkan seberapa penting “tujuan” dan “target” tersebut dalam serangkaian proyek.

Untuk masalah hukum yang terkait dengan proyek pengembangan sistem, dari sudut pandang pentingnya manajemen dokumen dan catatan rapat, penjelasan diberikan dalam artikel berikut.

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

Catatan Hukum Mengenai Tujuan Manajemen dan Sasaran Numerik

Namun, ada beberapa poin tambahan yang perlu diperhatikan mengenai masalah hukum yang berkaitan dengan “tujuan” dan “sasaran” ini.

Perubahan dalam Konsultasi Berbayar atau Gratis

Jika Anda tidak hanya melakukan proyek pengembangan sistem, tetapi juga memiliki kontrak konsultasi berbayar, situasinya mungkin berubah secara signifikan. Jika ada situasi di mana Anda merumuskan rencana pelaksanaan yang kurang realistis tanpa mempertimbangkan sumber daya manajemen yang dimiliki oleh pengguna, Anda mungkin dikejar untuk tanggung jawab atas pelanggaran kontrak dalam bagian kontrak konsultasi berbayar tersebut.

Masalah Terpisah dengan Cacat Hasil Kerja, Ketidaksesuaian Fungsi dan Persyaratan Spesifikasi

Juga, jika ada cacat dalam proyek “pengembangan” itu sendiri, yaitu jika ada masalah atau bug dalam hasil kerja, perlu dipahami bahwa ini adalah masalah yang berbeda. Dalam hal ini, bahkan tanpa membicarakan “tujuan” dan “sasaran” manajemen, masalah utamanya adalah konsistensi antara hasil kerja dan fungsi dan spesifikasi yang diminta. Misalnya, kami menjelaskan tindakan yang harus diambil oleh pengguna jika cacat ditemukan dalam sistem setelah fakta dalam artikel berikut.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Topik terkait lainnya termasuk hal-hal yang diakui memiliki kewajiban untuk melaksanakan meskipun tidak termasuk dalam persyaratan, tetapi dilakukan atas kebijakan vendor. Kami menjelaskan ini secara detail dalam artikel berikut.

https://monolith.law/corporate/system-development-specs-function[ja]

Dalam setiap kasus, harus dipahami bahwa konflik mengenai “tujuan” dan “sasaran” adalah hal yang berbeda.

Pemahaman fundamental tentang tanggung jawab dan kontrak juga dipertanyakan

Sejauh ini, kami telah menjelaskan masalah hukum yang berkaitan dengan ‘tujuan’ dan ‘target’ pengembangan sistem. Dalam konflik mengenai hal-hal seperti ini, pengadilan sering kali memahami bahwa upaya untuk menyelaraskan langkah-langkah antara pengguna dan vendor adalah bagian dari upaya komunikasi dan sering kali dibagikan secara bersama. Meskipun demikian, meskipun validitas kesimpulan itu sendiri dapat dipahami dengan cukup baik berdasarkan intuisi praktisi, pemahaman fundamental tentang ‘tanggung jawab’ dan ‘kontrak’ dipertanyakan dalam proses menuju itu. Kami menjelaskan tentang hal ini dalam artikel berikut.

https://monolith.law/corporate/responsibility-system-development[ja]

Memahami bahwa tanggung jawab hukum berbeda dari tanggung jawab moral yang samar, dan bahwa ‘kesepakatan kehendak’ yang pasti antara kedua pihak adalah apa yang menciptakan tanggung jawab kontrak, adalah penting untuk mendapatkan pemahaman yang lebih esensial.