Masalah Hukum yang Muncul dalam Migrasi dari Sistem Lama ke Sistem Baru dalam Pengembangan Sistem

Membuat sistem IT baru di perusahaan adalah bidang kerja khas seorang insinyur IT, namun dalam konteks “membuat sistem baru”, seringkali proses ini juga mencakup “menghapus sistem yang telah digunakan sebelumnya”. Dalam artikel ini, kami akan membahas berbagai masalah hukum yang terkait dengan pengembangan sistem baru, dengan sengaja melihatnya dari perspektif “penghapusan sistem lama”.

Apa yang Dimaksud dengan Migrasi ke Sistem Baru

Umur Sistem IT Tidaklah Abadi

Sistem IT yang digunakan dalam perusahaan bukanlah sesuatu yang dapat dibuat sekali lalu digunakan secara terus-menerus. Bahkan, bukan berarti selalu baik untuk terus menggunakan sesuatu yang lama. Meskipun tentu saja ada variasi antara perusahaan dan tujuan sistem, sebagai pedoman umum, kecenderungan manajemen adalah untuk membuat keputusan bahwa setelah menggunakan satu sistem selama sekitar 10 tahun, lebih baik untuk memperbarui dengan yang baru.

Dalam waktu 10 tahun, kinerja komputer yang beredar di pasar juga akan berubah secara signifikan. Dalam hal ini, misalnya, program yang tidak praktis untuk diimplementasikan karena keterbatasan seperti kecepatan pemrosesan komputer 10 tahun yang lalu (meskipun dari sudut pandang manusia, itu adalah desain yang sederhana dan unggul) mungkin sekarang dapat diimplementasikan. Selain itu, jika Anda telah terus menggunakannya selama 10 tahun sejak pembuatan, alur kerja bisnis perusahaan dan aturan internal mungkin telah berubah secara signifikan. Kode yang diimplementasikan setelahnya untuk menanggapi perubahan lingkungan bisnis internal dan eksternal perusahaan mungkin telah menjadi struktur yang rumit dan rumit yang tidak dapat dikenali dari sisi layar. Dalam hal ini, mungkin ada situasi di mana, meskipun pengguna ingin menambahkan fungsi, dari sudut pandang pengembang, implementasi tambahan sudah tidak mungkin.

Sistem yang sudah tua mungkin secara bertahap menyebabkan banyak “pekerjaan manual” bagi insinyur IT (misalnya, operasi seperti mengeluarkan query untuk mengekstrak data secara individual). Ironisnya, sistem itu sendiri, seiring bertambahnya usia, akan membuat pekerjaan menjadi “personal”. Ketika mencoba mengambil langkah-langkah “sistematisasi” lebih lanjut terhadap pekerjaan yang terkait dengan sistem yang telah menjadi terlalu tua dan memiliki banyak pekerjaan personal, proyek “pengembangan sistem baru untuk beralih dari sistem lama” akan dimulai.

Pengembangan Sistem Baru Berjalan Seiring dengan Penghapusan Sistem Lama

Seperti yang telah disebutkan sebelumnya, meskipun tidak semua proyek pengembangan sistem seperti ini, banyak proyek pengembangan sistem yang juga memiliki aspek transisi dari sistem lama. Sistem itu sendiri sering kali berubah secara diskontinu pada suatu hari tertentu.

Namun, proses kerja sehari-hari harus berlanjut secara terus menerus dari masa lalu ke masa kini, dan dari masa kini ke masa depan. Sementara data masa lalu disimpan sebanyak yang diperlukan, proses kerja saat ini harus berlanjut tanpa hambatan, dan selanjutnya, sering kali ada berbagai tantangan yang menyertai transisi ke sistem baru, seperti merumuskan konsep ‘sistematisasi’ yang unggul untuk masa depan. Karena berbagai situasi ini berpadu secara kompleks, pengembangan sistem baru dan operasi dan pemeliharaan sistem yang ada menjadi saling terkait secara kompleks, dan dalam beberapa kasus, mereka menjadi hubungan yang tidak dapat dipisahkan.

Apa Itu Langkah-langkah Migrasi ke Sistem Baru

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

1. Mengidentifikasi data mana dari sistem lama yang harus dimigrasikan ke sistem baru → Anda 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 diambil jika diperlukan (misalnya, untuk audit).
2. Ekspor data yang telah diidentifikasi pada langkah 1 ke sistem baru dalam format seperti file CSV.
3. Impor data yang telah diekstrak pada langkah 2 ke sistem baru.
4. Verifikasi apakah data yang telah diimpor pada langkah 3 telah direfleksikan dalam sistem baru dan konfirmasi apakah migrasi telah dilakukan dengan benar. → Hasil verifikasi apakah migrasi telah berhasil biasanya dicatat sebagai bukti melalui tampilan layar atau cetakan laporan (dalam proses pengujian).

Peralihan ke Sistem Baru Menyulitkan Penjelasan Peran Pengguna dan Vendor

Dalam langkah-langkah migrasi data yang telah disebutkan sebelumnya, masalah yang sering muncul adalah sejauh mana pengguna harus menganggap ini sebagai masalah internal perusahaan mereka dan sejauh mana mereka harus mengendalikannya. Selain itu, untuk penjelasan umum tentang “kewajiban kerjasama pengguna” dalam proyek pengembangan sistem secara keseluruhan, bukan hanya migrasi data, silakan lihat artikel di bawah ini.

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

Secara umum, dalam proyek pengembangan sistem, memang benar bahwa vendor sering kali unggul dalam hal pengetahuan spesialis untuk pengembangan sistem dibandingkan pengguna (atau lebih tepatnya, ini sering kali alasan mereka diberi tugas). Namun, di sisi lain, sering kali hanya pengguna yang dapat mendiskusikan “cara seharusnya” sistem perusahaan mereka.

Mengingat hal tersebut, kita dapat mempertimbangkan penjelasan peran di mana pengguna melakukan langkah 1 dan 4 yang disebutkan sebelumnya. Jika harus mengatakannya dengan cara lain, dalam proses migrasi data, “definisi kebutuhan” data yang harus dipindahkan dan “penerimaan” apakah data telah dipindahkan sesuai dengan kebutuhan dapat diatur sebagai kewajiban kerjasama pengguna. Atau, sebagai cara lain untuk mengatur, jika ada orang di pihak pengguna yang memiliki pengetahuan yang luas tentang sistem lama, mereka juga dapat dipertimbangkan untuk bertanggung jawab atas langkah 2.

Jika kita dapat menangani sistem lama di dalam perusahaan tanpa harus mengalihkannya, kita mungkin ingin mengalihkan hanya sistem baru ke vendor. Dalam bentuk ini, dalam pekerjaan migrasi data, penjelasan peran antara pengguna dan vendor kadang-kadang menjadi ambigu. Selain itu, untuk penjelasan umum tentang peran apa yang diharapkan dari vendor dan kewajiban hukum apa yang akan mereka miliki ketika pengguna mengalihkan pekerjaan terkait pengembangan sistem ke vendor, silakan lihat artikel di bawah ini juga.

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

Contoh Kasus Hukum Terkait Migrasi ke Sistem Baru

Ada beberapa kasus di mana proyek pengembangan sistem yang bertujuan untuk migrasi ke sistem baru mengalami masalah dan berakhir di pengadilan. Kasus yang akan kami kutip di bawah ini adalah tentang kegagalan dalam proses migrasi data, yang mengakibatkan inkonsistensi data dan bug di sistem baru, serta penundaan dalam penyelesaian proyek. Pertikaian utama dalam kasus ini adalah tentang kewajiban yang harus dipenuhi oleh pihak vendor dan pengguna dalam proyek tersebut. Hasilnya, pengadilan menentukan bahwa pihak vendor telah melanggar kewajiban mereka untuk berhati-hati, dengan menunjukkan hal-hal berikut:

Defendant, dalam melakukan pekerjaan migrasi data berdasarkan kontrak ini, tidak hanya sekadar memindahkan data dari sistem lama ke sistem baru, tetapi juga memiliki kewajiban untuk menjalankan sistem baru dengan data yang telah dipindahkan. Secara spesifik, sebelum memulai pekerjaan migrasi data, mereka harus melakukan penelitian dan analisis data yang akan dipindahkan dari sistem lama, memahami karakteristik dan kondisi data tersebut, mempertimbangkan apakah data tersebut akan menjadi hambatan setelah dipindahkan ke sistem baru, dan jika itu menjadi hambatan, mereka harus menentukan kapan dan bagaimana data tersebut akan diperbaiki. Akhirnya, mereka harus melakukan pekerjaan migrasi data (perencanaan migrasi, pengembangan alat migrasi, migrasi data) dan memiliki kewajiban untuk menjalankan sistem baru dengan data yang telah dipindahkan dari sistem lama.

Hal ini pantas diakui, dan dalam kasus ini, mereka harus memiliki kewajiban untuk memperbaiki dan menghilangkan inkonsistensi data saat melakukan migrasi data.

Putusan Pengadilan Distrik Tokyo, 30 November 2016 (Tahun Heisei 28)

Kasus ini sebenarnya melibatkan pembagian tugas di mana pihak pengguna bertanggung jawab atas langkah 1 dan 4, sementara pihak vendor bertanggung jawab atas langkah 2 dan 3. Artinya, pihak vendor seharusnya bertanggung jawab atas ekstraksi data dari sistem lama (langkah 2). Oleh karena itu, pengadilan memutuskan bahwa jika vendor, sebagai spesialis pengembangan sistem, telah setuju untuk melakukan ekstraksi data, mereka seharusnya telah mempertimbangkan apakah proses ekstraksi data dapat berjalan lancar atau tidak.

Namun, bagaimana jika pihak pengguna sebelumnya telah menetapkan bahwa mereka bertanggung jawab atas langkah 2 (ekstraksi data), dan kemudian gagal dalam proses tersebut? Dalam kasus seperti ini, mungkin pengguna yang akan dituduh melanggar kewajiban kerjasama karena mereka tidak melakukan penelitian awal untuk memastikan bahwa ekstraksi data dapat berjalan lancar, yang mengakibatkan penundaan dalam penyelesaian proyek. Dalam hal ini, mungkin pengguna yang akan dituduh melanggar kewajiban kerjasama.

Selain itu, keputusan seperti ini tidak hanya didasarkan pada kontrak saja, tetapi juga pada catatan rapat yang disesuaikan dengan kemajuan pengembangan sistem. Kami telah menjelaskan secara detail tentang pentingnya catatan rapat dalam artikel berikut.

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

Kesimpulan

Proyek pengembangan sistem adalah sesuatu yang harus dilakukan dengan komunikasi yang cermat antara pengguna dan vendor, di mana kedua belah pihak memiliki banyak kewajiban. Oleh karena itu, dalam kasus hukum yang telah disebutkan sebelumnya, hanya dengan sedikit perubahan dalam prasyarat, objek yang bertanggung jawab dapat dengan mudah berbalik antara pengguna dan vendor.

Mengingat kemungkinan sistem yang memiliki data yang sangat besar dan mekanisme yang rumit yang tidak dapat dibayangkan dari penampilan layar, dan kemungkinan bahwa arah putusan hukum akhir dapat berubah secara signifikan karena sedikit perbedaan dalam prasyarat, manajemen risiko proyek pengembangan sistem baru, bersama dengan penghapusan sistem lama, harus dilihat secara komprehensif. Hal ini penting untuk ditekankan.