Issu Undang-Undang yang Berkaitan dengan Migrasi dari Sistem Lama dalam Pembangunan Sistem

Membina sistem IT baru untuk digunakan dalam syarikat adalah bidang kerja utama bagi jurutera IT, namun dalam konteks “membina sistem baru”, proses “menghapuskan sistem yang telah digunakan sebelum ini” seringkali juga termasuk di dalamnya. Dalam artikel ini, kami akan membincangkan pelbagai isu undang-undang yang berkaitan dengan pembangunan sistem baru ini, dengan memberi tumpuan khusus kepada aspek “penghapusan sistem lama”.

Apa maksud beralih kepada sistem baru

Jangka Hayat Sistem IT Bukanlah Selamanya

Sistem IT yang digunakan dalam syarikat bukanlah sesuatu yang sekali dibuat, boleh digunakan secara berterusan. Selain itu, tidak semestinya baik untuk terus menggunakan sesuatu yang lama. Walaupun tentunya ada variasi antara syarikat dan kegunaan sistem, sebagai garis panduan kasar, kecenderungan adalah untuk membuat keputusan pengurusan untuk memperbaharui kepada sesuatu yang baru setelah menggunakan satu sistem selama kira-kira 10 tahun.

Dalam tempoh 10 tahun, prestasi komputer yang beredar di pasaran juga akan berubah secara drastik. Oleh itu, misalnya, program yang tidak dapat dilaksanakan 10 tahun lalu kerana batasan seperti kelajuan pemprosesan komputer (walaupun dari sudut pandang manusia ia adalah reka bentuk yang mudah dan cemerlang) mungkin boleh dilaksanakan sekarang. Selain itu, jika anda telah menggunakan sistem yang sama selama 10 tahun, aliran kerja perniagaan syarikat dan peraturan dalaman mungkin telah berubah banyak. Kod yang telah dilaksanakan selepas itu untuk menyesuaikan dengan perubahan persekitaran pengurusan dalaman dan luaran syarikat mungkin telah menjadi struktur yang rumit dan berbelit-belit yang tidak dapat dikenalpasti dari sisi skrin. Dalam keadaan ini, walaupun pengguna mungkin ingin menambah fungsi, dari sudut pandang pembangun, mungkin sudah tidak mungkin untuk menambah pelaksanaan.

Sistem yang lama mungkin secara beransur-ansur menyebabkan jurutera IT melakukan banyak “kerja manual” (seperti mengeluarkan query untuk mengekstrak data secara individu). Ironinya, sistem itu sendiri, seiring dengan penuaan, akan membuat kerja menjadi “personalized”. Apabila kerja yang berkaitan dengan sistem yang telah menjadi terlalu lama dan banyak kerja yang dipersonalisasikan muncul, projek “pembangunan sistem baru untuk beralih dari sistem lama” akan dimulakan sebagai langkah untuk “sistematisasi” lebih lanjut.

Pembangunan sistem baru berjalan seiring dengan penghapusan sistem lama

Seperti yang telah disebutkan sebelumnya, walaupun tidak semua projek pembangunan sistem seperti ini, banyak projek pembangunan sistem yang juga melibatkan aspek migrasi dari sistem lama. Sistem itu sendiri sering kali berubah secara tidak berkesinambungan pada suatu hari tertentu.

Namun, proses kerja harian harus berlanjut secara berkesinambungan dari masa lalu ke masa kini, dan dari masa kini ke masa depan. Sementara data masa lalu disimpan sebanyak yang diperlukan, proses kerja masa kini harus berlanjut tanpa gangguan, dan selanjutnya, ada banyak tantangan yang sering kali terlibat dalam transisi ke sistem baru, seperti merumuskan konsep ‘sistematisasi’ yang unggul untuk masa depan. Karena kombinasi dari berbagai faktor ini, pengembangan sistem baru dan operasi dan pemeliharaan sistem yang ada menjadi saling terkait secara kompleks, dan dalam beberapa kasus, mereka menjadi saling tergantung yang tidak dapat dipisahkan.

Apa Itu Langkah-langkah Migrasi ke Sistem Baru

Saat beralih dari sistem lama ke sistem baru, yang sangat penting adalah memindahkan data dengan tepat. Langkah-langkah dalam memindahkan data biasanya berlangsung sesuai prosedur berikut.

1. Menentukan data mana dari sistem lama yang harus dipindahkan ke sistem baru → Anda juga perlu menentukan data mana yang harus mudah dicari dari layar sistem baru, dan data mana yang mungkin tidak perlu dicari dari layar, tetapi harus dapat ditarik keluar jika diperlukan (misalnya, untuk audit).
2. Ekspor data yang telah ditentukan dalam langkah 1 ke sistem baru dalam format seperti file CSV.
3. Impor data yang telah diekstrak dalam langkah 2 ke sistem baru.
4. Verifikasi apakah data yang diimpor dalam langkah 3 telah tercermin dalam sistem baru, dan periksa apakah migrasi telah dilakukan dengan benar. → Hasil verifikasi apakah migrasi telah berhasil biasanya dicatat sebagai bukti melalui tampilan layar atau cetakan laporan (proses pengujian yang biasa).

Peralihan ke sistem baru adalah sukar untuk mengatur peranan pengguna dan vendor

Dalam langkah-langkah pemindahan data yang disebutkan sebelum ini, masalah yang sering timbul adalah sejauh mana pihak pengguna harus menganggapnya sebagai masalah dalaman syarikat dan harus diletakkan di bawah pengurusan mereka. Selain itu, untuk penjelasan umum tentang “kewajipan kerjasama pengguna” dalam projek pembangunan sistem secara keseluruhan, bukan hanya dalam konteks pemindahan data, sila rujuk artikel di bawah ini.

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

Dalam projek pembangunan sistem secara umum, memang benar bahawa vendor sering kali lebih unggul daripada pengguna dalam aspek pengetahuan pakar untuk pembangunan sistem (atau lebih tepat lagi, ini sering kali adalah sebab mereka diberi tugas). Namun, sebaliknya, sering kali hanya pihak pengguna yang dapat membincangkan “cara sepatutnya” sistem syarikat mereka.

Mengambil kira aspek-aspek ini, kita boleh mempertimbangkan pengaturan peranan di mana pengguna melakukan langkah 1 dan 4 yang disebutkan sebelum ini. Jika kita ingin mengatakannya dengan cara yang berbeza, kita boleh mengatakan bahawa “definisi keperluan” data yang harus dipindahkan dan “penerimaan” sama ada data telah dipindahkan mengikut keperluan adalah kewajipan kerjasama pengguna. Atau, sebagai cara pengaturan yang berbeza, jika ada orang di pihak pengguna yang mempunyai pengetahuan yang luas tentang sistem lama yang berkaitan, kita boleh mempertimbangkan untuk menjadikan langkah 2 sebagai tanggungjawab pihak pengguna.

Jika kita boleh menangani isu sistem lama di dalam syarikat tanpa perlu menghantar ke luar, kita mungkin ingin menghantar hanya isu sistem baru ke vendor. Dalam cara ini, dalam kerja pemindahan data, pengaturan peranan antara pengguna dan vendor kadang-kadang boleh menjadi kabur. Selain itu, untuk penjelasan umum tentang peranan yang diharapkan dari vendor dan kewajipan undang-undang yang akan diberikan kepada mereka apabila pengguna menghantar kerja berkaitan pembangunan sistem ke vendor, sila rujuk juga artikel di bawah ini.

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

Contoh Kehakiman Lampau Berkaitan dengan Peralihan ke Sistem Baru

Ada kes di mana masalah sebenar berlaku dalam projek pembangunan sistem yang bertujuan untuk beralih ke sistem baru, dan menjadi kes mahkamah. Kes yang dirujuk dalam penghakiman berikut melibatkan kegagalan dalam operasi peralihan data semasa peralihan ke sistem baru, menyebabkan ketidakseragaman dan bug data, dan juga kelewatan dalam tempoh penyerahan. Isu yang dipertikaikan adalah tanggungjawab yang harus dipikul oleh pihak vendor dan pengguna terhadap projek tersebut. Sebagai kesimpulan, mahkamah telah menunjukkan kewajipan berikut yang sepatutnya dipikul oleh pihak vendor, dan mengakui pelanggaran kewajipan berhati-hati oleh pihak vendor.

Defendan, dalam menjalankan tugas peralihan data berdasarkan kontrak ini, bukan sahaja perlu memindahkan data dari sistem lama ke sistem baru, tetapi juga mempunyai kewajipan untuk menjalankan sistem baru dengan data yang dipindahkan. Secara khusus, sebelum memulakan tugas peralihan data, defendan perlu menyiasat dan menganalisis data yang akan dipindahkan dari sistem lama, memahami sifat dan keadaan data, mempertimbangkan sama ada data tersebut akan menjadi halangan kepada operasi sistem baru setelah dipindahkan, dan jika ia menjadi halangan, menentukan bila dan bagaimana data tersebut akan diperbaiki, sebelum memulakan tugas peralihan data (perancangan peralihan, pembangunan alat peralihan, peralihan data), dan akhirnya, mempunyai kewajipan untuk menjalankan sistem baru dengan data yang dipindahkan dari sistem lama.

Adalah wajar untuk mengakui bahawa dalam kes ini, defendan mempunyai kewajipan untuk membetulkan dan mengatasi ketidakseragaman data semasa peralihan data.

Keputusan Mahkamah Tokyo, 30 November 2016 (Heisei 28)

Kes ini sebenarnya melibatkan pengguna yang mengambil alih langkah 1 dan langkah 4, dan vendor yang mengambil alih langkah 2 dan langkah 3. Dengan kata lain, vendor telah menerima tugas pengeluaran data dari sistem lama (langkah 2). Oleh itu, mahkamah juga memutuskan bahawa jika vendor, sebagai pakar dalam pembangunan sistem, telah menerima tugas pengeluaran data, mereka seharusnya telah mempertimbangkan sama ada operasi pengeluaran data tersebut dapat dilakukan dengan lancar atau tidak.

Namun, bagaimana jika pengguna telah mengambil alih langkah 2 (iaitu, pengeluaran data) sebagai tugas mereka dan telah gagal dalam operasi pengeluaran? Dalam kes ini, mungkin pengguna yang tidak melakukan penyelidikan awal untuk menentukan sama ada pengeluaran data dapat dilakukan dengan lancar atau tidak, dan ini menyebabkan kelewatan dalam tempoh penyerahan, dan sekarang pengguna mungkin dituduh melanggar kewajipan kerjasama.

Selain itu, keputusan seperti ini tidak semestinya hanya berdasarkan kontrak, tetapi juga berdasarkan minit mesyuarat yang disesuaikan dengan kemajuan pembangunan sistem. Kepentingan minit mesyuarat dijelaskan secara terperinci dalam artikel di bawah.

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

Rumusan

Projek pembangunan sistem adalah sesuatu yang harus diteruskan dengan komunikasi yang teliti antara pengguna dan vendor, di mana kedua-dua pihak mempunyai banyak tanggungjawab. Oleh itu, dalam kes mahkamah yang disebutkan sebelum ini, hanya dengan sedikit perubahan dalam prasyarat, objek yang dipertanggungjawabkan boleh dengan mudah berbalik antara pengguna dan vendor.

Mengingat kemungkinan sistem yang mempunyai data yang sangat besar dan mekanisme yang rumit yang tidak dapat dibayangkan dari penampilan luaran skrin, dan kemungkinan perubahan besar dalam arah keputusan kehakiman akhir dari perbezaan prasyarat yang sedikit, penting untuk melihat pengurusan risiko projek pembangunan sistem baru secara menyeluruh bersama dengan penghapusan sistem lama.