Vấn đề pháp lý liên quan đến việc chuyển đổi từ hệ thống cũ trong phát triển hệ thống

Việc tạo ra hệ thống IT mới cho doanh nghiệp là một trong những lĩnh vực tiêu biểu của các kỹ sư IT. Tuy nhiên, khi nói đến “tạo ra hệ thống mới”, thường đi kèm với quá trình “loại bỏ hệ thống đã được sử dụng trước đây”. Trong bài viết này, chúng tôi sẽ giải thích về các vấn đề pháp lý liên quan đến việc này, bằng cách nhìn nhận lại dự án phát triển hệ thống mới từ góc độ “loại bỏ hệ thống cũ”.

Chuyển đổi sang hệ thống mới có nghĩa là gì?

Tuổi thọ của hệ thống IT không phải là vĩnh cửu

Hệ thống IT được sử dụng trong doanh nghiệp không phải là thứ mà một khi đã tạo ra thì có thể sử dụng mãi mãi. Thậm chí, việc tiếp tục sử dụng những thứ cũ kỹ không phải lúc nào cũng tốt. Mặc dù có sự khác biệt tùy thuộc vào từng doanh nghiệp và mục đích sử dụng của hệ thống, nhưng một cách tổng quát, sau khoảng 10 năm sử dụng một hệ thống, có xu hướng ra quyết định quản lý là nên thay thế bằng một cái mới.

Sau 10 năm, hiệu suất của máy tính trên thị trường cũng đã thay đổi hoàn toàn. Vì vậy, có thể có những chương trình mà 10 năm trước, dù có thiết kế đơn giản và xuất sắc (từ góc độ con người) nhưng không thể triển khai do hạn chế về tốc độ xử lý của máy tính, giờ đây có thể đã trở nên khả thi. Ngoài ra, nếu bạn đã sử dụng một hệ thống từ khi tạo ra cho đến 10 năm sau, quy trình công việc và quy tắc nội bộ của công ty có thể đã thay đổi đáng kể. Các đoạn mã được triển khai sau để đáp ứng sự thay đổi trong môi trường quản lý nội và ngoại của công ty có thể đã trở nên phức tạp và rắc rối đến mức không thể nhận biết từ màn hình. Khi điều này xảy ra, ngay cả khi người dùng muốn thêm chức năng, có thể đã trở nên không thể thực hiện thêm từ góc độ của nhà phát triển.

Hệ thống cũ có thể dần dần tạo ra nhiều “công việc thủ công” cho các kỹ sư IT (ví dụ như việc phát hành truy vấn để trích xuất dữ liệu riêng lẻ). Chính hệ thống cũng, một cách mỉa mai, khiến công việc trở nên “phụ thuộc vào cá nhân”. Khi một hệ thống trở nên quá cũ và công việc liên quan đến hệ thống có nhiều công việc phụ thuộc vào cá nhân, khi cố gắng áp dụng biện pháp “hệ thống hóa” thêm, dự án “phát triển hệ thống mới để chuyển đổi từ hệ thống cũ” sẽ được khởi xướng.

Việc phát triển hệ thống mới tiến triển cùng với việc loại bỏ hệ thống cũ

Như đã nêu ở trên, dù không phải tất cả các dự án phát triển hệ thống đều như vậy, nhưng nhiều dự án phát triển hệ thống thường cùng lúc mang tính chất chuyển đổi từ hệ thống cũ. Hệ thống tự thân thường thay đổi một cách không liên tục vào một ngày nào đó.

Tuy nhiên, việc tiến hành công việc hàng ngày nên liên tục từ quá khứ đến hiện tại, từ hiện tại đến tương lai. Trong khi lưu trữ dữ liệu quá khứ cần thiết, không làm gián đoạn tiến trình công việc hiện tại, và đưa ra ý tưởng “hệ thống hóa” xuất sắc hướng tới tương lai, việc chuyển đổi sang hệ thống mới thường đi kèm với nhiều thách thức. Do những tình huống này kết hợp với nhau một cách phức tạp, việc phát triển hệ thống mới và các công việc như vận hành và bảo dưỡng hệ thống hiện có trở nên phức tạp liên quan đến nhau, và có thể tạo ra mối quan hệ không thể tách rời.

Các bước chuyển đổi sang hệ thống mới

Khi chuyển đổi từ hệ thống cũ sang hệ thống mới, điều đặc biệt quan trọng là việc chuyển đổi dữ liệu một cách phù hợp. Các bước chuyển đổi dữ liệu thường tuân theo các quy trình sau đây.

1. Xác định rõ ràng dữ liệu nào trong số dữ liệu được lưu trữ bởi hệ thống cũ nên được chuyển đổi sang hệ thống mới → Dữ liệu nào nên dễ dàng tìm kiếm từ màn hình của hệ thống mới, và dữ liệu nào không cần tìm kiếm từ màn hình nhưng nên có thể truy cập khi cần thiết (như trong quá trình kiểm toán) cũng cần được xác định.
2. Xuất dữ liệu cần được nhập vào hệ thống mới từ dữ liệu đã xác định ở bước 1 dưới dạng tệp CSV hoặc định dạng tương tự.
3. Nhập dữ liệu đã trích xuất ở bước 2 vào hệ thống mới.
4. Kiểm tra xem dữ liệu đã được nhập vào từ bước 3 có được phản ánh trong hệ thống mới hay không, và xác nhận xem việc chuyển đổi đã được thực hiện đúng hay không. → Kết quả kiểm định việc chuyển đổi đúng hay không thường được lưu lại dưới dạng tài liệu chứng minh thông qua màn hình hiển thị hoặc in ấn (quá trình kiểm tra).

Việc chuyển đổi sang hệ thống mới thường gặp khó khăn trong việc phân chia vai trò giữa người dùng và nhà cung cấp

Trong các bước chuyển đổi dữ liệu đã nêu trước đây, vấn đề thường gặp là phía người dùng không biết đến mức độ nào họ nên xem đó là vấn đề nội bộ của công ty và cần quản lý. Ngoài ra, không chỉ riêng vấn đề chuyển đổi dữ liệu, về “nghĩa vụ hợp tác của người dùng” trong dự án phát triển hệ thống nói chung, vui lòng tham khảo bài viết dưới đây.

Nói chung, trong dự án phát triển hệ thống, nhà cung cấp thường có nhiều ưu thế hơn người dùng về kiến thức chuyên môn trong việc phát triển hệ thống (hoặc thậm chí, đó chính là lý do họ được giao công việc). Tuy nhiên, mặt khác, việc thảo luận về “hình mẫu lý tưởng” của hệ thống của công ty thường chỉ có thể được thực hiện bởi phía người dùng.

Xét về khía cạnh đó, có thể xem xét việc phân chia vai trò là người dùng sẽ thực hiện các bước 1 và 4 đã nêu trước đây. Nếu nói cách khác, trong quá trình chuyển đổi toàn bộ dữ liệu, việc “định rõ yêu cầu” cho dữ liệu cần chuyển đổi và việc “kiểm tra” xem dữ liệu đã được chuyển đổi đúng yêu cầu hay chưa có thể được xem là nghĩa vụ hợp tác của người dùng. Hoặc, như một cách phân chia vai trò khác, nếu có người trong số người dùng có kiến thức sâu rộng về hệ thống cũ, họ cũng có thể được giao bước 2.

Nếu không cần phải thuê ngoài, và có thể xử lý vấn đề về hệ thống cũ bên trong công ty, có thể xem xét việc chỉ thuê ngoài phần liên quan đến hệ thống mới từ nhà cung cấp. Trong trường hợp như vậy, trong công việc chuyển đổi dữ liệu, vai trò của người dùng và nhà cung cấp đôi khi có thể trở nên mơ hồ. Ngoài ra, khi người dùng thuê ngoài công việc liên quan đến phát triển hệ thống từ nhà cung cấp, vui lòng tham khảo bài viết dưới đây để hiểu rõ hơn về những vai trò thường được kỳ vọng ở nhà cung cấp và những nghĩa vụ pháp lý nào sẽ thuộc về họ.

Các vụ kiện trong quá khứ liên quan đến việc chuyển đổi sang hệ thống mới

Trong các dự án phát triển hệ thống nhằm mục đích chuyển đổi sang hệ thống mới, thực tế đã có những trường hợp xảy ra rắc rối và trở thành vụ kiện. Vụ việc được trích dẫn trong bản án dưới đây là một trường hợp mà trong quá trình chuyển đổi dữ liệu, việc chuyển đổi đã thất bại, dẫn đến sự không nhất quán của nhiều dữ liệu và lỗi trong hệ thống mới, gây ra sự chậm trễ trong thời hạn giao hàng. Các vấn đề tranh chấp liên quan đến những rắc rối như vậy là trách nhiệm mà bên cung cấp và bên sử dụng đều phải gánh chịu đối với dự án. Kết quả cuối cùng là, tòa án đã xác định rằng bên cung cấp đã vi phạm nghĩa vụ chú ý mà họ nên thực hiện, và đã chỉ ra nội dung sau đây.

Bên bị đơn, trong việc chuyển đổi dữ liệu dựa trên hợp đồng thầu này, không chỉ đơn thuần là chuyển dữ liệu từ hệ thống cũ sang hệ thống mới, mà còn có nghĩa vụ vận hành hệ thống mới bằng dữ liệu đã chuyển đổi, cụ thể là, trước khi bắt đầu công việc chuyển đổi dữ liệu, họ đã nghiên cứu và phân tích dữ liệu mà sẽ được chuyển từ hệ thống cũ, hiểu rõ tính chất và tình trạng của dữ liệu, và đã xem xét liệu dữ liệu đó có trở thành trở ngại cho việc vận hành sau khi được chuyển sang hệ thống mới hay không, và nếu có trở ngại, họ đã quyết định khi nào và bằng phương pháp nào để sửa dữ liệu đó, sau đó tiến hành công việc chuyển đổi dữ liệu (thiết kế chuyển đổi, phát triển công cụ chuyển đổi, chuyển đổi dữ liệu), và cuối cùng, họ đã chịu trách nhiệm vận hành hệ thống mới bằng dữ liệu đã chuyển từ hệ thống cũ.

Điều này là phù hợp, và trong trường hợp này, khi chuyển đổi dữ liệu, họ nên chịu trách nhiệm sửa chữa và giải quyết sự không nhất quán của dữ liệu.

Tòa án Tokyo, ngày 30 tháng 11 năm 2016 (Heisei 28)

Vụ việc này là một trường hợp mà bên sử dụng đã đảm nhận bước 1 và bước 4, trong khi bên cung cấp đã đảm nhận bước 2 và bước 3. Nói cách khác, đây là một trường hợp mà bên cung cấp đã một lần đảm nhận việc trích xuất dữ liệu từ hệ thống cũ (bước 2). Do đó, tòa án cũng đã quyết định rằng, nếu bên cung cấp (như một chuyên gia phát triển hệ thống) đã đảm nhận việc trích xuất dữ liệu, họ nên đã xem xét trước liệu việc trích xuất dữ liệu có thể được thực hiện một cách trơn tru hay không.

Tuy nhiên, nếu bước 2 (tức là việc trích xuất dữ liệu) đã được sắp xếp trước đó như một công việc của bên sử dụng, và nếu việc trích xuất dữ liệu đã thất bại trong trường hợp đó, thì điều gì sẽ xảy ra? Trong trường hợp này, có thể xem xét việc bên sử dụng đã bỏ qua việc điều tra trước liệu việc trích xuất dữ liệu có thể được thực hiện một cách trơn tru hay không, dẫn đến sự chậm trễ trong thời hạn giao hàng, và ngược lại, bên sử dụng có thể bị truy cứu vì vi phạm nghĩa vụ hợp tác.

Ngoài ra, những quyết định như vậy không chỉ dựa trên hợp đồng mà còn dựa trên biên bản họp phù hợp với tiến trình phát triển hệ thống. Tầm quan trọng của biên bản họp được giải thích chi tiết trong bài viết dưới đây.

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

Tóm tắt

Dự án phát triển hệ thống là một quá trình cần sự giao tiếp kỹ lưỡng và cả hai bên, người dùng và nhà cung cấp, đều phải chịu nhiều trách nhiệm. Do đó, trong các ví dụ phán quyết mà chúng tôi đã đề cập ở trên, chỉ cần có một chút thay đổi trong các điều kiện tiên quyết, đối tượng chịu trách nhiệm có thể dễ dàng đảo ngược giữa người dùng và nhà cung cấp.

Do có khả năng chứa một lượng lớn dữ liệu và cơ chế phức tạp mà không thể tưởng tượng được từ giao diện người dùng, cũng như khả năng thay đổi lớn trong quyết định tư pháp cuối cùng chỉ từ một sự khác biệt nhỏ trong các giả định, quản lý rủi ro của dự án phát triển hệ thống mới, cùng với việc loại bỏ hệ thống cũ, có thể nói là rất quan trọng khi xem xét một cách toàn diện.