Phương pháp xử lý khi công việc phát triển hệ thống bị gián đoạn do lý do của người dùng là gì?

Công việc phát triển hệ thống thường là dự án kéo dài trong thời gian dài. Vậy nếu người dùng từ một phía nói rằng “không cần phải tạo hệ thống đó nữa” đối với việc phát triển hệ thống mà họ đã bắt đầu, thì nhà cung cấp, người đã nhận công việc, có thể làm gì?

Bài viết này sẽ sắp xếp các đặc điểm của hợp đồng phát triển hệ thống và giải thích các biện pháp ứng phó trong trường hợp đó.

Ý nghĩa của việc suy nghĩ về việc gián đoạn do người dùng

Hợp đồng phát triển hệ thống có một số điểm đặc biệt khi xem xét dưới góc độ hợp đồng. Một trong số đó là việc thời gian thực hiện thường kéo dài, và nhà cung cấp có nghĩa vụ quản lý dự án với một lượng lớn quyền tự quyết và nghĩa vụ. Nội dung tổng thể về nghĩa vụ quản lý dự án mà nhà cung cấp phải chịu trách nhiệm được giải thích chi tiết trong bài viết dưới đây.

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

Ngoài ra, một điểm khác là người dùng, mặc dù là khách hàng, cũng có nghĩa vụ hợp tác rộng rãi với công việc của nhà cung cấp. Đối với hệ thống được sử dụng bên trong công ty, không thể chỉ “giao hết” cho nhà cung cấp. Cả bên trong công ty cũng có nghĩa vụ hợp tác thích hợp để nhà cung cấp có thể phát huy chuyên môn và tiếp cận công việc. Điều này được giải thích chi tiết trong bài viết dưới đây.

Nếu tóm tắt nội dung trên ở đây, giữa nhà cung cấp và người dùng, không chỉ có mối quan hệ đối tác giữa “nhà thầu ngoài” phát triển hệ thống và “khách hàng” trả tiền, mà còn có một khía cạnh khác, như là “đồng đội” cần hợp tác để đạt được mục tiêu chung của dự án. Sự phức tạp của mối quan hệ này thường không có trong các nhà may đo đơn giản như may đo trang phục, và đó cũng là một đặc điểm lớn của hợp đồng liên quan đến phát triển hệ thống. Các tranh chấp liên quan đến phát triển hệ thống do sự phức tạp của mối quan hệ này, một khi bị rối, việc sắp xếp quan hệ giữa hai bên theo pháp luật sẽ trở nên phức tạp và dễ bị rối.

Việc suy nghĩ về vấn đề làm thế nào để hiểu quan hệ quyền và nghĩa vụ giữa hai bên khi người dùng thay đổi ý định và nói đột ngột rằng “cuối cùng thì hệ thống đó không cần thiết nữa, vì vậy không cần tiếp tục dự án nữa” có ý nghĩa trong việc đưa ra ví dụ thực tế về việc áp dụng tư duy pháp lý trước mối quan hệ hợp đồng phức tạp như vậy. Dưới đây, tôi sẽ tổ chức các vấn đề cần xem xét sau khi xem xét trường hợp như vậy.

Đầu tiên, hãy tổ chức lại lý do đã đề xuất hủy bỏ

Từ góc nhìn của nhà cung cấp, có những trường hợp mà “người dùng muốn dừng dự án một cách đơn phương”, nhưng không nhất thiết là người dùng cũng chia sẻ cùng quan điểm đó. Ví dụ, giả sử rằng một dự án phát triển hệ thống quản lý nhân sự cho nhân viên công tác tại các cơ sở nước ngoài đã được khởi xướng, nhưng sau đó kế hoạch mở rộng ra nước ngoài đã bị rút lại, và việc phát triển hệ thống như vậy đã trở nên không cần thiết. Quả thật, chỉ nhìn vào lời giải thích này, có thể hiểu rằng đây là sự thay đổi ý kiến đơn phương từ phía người dùng.

Tuy nhiên, nếu như quá trình dẫn đến quyết định như vậy có sự thực tế vi phạm nghĩa vụ quản lý dự án như sự chậm trễ của từng giai đoạn từ phía nhà cung cấp, và việc phát triển chính của dự án đã gặp khó khăn, thì điều gì sẽ xảy ra nếu điều này cũng là một trong những nguyên nhân thay đổi chính sách của công ty?

Như đã nói ở trên, việc phát triển hệ thống là một quá trình mà cả nhà cung cấp và người dùng đều phải chịu nhiều nghĩa vụ và phải hợp tác chặt chẽ để tiến triển. Vì vậy, ngay cả khi người dùng là người muốn dừng lại và nhà cung cấp cho rằng đây là việc hủy bỏ do lợi ích cá nhân của người dùng, họ cũng nên nhận thức được rằng có khả năng bị chỉ trích về nguyên nhân thuộc về nhà cung cấp, và có thể bị đòi hỏi việc hủy bỏ dựa trên việc không thực hiện nghĩa vụ hoặc hủy bỏ theo thỏa thuận.

Sự phân biệt giữa việc hủy bỏ do lợi ích cá nhân, việc hủy bỏ dựa trên việc không thực hiện nghĩa vụ, hoặc việc hủy bỏ theo thỏa thuận, thường được đánh giá riêng biệt cho từng trường hợp dựa trên tình hình tiến triển của dự án và quá trình đàm phán trước đó. Do đó, nếu nhà cung cấp tiến hành xử lý sau cùng dựa trên quan điểm rằng đây là việc hủy bỏ do lợi ích cá nhân của người dùng, họ nên ghi chép rõ ràng về điều này trong biên bản họp, để tránh xung đột về điểm này sau này.

Xác nhận điều khoản cơ sở cho yêu cầu phí và bồi thường thiệt hại tiếp theo

Sau khi xem xét các điểm trên, nếu có thể tiếp tục cuộc thảo luận dưới dạng hủy bỏ do nguyên nhân cá nhân của người dùng, tiếp theo, chúng ta sẽ xem xét liệu có thể yêu cầu phí hoàn thành theo tỷ lệ hoặc yêu cầu bồi thường thiệt hại từ nhà cung cấp đến người dùng hay không.

Điều khoản cần tham khảo trong trường hợp này sẽ khác nhau tùy thuộc vào loại hợp đồng. Hợp đồng liên quan đến phát triển hệ thống, nói chung, có thể phân biệt thành hợp đồng thầu và hợp đồng ủy quyền.

Và, trong trường hợp hợp đồng ủy quyền và hợp đồng thầu, Luật dân sự Nhật Bản quy định như sau:

a.) Trường hợp hợp đồng ủy quyền
Yêu cầu phí: Điều 648, Điều 3 của Luật dân sự Nhật Bản
Khi việc thực hiện kết thúc giữa chừng do nguyên nhân không thể quay trở lại người nhận ủy quyền, người nhận ủy quyền có thể yêu cầu phí tương ứng với tỷ lệ đã thực hiện.
Yêu cầu bồi thường thiệt hại: Điều 651 của Luật dân sự Nhật Bản
1. Ủy quyền có thể được hủy bỏ bất cứ lúc nào bởi mỗi bên liên quan.
2. Khi một trong các bên liên quan hủy bỏ ủy quyền vào thời điểm không lợi cho bên kia, bên đó phải bồi thường thiệt hại cho bên kia. Tuy nhiên, điều này không áp dụng khi có lý do không thể tránh khỏi.

b.) Trường hợp hợp đồng thầu
Yêu cầu bồi thường thiệt hại: Điều 641 của Luật dân sự Nhật Bản
Trong khi người thầu chưa hoàn thành công việc, người đặt hàng có thể hủy bỏ hợp đồng bất cứ lúc nào bằng cách bồi thường thiệt hại.

Ngoài ra, phạm vi bồi thường thiệt hại dựa trên Điều 641 của Luật dân sự Nhật Bản được cho là bao gồm không chỉ chi phí đã chi trả mà còn cả “lợi nhuận mà sẽ được thu được nếu hợp đồng không bị hủy bỏ”. Điều này phản ánh quan điểm rằng việc buộc phải hoàn thành công việc mà từ quan điểm của người đặt hàng đã trở nên không cần thiết là vô nghĩa, do đó, trong trường hợp như vậy, việc đảm bảo lợi ích cho bên nhận đơn hàng thông qua việc thanh toán một số tiền tương đương là hợp lý.

Tuy nhiên, đối với bồi thường thiệt hại dựa trên Điều 641 của Luật dân sự Nhật Bản, không ít trường hợp trong hợp đồng riêng giữa nhà cung cấp và người dùng, các mục tiêu bồi thường thiệt hại đã bị loại trừ. Trong trường hợp như vậy, lời hứa giữa các bên liên quan ( = hợp đồng) được ký kết riêng lẻ sẽ ưu tiên, và các quy định của Luật dân sự Nhật Bản sẽ không được áp dụng, do đó cần chú ý.

Tiếp tục chứng minh khối lượng công việc hoàn thành và thiệt hại

Trong trường hợp hủy bỏ do nguyện vọng của người dùng, điều thường thấy trong hợp đồng là quy định cho phép yêu cầu phí dịch vụ cho khối lượng công việc hoàn thành (tức là phần đã hoàn tất) và yêu cầu bồi thường thiệt hại. Do đó, thông thường, từ phía nhà cung cấp, cần phải chứng minh khối lượng công việc hoàn thành và thiệt hại để đưa ra yêu cầu bồi thường thiệt hại.

Tuy nhiên, việc chứng minh khối lượng công việc hoàn thành, tức là tỷ lệ hoàn thành, có thể trở thành công việc khá khó khăn khi thực hiện thực tế. Bởi vì, việc xác định mức độ hoàn thành của từng mục công việc, đặc biệt khi có nhiều nhà thầu phụ, có thể dẫn đến một lượng lớn phỏng vấn để kiểm tra tiến độ. Hơn nữa, việc tạo tài liệu để xác nhận kết quả phỏng vấn và việc văn bản hóa nội dung phỏng vấn có thể tạo ra một lượng công việc lớn. Nếu cuối cùng việc chứng minh vẫn không đủ, rủi ro là tất cả công sức bỏ ra để chuẩn bị chứng minh có thể trở thành công cốc, điều này cũng tạo ra nhiều khó khăn.

Xem xét những điểm này, một biện pháp có thể là, từ giai đoạn hợp đồng ban đầu, rõ ràng ghi chú rằng nếu hủy bỏ giữa chừng, sẽ tính toán theo tỷ lệ ngày cho đến thời điểm hủy bỏ, để có thể thực hiện các phép tính đơn giản. Ngoài ra, xem xét việc yêu cầu bồi thường cho khối lượng công việc hoàn thành mất nhiều công sức để chứng minh, một phương pháp khác có thể là từ bỏ việc yêu cầu bồi thường cho khối lượng công việc hoàn thành và thay vào đó xem xét việc yêu cầu bồi thường cho “chi phí đã phát sinh cho phần công việc đã hoàn thành”. Nếu là chi phí phát triển nội bộ, thì có thể dễ dàng tính toán bằng công thức đơn giản “số giờ làm việc x đơn giá”. Đặc biệt đối với các dự án có tỷ suất lợi nhuận thấp, việc ưu tiên yêu cầu bồi thường dựa trên chi phí thay vì khối lượng công việc hoàn thành có thể giúp dễ dàng thu hồi nợ hơn và bù đắp thiệt hại, do đó có thể trở thành một biện pháp cứu trợ thực tế trong nhiều trường hợp.

Điều gì cần được xem xét từ phía người dùng?

Điều đáng chú ý là, từ phía người dùng khi muốn hủy hợp đồng do lý do cá nhân, cũng có những điểm cần được xem xét trước. Đó là, giữa bạn và nhà cung cấp, bạn nên xác định trước một số tiền bồi thường dự kiến mà bạn cần phải trả. Khi chúng tôi nói “ước lượng”, ý của chúng tôi là đặt một mục tiêu chung để có thể dự đoán hướng của cuộc thương lượng sau này (nếu việc thể hiện ý định hủy hợp đồng bị trễ, mọi thứ sẽ trở nên ngược đời, vì vậy không cần thiết phải là một số tiền chính xác).

Nếu số tiền ước lượng mà bạn đã xác định được coi là quá cao, bạn nên yêu cầu giải thích lý do. Tuy nhiên, nếu bạn cố gắng thương lượng một cách quá đáng để giảm số tiền phải trả, có thể sẽ dẫn đến những vụ kiện vô nghĩa và làm tình hình càng trở nên phức tạp hơn. Nếu việc thương lượng chỉ giữa hai bên trở nên khó khăn, việc tìm kiếm lời khuyên từ một luật sư cũng có thể là một giải pháp.

Đáng chú ý là, trong bài viết này, chúng tôi đã giả định rằng hợp đồng liên quan đến phát triển hệ thống đã được thiết lập. Tuy nhiên, trong thực tế của việc phát triển hệ thống, có không ít trường hợp mà việc “hợp đồng có được thiết lập một cách hợp lệ hay không” trở thành vấn đề tranh chấp. Chúng tôi đã giải thích chi tiết về điều này trong bài viết dưới đây.

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

Tóm tắt

Trong bài viết này, chúng tôi đã giải thích quy trình xử lý vấn đề khi dự án bị gián đoạn do lý do của người dùng. Tuy nhiên, điểm quan trọng nhất của bài viết này là việc cần xem xét liệu có thể nói rằng đây thực sự là lý do của người dùng hay không, và liệu phía nhà cung cấp có thực sự không có lỗi hay không.

Đặc điểm của dự án phát triển hệ thống là cả nhà cung cấp và người dùng đều phải chịu trách nhiệm lớn. Vì vậy, nếu không xem xét kỹ trước liệu có thể đổ lỗi một cách một chiều cho đối tác hay không, có thể dẫn đến tình huống càng thêm dầu vào lửa. Điều này cần được ý thức rõ.