Apa Maksud Hukum Objektif Pengurusan & Sasaran Numerik dalam Projek Pembangunan Sistem

Projek pembangunan sistem sering kali berkait rapat dengan peningkatan operasi besar-besaran dalam syarikat atau tempat kerja. Dalam konteks ini, mungkin ada tuntutan untuk sikap yang menyumbang ke arah penyelesaian isu pengurusan syarikat dari pihak pengguna, atau pencapaian objektif berdasarkan angka. Namun, adakah komitmen terhadap objektif pengurusan ini merupakan kewajipan dari segi undang-undang? Makna undang-undang yang dimiliki oleh objektif berdasarkan angka atau objektif pengurusan menjadi isu. Dalam artikel ini, kami akan menerangkan tentang isu undang-undang yang berkaitan dengan pelbagai ‘tujuan’ dan ‘objektif’ dalam pembangunan sistem.

Mengapa Tujuan dan Sasaran Pembangunan Sistem Menjadi Punca Konflik?

Isu yang Berada di Antara Kewajipan Kerjasama Pengguna dan Budi Bicara Vendor

Dari sudut pandangan transaksi komersial, terdapat beberapa ciri unik dalam projek pembangunan sistem. Pertama, projek pembangunan sistem oleh vendor bukanlah sesuatu yang boleh dilakukan oleh vendor secara sendirian, tetapi memerlukan kerjasama dari pihak pengguna. Kewajipan ini dikenali sebagai “kewajipan kerjasama” dalam undang-undang preseden. Pengguna biasanya diminta untuk bekerjasama dalam pembangunan sistem pada fasa seperti ① penentuan keperluan ② reka bentuk asas ③ penerimaan hasil kerja.

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

Yang kedua, vendor biasanya diminta untuk menggunakan budi bicara yang luas dalam menjalankan tugas mereka. Terdapat istilah undang-undang yang merangkumi apa yang harus dilakukan oleh vendor dalam keseluruhan projek pembangunan sistem, yang dikenali sebagai “kewajipan pengurusan projek”. Ini dijelaskan dengan lebih terperinci dalam artikel berikut.

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

Mengambil kira semua ini, kita boleh menunjukkan dua perkara penting di sini.

• Pengguna diharapkan untuk memberikan maklumat yang diperlukan kepada vendor dan bekerjasama dengan kerja pembangunan vendor.
• Vendor diharapkan untuk memahami tujuan dan sasaran projek bagi pengguna dan melakukan usaha yang sejajar dengan itu.

Atas dua sebab ini, isu tentang sejauh mana pencapaian sasaran pengurusan dan sasaran numerik yang diberikan oleh pengguna sebelumnya boleh menjadi kewajipan vendor dalam undang-undang. Dengan kata lain, walaupun ada aspek yang mengatakan bahawa pengguna mempunyai kewajipan untuk merangkum apa yang harus dilakukan oleh vendor (bukan sesuatu yang kabur seperti sasaran) dalam spesifikasi dan menunjukkannya, ada juga aspek yang mengatakan bahawa vendor mempunyai kewajipan sebagai pakar untuk memberikan apa yang sebenarnya diminta oleh pengguna (bukan hanya melakukan apa yang diberitahu). Konflik antara kedua-dua pihak yang bertentangan ini adalah ciri konflik seputar “sasaran” dan “tujuan” pembangunan sistem. Dari sudut pandangan undang-undang, menunjukkan garis panduan penyelesaian konflik yang adil untuk kedua-dua pihak adalah isu dalam amalan.

Bagaimana Sasaran Pengguna Mempengaruhi Projek dalam Cara yang Konkrit

Projek pembangunan sistem seringkali berkaitan dengan usaha peningkatan dan pengefisienan kerja besar-besaran di syarikat atau tempat kerja, dan seringkali ada wawancara tentang isu pengurusan dan sasaran pengurusan pada tahap perancangan dan cadangan. Di sini, kita boleh membayangkan pertukaran tentang kos berbanding manfaat pembangunan sistem dan pertukaran melalui pelbagai sasaran numerik.

• Penjimatan kos tenaga kerja akibat pengefisienan
• Peningkatan pendapatan dan keuntungan
• Penyingkatan masa kerja

Sebagai contoh, jika item-item seperti yang di atas adalah tujuan akhir projek, vendor mungkin menjelaskan tentang kesan pelaburan dalam pembangunan sistem dari posisi seperti konsultan dan melakukan penjualan.

Contoh Kes di mana Matlamat Pengurusan yang Dikemukakan oleh Pengguna Menjadi Masalah

Namun, vendor biasanya adalah pakar dalam pembangunan sistem. Jika semua tanggungjawab ditumpukan kepada mereka berkenaan dengan matlamat pengurusan pengguna, ini mungkin menjadi beban yang terlalu berat.

Kes di mana peningkatan kelajuan operasi telah ditetapkan sebagai matlamat

Berkaitan dengan isu ini, dalam kes yang dirujuk dalam penghakiman berikut, tujuan dan matlamat untuk memulakan projek pembangunan sistem telah ditulis dalam proposal yang dibuat pada masa projek dimulakan. Namun, apabila sistem selesai dan operasi dimulakan, mereka tidak dapat mencapai tujuan dan matlamat tersebut, dan ini telah membawa kepada pertikaian. Dalam proposal awal, selepas sistem selesai dan mula digunakan, ia ditulis dengan tujuan untuk mencapai keadaan berikut:

• Mengurangkan masa input manual oleh manusia sebanyak 50%
• Memastikan proses administratif menggunakan sistem IT ini dapat diselesaikan dalam tempoh yang ditetapkan

Pengguna mencuba untuk mengejar tanggungjawab pelanggaran kontrak dan jaminan cacat terhadap vendor kerana mereka tidak dapat mencapai ini pada akhirnya. Namun, mahkamah tidak menerima hujah ini (bahagian yang digarisbawahi dan tebal adalah tambahan oleh penulis).

Dan, (omitted) berdasarkan keseluruhan hujah, ① tujuan kes ini adalah “peningkatan kecekapan operasi”, “membina asas CRM”, “melakukan pengurusan yang boleh dilihat” dan sebagainya, yang merupakan abstrak, dan nilai sasaran juga “meningkatkan titik sentuhan dengan pelanggan”, “mengalihkan tenaga kerja pejabat ke kawalan dalaman / sokongan jualan”, “ramalan jualan yang lebih tepat dapat dibuat”, “mengawal diskaun jualan yang berlebihan” dan sebagainya, banyak yang abstrak, dan “mengurangkan masa input sebanyak 50%”, “mengurangkan masa untuk membuat anggaran sebanyak 50%”, “melakukan pendedahan undang-undang dalam tempoh undang-undang” dan sebagainya nilai sasaran adalah bergantung pada cara pengurusan dan operasi defendan setelah pengenalan SBO, dan bukanlah sesuatu yang plaintif, sebuah syarikat pembangunan sistem yang membantu pengenalan perisian paket, dapat mengambil tanggungjawab untuk mencapainya, ② dalam minit mesyuarat selepas kickoff projek ini, tidak ada catatan yang membincangkan secara khusus tentang pencapaian tujuan dan nilai sasaran ini, ③ dalam rancangan projek ini, “menjadi syarikat tersenarai” dan sebagainya, ungkapan yang tidak dapat dianggap sebagai sifat kontrak digunakan, (omitted) mengambil kira keadaan seperti itu, plaintif membuat deskripsi tujuan ini dalam rancangan projek ini berdasarkan penjelasan defendan, untuk mengelakkan projek ini gagal, ia adalah untuk mendapatkan pengakuan bersama tentang tujuan dan hasil projek ini, dan defendan, terhadap plaintif, tidak dapat mengakui bahawa mereka telah mengarahkan pembangunan sistem untuk mencapai tujuan ini. (omitted) Oleh itu, tidak dapat diakui bahawa plaintif telah mengambil tanggungjawab untuk pembangunan sistem untuk mencapai tujuan ini dari defendan, (omitted) tiada alasan untuk menuntut tanggungjawab pelanggaran kontrak dan jaminan cacat.

Keputusan Mahkamah Tokyo, 28 Disember 2010 (Tahun 22 Heisei)

Apa Maksud Hukum Matlamat Pengurusan & Sasaran Kuantitatif yang Dapat Dibaca dari Contoh Kes?

Sebagaimana disebut dalam penghakiman ini, sama ada tujuan pembangunan sistem atau sasaran yang dikuantifikasi secara numerik dapat dicapai atau tidak biasanya melibatkan pelbagai faktor seperti usaha pengurusan pengguna yang menggunakan sistem tersebut. Oleh itu, batas tanggungjawab pihak vendor harus dianggap sangat tinggi. Pertama sekali, jika tanggungjawab pelanggaran kontrak dan jaminan cacat pihak vendor diakui, ini bermakna pencapaian “tujuan” atau “sasaran” telah disertakan sebagai sebahagian daripada isi kontrak. Namun, dalam kes ini, “tujuan” dan “sasaran” adalah:

• Untuk perkara yang abstrak dan tidak jelas, ia tidak sesuai dengan sifat tanggungjawab hukum, dan tidak masuk akal untuk menganggapnya sebagai sebahagian daripada isi kontrak
• Untuk perkara yang memerlukan usaha bantuan diri sendiri, terutama dari pihak pengurusan pengguna, selagi ia berada di luar kawalan pihak vendor, adalah tidak wajar untuk menyalahkan pihak vendor, dan tidak masuk akal untuk menganggapnya sebagai sebahagian daripada tanggungjawab kontrak

Ini adalah penilaian hukum yang diterima dalam hal ini.

Apa yang Dapat Dibaca Lebih Lanjut dari Penghakiman Ini

Penghakiman ini juga mengandungi beberapa kandungan yang menarik.

• Titik yang diambil kira oleh mahkamah bahawa perkongsian “tujuan” dan “sasaran” projek pembangunan sistem mungkin hanya merupakan sebahagian daripada usaha komunikasi untuk mendapatkan “pengakuan bersama” antara pengguna dan vendor.
• Titik yang merujuk kepada minit mesyuarat dan sebagainya untuk mempertimbangkan sejauh mana “tujuan” dan “sasaran” tersebut adalah elemen penting dalam projek keseluruhan.

Selain itu, dari sudut pandangan kepentingan pengurusan dokumen dan minit, kami telah memberikan penjelasan tentang isu hukum yang berkaitan dengan projek pembangunan sistem dalam artikel berikut.

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

Perhatian Mengenai Isu Hukum Berkaitan dengan Objektif Pengurusan dan Sasaran Numerik

Namun, berkenaan dengan isu hukum yang berkaitan dengan “tujuan” dan “sasaran”, mari kita perhatikan juga beberapa perkara tambahan seperti berikut.

Perbincangan berubah bergantung kepada sama ada perundingan adalah berbayar atau percuma

Jika bukan sahaja projek pembangunan sistem, tetapi juga kontrak perundingan berbayar telah ditandatangani, keadaan mungkin berubah secara drastik. Jika ada keadaan di mana, tanpa mengambil kira sumber pengurusan yang dimiliki oleh pihak pengguna, rancangan pelaksanaan yang kurang kemungkinan untuk direalisasikan telah ditetapkan, mungkin ada kemungkinan untuk dituntut tanggungjawab atas kegagalan melaksanakan hutang dalam bahagian kontrak perundingan berbayar tersebut.

Defek dalam hasil kerja, ketidaksesuaian fungsi dan keperluan spesifikasi adalah isu yang berbeza

Selain itu, jika ada defek dalam projek “pembangunan” itu sendiri, iaitu jika terdapat kecacatan atau bug dalam hasil kerja, perlu difahami secara berasingan dari isu ini. Dalam kes tersebut, tidak perlu membincangkan “tujuan” atau “sasaran” pengurusan, tetapi sebaliknya, kesesuaian antara hasil kerja dan fungsi dan spesifikasi yang diperlukan menjadi isu. Sebagai contoh, kami telah menerangkan langkah-langkah yang harus diambil oleh pihak pengguna jika defek ditemui dalam sistem setelah fakta dalam artikel berikut.

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

Topik lain yang berkaitan termasuk perkara yang tidak termasuk dalam keperluan, tetapi dianggap sebagai kewajipan untuk melaksanakan oleh pihak vendor. Kami telah menerangkan secara terperinci tentang ini dalam artikel berikut.

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

Dalam setiap kes, ia harus difahami sebagai sesuatu yang mirip tetapi berbeza dari konflik yang berkaitan dengan “tujuan” dan “sasaran”.

Pemahaman asas terhadap tema seperti tanggungjawab dan kontrak juga ditanya

Sehingga ini, kami telah memberikan penjelasan mengenai isu-isu undang-undang yang berkaitan dengan ‘tujuan’ dan ‘matlamat’ pembangunan sistem. Dalam pertikaian yang berkaitan dengan isu-isu ini, mahkamah seringkali memahami bahawa usaha untuk menyelaraskan langkah-langkah antara pengguna dan vendor adalah sebahagian daripada usaha komunikasi, dan seringkali berbagi antara satu sama lain. Walau bagaimanapun, walaupun keabsahan kesimpulan itu sendiri boleh difahami dengan cukup baik berdasarkan intuisi praktikal sebagai praktisi, pemahaman asas terhadap ‘tanggungjawab’ dan ‘kontrak’ ditanya dalam proses yang membawa ke sana. Kami memberikan penjelasan mengenai isu-isu ini dalam artikel berikut.

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

Adalah penting untuk memahami bahawa tanggungjawab undang-undang berbeza daripada tanggungjawab moral yang kabur, dan bahawa ‘persetujuan kehendak’ yang jelas antara kedua-dua pihak adalah apa yang menghasilkan tanggungjawab kontrak, dengan mempertimbangkan ini, adalah penting untuk mendapatkan pemahaman yang lebih asas.