Hợp đồng phát triển hệ thống 2026 – khoán việc hay bán ủy thác

Phần lớn người tìm kiếm về hợp đồng phát triển hệ thống đều đang muốn có một bản mẫu dùng được ngay. Nhưng trên thực tế, tranh chấp hiếm khi bắt nguồn từ câu chữ của điều khoản. Nó bắt nguồn từ việc bốn hạng mục gồm loại hợp đồng, tiêu chí nghiệm thu, trách nhiệm do không phù hợp hợp đồng và quyền sở hữu trí tuệ bị quyết định trên những giả định không khớp nhau. Bốn hạng mục này phải được thiết kế cùng lúc như một bộ duy nhất, căn cứ vào đúng một biến số là yêu cầu đã được chốt đến mức nào. Bài viết này sắp xếp lại cách ra quyết định đó, đặt trong bối cảnh một nhà máy Nhật Bản tại Thái Lan đặt hàng phát triển hệ thống quản lý sản xuất.

Điều thực sự phải quyết trong hợp đồng phát triển hệ thống – vì sao nguyên tắc chung là chưa đủ

Bản mẫu hợp đồng thì trên mạng có bao nhiêu cũng được. Vậy mà bên đặt hàng vẫn thấy bất an, bởi bản mẫu chỉ cho biết nên đưa những điều khoản nào vào, chứ không cho biết trong hoàn cảnh của chính mình thì phải điền nội dung ra sao.

Những điểm gây rắc rối trong hợp đồng phát triển hệ thống rốt cuộc quy về bốn thứ. Thứ nhất, chọn loại hợp đồng là hợp đồng khoán việc hay hợp đồng bán ủy thác. Thứ hai, tiêu chí nghiệm thu, tức lấy gì làm căn cứ để coi là đã hoàn thành. Thứ ba, trách nhiệm do không phù hợp hợp đồng khi phát hiện lỗi sau bàn giao. Thứ tư, quyền sở hữu trí tuệ của chương trình đã hoàn thiện thuộc về bên đặt hàng hay công ty phát triển.

Điều quan trọng là bốn thứ này không phải bốn vấn đề độc lập. Cả bốn đều bị chi phối bởi cùng một biến số là yêu cầu đã được chốt đến mức nào. Vì vậy, chỉ chốt có lợi cho mình ở một điểm thì toàn bộ hợp đồng vẫn không ổn định. Ngược lại, ghép sai tổ hợp sẽ tạo ra một bản hợp đồng tự mâu thuẫn bên trong.

Mâu thuẫn điển hình nhất là ghép hợp đồng khoán việc trọn gói với tiêu chí nghiệm thu ngặt nghèo trong khi việc định nghĩa yêu cầu còn chưa chốt. Hợp đồng khoán việc là hợp đồng cam kết hoàn thành công việc, nên nếu chưa xác định được thế nào là hoàn thành thì đối tượng của cam kết cũng chưa hình thành. Viết thêm tiêu chí nghiệm thu chi tiết lên trên nền đó, thì mỗi lần công việc tiến triển lại nổ ra cùng một cuộc tranh cãi rằng thứ này vốn đã nằm trong đặc tả ban đầu hay là yêu cầu phát sinh. Bên đặt hàng nói đương nhiên phải có. Công ty phát triển nói nằm ngoài phạm vi đã thỏa thuận. Cả hai đều đúng theo cách hiểu của mình, nên câu chuyện không có điểm dừng.

Kiểu ngược lại cũng xảy ra. Yêu cầu và thiết kế màn hình đã chốt trọn vẹn, nhưng toàn bộ các giai đoạn lại được ký theo hợp đồng bán ủy thác đúng như công ty phát triển đề xuất. Trong trường hợp này, dù không hoàn thành thì vẫn phát sinh thù lao theo khối lượng nhân lực đã bỏ ra, nghĩa là bên đặt hàng gánh gần như toàn bộ rủi ro hoàn thành. Không có lý do hợp lý nào để chấp nhận điều đó khi yêu cầu đã chốt.

Nói cách khác, cuộc tranh luận chung chung rằng khoán việc hay bán ủy thác mới là đúng thì không có ý nghĩa. Cái có ý nghĩa là đánh giá trung thực xem yêu cầu của công ty mình hiện đã chốt tới đâu, rồi thiết kế cả bốn hạng mục cùng lúc cho khớp với mức độ chốt đó. Bài viết này bàn về quy trình thiết kế ấy.

Về việc cơ cấu chi phí được hình thành ra sao, chúng tôi trình bày trong bài viết phân tích cấu thành báo giá phát triển hệ thống nghiệp vụ, còn cách chọn chính nhà thầu thì nằm ở bài viết về cách chọn công ty phát triển hệ thống tại Thái Lan. Bài này không đi vào giá cả hay so sánh nhà cung cấp, mà chỉ giới hạn ở bộ khung pháp lý của hợp đồng.

Xin nói rõ ngay từ đầu. Bài viết này là hướng dẫn thực hành dành cho người phụ trách đặt hàng, không phải tư vấn pháp lý. Với nội dung của từng hợp đồng cụ thể, hoặc cách xử lý một tranh chấp cụ thể, hãy luôn xác nhận với luật sư hoặc chuyên gia.

Hợp đồng khoán việc khác hợp đồng bán ủy thác ở chỗ nào

Trước hết hãy xác nhận khác biệt giữa hai loại hợp đồng, chỉ giới hạn ở những hệ quả có ý nghĩa thực tiễn.

Hợp đồng khoán việc là hợp đồng trong đó bên nhận việc cam kết hoàn thành công việc và bên đặt hàng trả thù lao cho kết quả đó. Điểm mấu chốt là thù lao gắn với kết quả. Nếu sản phẩm đã cam kết không hoàn thành thì về nguyên tắc bên nhận việc không được yêu cầu thanh toán.

Hợp đồng bán ủy thác là hợp đồng ủy thác việc xử lý những công việc không mang tính hành vi pháp lý. Bên nhận ủy thác có nghĩa vụ xử lý công việc với sự cẩn trọng của một người quản lý mẫn cán, nhưng không cam kết bản thân việc hoàn thành sản phẩm. Thù lao về nguyên tắc được trả theo thời gian và khối lượng nhân lực đã bỏ ra. Ngoài ra, Bộ luật Dân sự sửa đổi của Nhật Bản có hiệu lực từ tháng 4 năm 2020 đã quy định thành văn cả dạng bán ủy thác trả thù lao theo thành quả, nên bán ủy thác không đồng nghĩa với việc hoàn toàn không thể định nghĩa sản phẩm bàn giao.

Các phân tích thực hành nhìn chung đều thống nhất rằng giai đoạn định nghĩa yêu cầu hợp với hợp đồng bán ủy thác. Lý do rất rõ ràng, vì định nghĩa yêu cầu chính là công việc sẽ quyết định sẽ xây dựng cái gì. Về mặt logic, không thể bắt ai đó cam kết hoàn thành một thứ chưa được xác định. Nếu vẫn ép thành hợp đồng khoán việc trọn gói, công ty phát triển sẽ chọn một trong hai đường, hoặc cộng phần bất định vào báo giá dưới dạng chi phí rủi ro, hoặc diễn giải phạm vi thật hẹp để tự vệ. Cả hai đều không có lợi cho bên đặt hàng.

Ngược lại, nếu để giai đoạn lập trình sau khi yêu cầu đã chốt vẫn nằm trong hợp đồng bán ủy thác, khối lượng nhân lực cứ chồng chất trong khi không ai chịu trách nhiệm về việc hoàn thành. Ở đây chuyển sang hợp đồng khoán việc mới là tự nhiên.

Tóm lại, hai loại hợp đồng không hơn kém nhau, mà mỗi loại hợp với một giai đoạn. Sự gượng ép sinh ra từ việc cố phủ toàn bộ quy trình bằng một hợp đồng duy nhất. Chia giai đoạn rồi đổi loại hợp đồng thì tránh được nhược điểm của cả hai.

Nên chọn loại nào – quyết định theo mức độ chốt của yêu cầu

Vậy ranh giới chuyển đổi nằm ở đâu. Tiêu chuẩn là mức độ chốt của yêu cầu. Nghe có vẻ trừu tượng, nhưng có thể phán đoán qua việc trả lời được hay không ba câu hỏi sau.

Thứ nhất, phạm vi nghiệp vụ mà hệ thống xử lý, các cơ sở và các bộ phận thuộc phạm vi đã được xác định chưa. Thứ hai, đã có danh mục các màn hình và biểu mẫu chính chưa, và với mỗi cái có liệt kê được các mục nhập liệu và mục kết xuất không. Thứ ba, các điểm kết nối với hệ thống hoặc thiết bị hiện có, tức là nối cái gì với cái gì, đã được quyết định chưa.

Nếu trả lời được cả ba, việc đặt hàng giai đoạn lập trình theo hợp đồng khoán việc sẽ không sinh ra lệch pha nghiêm trọng. Ngược lại, nếu dù chỉ một câu trả lời là sẽ bàn tiếp sau, thì phần đó nên được chốt trước trong một giai đoạn bán ủy thác.

Nhìn bảng này có thể thấy loại hợp đồng và tiêu chí nghiệm thu luôn đi cùng nhau. Nghiệm thu ở giai đoạn bán ủy thác được đánh giá theo việc sản phẩm trung gian, tức báo cáo hay tài liệu định nghĩa yêu cầu, có phản ánh những gì đã thỏa thuận hay không. Nghiệm thu ở giai đoạn khoán việc được đánh giá theo việc có đạt các bài kiểm thử gắn với tài liệu định nghĩa yêu cầu hay không. Nếu sản phẩm của giai đoạn trước chưa chốt thì tiêu chí nghiệm thu của giai đoạn sau không thể viết ra. Trình tự này không thể bỏ qua.

Một câu hỏi thường gặp trong thực tế là tách riêng phần định nghĩa yêu cầu thành hợp đồng bán ủy thác thì chi phí có tăng thêm đúng bằng phần đó không. Có tăng. Nhưng như ước tính riêng của chúng tôi trình bày phía sau, cái tăng lên là chi phí nhìn thấy được, còn cái giảm đi là phần làm lại và chậm trễ khó nhìn thấy. Bên nào lợi hơn thì không thể kết luận chung chung, nhưng ít nhất hãy hiểu rằng một đề xuất không có chi phí định nghĩa yêu cầu trong báo giá không có nghĩa là phần việc đó biến mất. Hoặc có ai đó đang làm không công, hoặc nó đang ẩn mình bên trong giai đoạn lập trình.

Ngoài ra, ý nghĩa của mức độ chốt yêu cầu còn thay đổi tùy theo việc chọn phát triển riêng hay triển khai gói phần mềm, vì nếu là gói thì bản thân sản phẩm đã nắm sẵn một phần yêu cầu. Ngã rẽ này chúng tôi sắp xếp trong bài viết phân định ba lựa chọn giữa phát triển riêng và gói phần mềm.

Tiêu chí nghiệm thu nên chốt khi nào và dựa trên cái gì

Nghiệm thu là khâu dễ phát sinh xích mích nhất trong hợp đồng. Các hướng dẫn thực hành cũng chỉ ra rằng nguyên nhân lớn nhất của rắc rối nghiệm thu là tiêu chí nghiệm thu mơ hồ, và biện pháp là phải chốt tiêu chí nghiệm thu trước khi bắt tay vào phát triển.

Nghe thì hiển nhiên, nhưng thực tế lại ít khi được tuân thủ. Ở phần lớn dự án, hợp đồng chỉ ghi thủ tục, đại loại bên đặt hàng sẽ kiểm tra trong thời hạn quy định sau bàn giao và cấp biên bản nghiệm thu nếu đạt, mà không ghi thế nào là đạt. Đến ngày bàn giao trong tình trạng đó, bên đặt hàng sẽ đánh giá theo kỳ vọng của mình, còn công ty phát triển đánh giá theo những gì ghi trong tài liệu đặc tả. Hai thước đo khác nhau, nên nghiệm thu chắc chắn sẽ căng thẳng.

Thực tiễn những năm gần đây ngày càng chuộng việc không nghiệm thu một lần cho xong, mà chia thành nhiều mốc như khi hoàn tất định nghĩa yêu cầu, khi hoàn tất thiết kế và nghiệm thu cuối cùng. Có hai lý do. Một là càng phát hiện muộn thì chi phí làm lại càng vọt lên. Nhận ra ở khâu tài liệu định nghĩa yêu cầu thì chỉ cần sửa chữ trong tài liệu, còn nhận ra ở khâu kiểm thử thì phải làm lại toàn bộ thiết kế, lập trình và kiểm thử. Hai là nó kéo sớm thời điểm bên đặt hàng được nhìn thấy sản phẩm thật. Hình dung hình hài cuối cùng chỉ qua tài liệu là việc khó với bất kỳ ai, còn nếu được xem bản mẫu màn hình từ sớm thì phát hiện lệch nhận thức cũng sớm hơn.

Khi viết tiêu chí nghiệm thu, tối thiểu cần có những mục sau.

• Đối tượng nghiệm thu. Kiểm tra sản phẩm nào, theo đơn vị nào
• Phương pháp đánh giá. Dựa trên tài liệu hạng mục kiểm thử, thao tác thực tế trên máy, hay đọc soát văn bản
• Ranh giới đạt và không đạt. Lỗi nhẹ vẫn cho đạt rồi khắc phục sau, hay phải xử lý hết mới cho đạt
• Thời hạn kiểm tra. Phải đánh giá trong bao nhiêu ngày làm việc kể từ khi bàn giao
• Cách xử lý nghiệm thu mặc nhiên. Xử lý ra sao nếu bên đặt hàng không đánh giá trong thời hạn
• Thủ tục khi không đạt. Thời hạn bàn giao lại, phạm vi kiểm tra lại, bên chịu chi phí

Trong số này, bên đặt hàng hay bỏ sót nhất là nghiệm thu mặc nhiên và cách xử lý lỗi nhẹ. Nếu có điều khoản nghiệm thu mặc nhiên mà lại không chuẩn bị lực lượng kiểm tra nội bộ, thì hàng bàn giao vào mùa cao điểm có thể nằm im không ai đụng tới cho đến khi hết hạn rồi mặc nhiên thành đạt. Ngược lại, đặt tiêu chí không chấp nhận bất kỳ lỗi nhẹ nào thì ngày vận hành thật sẽ chẳng bao giờ tới. Trên thực tế, cách khả thi là đánh giá đạt hay không đạt theo việc nghiệp vụ có chạy được hay không, còn lỗi nhẹ thì ấn định thời hạn khắc phục.

Cũng có cách yêu cầu từng nhà thầu nộp bản dự thảo tiêu chí nghiệm thu ngay ở khâu chào giá cạnh tranh. Cách này còn hữu ích như một trục so sánh các đề xuất. Quy trình đó chúng tôi trình bày chi tiết trong bài viết về cách làm RFP cho hệ thống quản lý sản xuất.

Trách nhiệm do không phù hợp hợp đồng là gì – khác gì trách nhiệm bảo hành khuyết tật trước đây

Khi phát hiện lỗi sau khi đã bàn giao và đã nghiệm thu đạt, thì có thể yêu cầu công ty phát triển sửa đến đâu. Thứ quy định điều này chính là trách nhiệm do không phù hợp hợp đồng.

Bộ luật Dân sự sửa đổi của Nhật Bản có hiệu lực từ tháng 4 năm 2020 đã đổi trách nhiệm bảo hành khuyết tật trước đây thành trách nhiệm do không phù hợp hợp đồng. Thay đổi này không dừng ở tên gọi mà bao gồm cả những nội dung tác động thật đến thực tiễn.

Tác động lớn nhất là thay đổi mốc bắt đầu tính thời hạn thực hiện quyền. Chế độ cũ đòi phải thực hiện quyền trong vòng một năm kể từ khi bàn giao, còn sau sửa đổi thì chỉ cần thông báo trong vòng một năm kể từ khi biết về sự không phù hợp là đủ. Điều đó có nghĩa là với những lỗi được phát hiện sau bàn giao một thời gian dài, bên đặt hàng vẫn còn cửa để yêu cầu khắc phục.

Thay đổi thứ hai là việc quy định thành văn các biện pháp khắc phục. Bộ luật Dân sự sửa đổi đã ghi rõ quyền yêu cầu hoàn thiện và quyền yêu cầu giảm giá. Quyền yêu cầu hoàn thiện là quyền đòi sửa chữa phần không phù hợp, hoặc đòi giao vật thay thế, để đưa trạng thái về đúng với hợp đồng. Quyền yêu cầu giảm giá là quyền đòi giảm thù lao tương ứng với mức độ không phù hợp trong trường hợp không được hoàn thiện. Quyền đòi bồi thường thiệt hại và quyền hủy hợp đồng vốn đã có từ trước, nay có thêm 2 lựa chọn nữa.

Tuy nhiên, các quy định về trách nhiệm do không phù hợp hợp đồng có thể thay đổi bằng thỏa thuận của các bên. Trên thực tế không hiếm những điều khoản rút ngắn thời hạn trách nhiệm, hoặc giới hạn phạm vi trách nhiệm ở mức không vượt quá tổng phí dịch vụ mà bên đặt hàng đã thanh toán. Bản mẫu do công ty phát triển đưa ra thường đã chứa sẵn những giới hạn kiểu này. Là bên đặt hàng, đừng chỉ nhìn xem điều khoản có hay không, mà nhất định phải xem thời hạn và mức trần được viết như thế nào.

Thêm nữa, trong phát triển hệ thống, chính ranh giới giữa lỗi và thay đổi đặc tả cũng là điểm tranh chấp. Trạng thái hệ thống chạy đúng như đặc tả đã thỏa thuận nhưng khó dùng trong nghiệp vụ không phải là không phù hợp hợp đồng, mà là đề nghị thay đổi đặc tả. Chính để ranh giới này không phải đem ra bàn về sau, mức độ cụ thể của tài liệu định nghĩa yêu cầu và tiêu chí nghiệm thu mới có sức nặng. Chỉ làm dày mỗi điều khoản trách nhiệm sẽ không phát huy tác dụng, nếu đặc tả dùng làm mốc so sánh vẫn còn mơ hồ.

Quyền sở hữu trí tuệ thuộc về bên nào

Đã bỏ tiền đặt hàng thì hệ thống làm xong phải là của công ty mình. Cảm giác đó rất tự nhiên, nhưng về mặt pháp lý thì không phải vậy.

Nếu hợp đồng không quy định gì, quyền tác giả đối với hệ thống được phát triển thuộc về công ty phát triển, tức bên nhận việc. Vì người thực sự sáng tạo ra chương trình là nhân viên của công ty phát triển. Nếu bên đặt hàng muốn có quyền tác giả thì phải ghi rõ việc chuyển giao trong hợp đồng.

Điểm dễ bị bỏ sót ở đây là quyền chỉnh sửa. Hành vi viết lại chương trình có thể cấu thành hành vi phóng tác theo luật quyền tác giả. Do đó, nếu quyền tác giả vẫn nằm ở công ty phát triển, việc bên đặt hàng giao bảo trì hay chỉnh sửa cho một công ty khác có nguy cơ trở thành xâm phạm quyền tác giả. Vấn đề này lộ ra vào lúc quan hệ với công ty phát triển đứt gãy sau vài năm, hoặc lúc muốn đổi nhà cung cấp vì phản hồi quá chậm.

Trên thực tế có ba lựa chọn lớn.

• Chuyển giao toàn bộ quyền tác giả cho bên đặt hàng. Cách này cho bên đặt hàng mức tự do cao nhất, nhưng công ty phát triển không còn tái sử dụng được tài sản cùng loại cho dự án khác nên báo giá có thể tăng
• Giữ quyền tác giả ở công ty phát triển nhưng cấp cho bên đặt hàng quyền sử dụng và chỉnh sửa. Nếu ghi rõ đến mức cho phép giao bảo trì cho bên thứ ba thì bất tiện thực tế sẽ rất nhỏ
• Tách phần dùng chung ra khỏi phần phát triển riêng. Thư viện và nền tảng chung vẫn thuộc công ty phát triển, chỉ chuyển giao cho bên đặt hàng phần logic đặc thù của nghiệp vụ

Cách tách thứ ba hợp lý, nhưng ranh giới mơ hồ sẽ thành mầm mống tranh chấp về sau. Nên liệt kê cụ thể ngay tại thời điểm ký hợp đồng phạm vi nào được coi là mô đun dùng chung.

Ngoài ra, khi quy định việc chuyển giao, thực tiễn phổ biến là đề cập luôn đến việc không thực hiện quyền nhân thân của tác giả. Vì quyền nhân thân của tác giả là quyền không thể chuyển giao, nên người ta dùng hình thức thỏa thuận sẽ không thực hiện quyền đó. Điểm này cách viết điều khoản quyết định kết quả, nên chúng tôi rất khuyến nghị để luật sư rà soát.

Hai lỗ hổng hay bị bỏ qua trong thỏa thuận bảo mật

Phần lớn công ty hẳn đã ký thỏa thuận bảo mật ngay từ khâu mời đề xuất. Cũng chính vì thế mà nhiều nơi dùng lại bản mẫu cũ không soát nội dung, và để 2 điểm sau thiếu vắng mà không hay.

Lỗ hổng thứ nhất là nghĩa vụ không vươn tới nhà thầu phụ. Trong phát triển hệ thống, việc công ty phát triển giao lại một phần công đoạn cho công ty khác hoặc cơ sở offshore là chuyện không hiếm. Vậy mà nếu bên nhận nghĩa vụ trong thỏa thuận bảo mật chỉ là công ty phát triển, thì những người thực sự chạm vào bản vẽ và dữ liệu giá thành của công ty mình lại nằm ngoài hợp đồng. Cần quy định rõ có cho phép giao thầu lại hay không, và nếu cho phép thì phải áp nghĩa vụ bảo mật tương đương lên nhà thầu phụ, đồng thời ghi rõ công ty phát triển chịu trách nhiệm về hành vi của nhà thầu phụ.

Lỗ hổng thứ hai là không viết về việc cấm sử dụng ngoài mục đích và cách xử lý sau khi hợp đồng kết thúc. Đa số thỏa thuận bảo mật có quy định không tiết lộ cho bên thứ ba, nhưng có bản không quy định tới mức cấm sử dụng cho mục đích khác ngoài công việc này. Vậy là còn chỗ để lập luận rằng chỉ cần không tiết lộ thì việc dùng lại trong phân tích nội bộ hay trong tài liệu đề xuất cho khách khác là không bị cấm. Ngoài ra cũng nên quy định sau khi dự án kết thúc thì xử lý dữ liệu đã cung cấp ra sao, trả lại hay xóa bỏ, và chứng minh việc xóa bỏ bằng cách nào. Nếu đã từng đưa dữ liệu thật cho việc kiểm thử, thì có hay không câu này tạo ra khác biệt thực sự.

Thỏa thuận bảo mật một khi đã ký thường được dùng tiếp nhiều năm mà không ai xem lại. Thời điểm ký hợp đồng phát triển chính là dịp tốt để rà 2 điểm này.

Học từ vụ việc có thật – thiết kế hợp đồng sai thì chuyện gì xảy ra

Vụ việc thường được nhắc tới như ví dụ về thiết kế hợp đồng lỏng lẻo dẫn tới tranh chấp quy mô lớn là vụ kiện phát triển hệ thống giữa ngân hàng Suruga và IBM Japan.

Theo báo chí, Tòa án Quận Tokyo ngày 29 tháng 3 năm 2012 đã ra bản án buộc thanh toán khoảng 7.4 tỷ yên. Sau đó, Tòa án Cấp cao Tokyo với tư cách tòa phúc thẩm ngày 26 tháng 9 năm 2013 đã ra bản án giảm khoản tiền này xuống còn khoảng 4.2 tỷ yên. Có tin rằng Tòa án Cấp cao Tokyo đã đưa ra nhận định rằng đối với sự bất định ở giai đoạn đầu dự án, phía doanh nghiệp sử dụng cũng phải gánh phần rủi ro tương ứng của mình.

Bài viết này không phải bình luận án lệ nên sẽ không bước vào đánh giá pháp lý. Điều người phụ trách thực tế cần nắm là những điểm sau.

Thứ nhất, bất kể số tiền lớn hay nhỏ, điểm tranh chấp là ai đã gánh sự bất định của giai đoạn đầu và gánh tới đâu. Thứ hai, việc phân bổ gánh nặng đó được phán đoán từ cả câu chữ hợp đồng lẫn cách vận hành dự án trên thực tế. Thứ ba, chính việc sơ thẩm và phúc thẩm phán quyết khác nhau đã cho thấy vấn đề này không dễ ngã ngũ.

Lật ngược lại, điều đó nghĩa là hợp đồng đẩy toàn bộ trách nhiệm hoàn thành sang một phía trong khi yêu cầu chưa chốt thì luôn bấp bênh, bất kể quy mô lớn hay nhỏ. Dự án vừa và nhỏ ít khi đi đến tòa. Thay vào đó, tổn thất xuất hiện dưới dạng đàm phán chi phí phát sinh kéo dài, ngày vận hành bị trễ, và quan hệ tin cậy giữa những người phụ trách bị đổ vỡ. Chỉ là nó không được cộng thành con số. Thứ bị mất đi thì vẫn vậy.

Nguyên nhân khiến việc triển khai không suôn sẻ không chỉ nằm ở hợp đồng. Toàn bộ những hạng mục cần tự quyết trong nội bộ trước khi đặt hàng được chúng tôi sắp xếp trong bài viết về thất bại khi triển khai hệ thống quản lý sản xuất.

Ba điều khoản cần bổ sung khi ký hợp đồng tại Thái Lan

Toàn bộ phần trên là nguyên tắc chung đặt trên nền pháp luật Nhật Bản. Khi pháp nhân tại Thái Lan là bên đặt hàng, hoặc khi trụ sở chính ở Nhật ký với công ty phát triển của Thái Lan, sẽ có thêm những điều khoản phải kiểm tra. Chỉ dịch bản hợp đồng vẫn dùng ở Nhật sang tiếng Thái thì rất dễ thành một bản hợp đồng không vận hành được.

Thứ nhất là luật áp dụng. Việc diễn giải hợp đồng theo pháp luật nước nào có thể do các bên tự chọn bằng thỏa thuận. Chọn luật Nhật Bản cũng được, chọn luật Thái Lan cũng được. Nhưng nếu luật áp dụng đã chọn lệch với thẩm quyền tài phán nói dưới đây, sẽ phát sinh nhu cầu chứng minh nội dung luật Nhật Bản trước tòa Thái Lan, khiến thủ tục nặng nề hơn nhiều.

Thứ hai là thứ tự ưu tiên ngôn ngữ. Theo quy định của Bộ luật Dân sự và Thương mại Thái Lan, người ta hiểu rằng với hợp đồng được lập bằng nhiều ngôn ngữ mà không ghi rõ thứ tự ưu tiên thì bản tiếng Thái sẽ được ưu tiên. Chỉ trao đổi bản tiếng Nhật và bản tiếng Anh rồi yên tâm sẽ để lại chỗ trống cho những cách diễn giải bất ngờ được viện dẫn khi bản dịch tiếng Thái xuất hiện về sau. Cách xử lý thực tế là chọn một trong hai hướng, hoặc ấn định bản tiếng Anh là bản gốc rồi xếp bản tiếng Thái và tiếng Nhật là bản dịch, hoặc ghi rõ bản tiếng Thái được ưu tiên rồi soát kỹ từng câu chữ tiếng Thái. Để cả ba ngôn ngữ song song mà bỏ lửng điểm này là nguy hiểm nhất.

Thứ ba là thẩm quyền tài phán. Nếu đã lường trước tình huống đòi pháp nhân Thái Lan thanh toán hoặc bồi thường thiệt hại, thì thỏa thuận chỉ định tòa án Thái Lan là nơi giải quyết tranh chấp gần như là bắt buộc trên thực tế. Bởi dù thắng kiện tại tòa án Nhật Bản thì cũng không thể đem bản án đó thi hành trực tiếp tại Thái Lan. Tổ hợp luật Nhật Bản và tòa án Nhật Bản cho phía Nhật cảm giác an tâm về tâm lý, nhưng lại thiếu hiệu lực thực tế khi tài sản của đối tác nằm ở Thái Lan.

Còn một điểm nữa cần lưu ý, là chính bản thân loại hợp đồng. Bộ luật Dân sự và Thương mại Thái Lan có loại hợp đồng gọi là Hire of Work, tức khoán việc, và đây là khái niệm gần với hợp đồng khoán việc theo luật Nhật Bản. Nó được định nghĩa là hợp đồng trả thù lao cho kết quả của công việc đã hoàn thành, và cũng đã có điều luật quy định. Ngược lại, loại hợp đồng tương ứng chặt chẽ với hợp đồng bán ủy thác của luật Nhật Bản, tức việc ủy thác các công việc không mang tính hành vi pháp lý, thì không tồn tại trong luật Thái Lan.

Vì vậy, khi ký hợp đồng cho giai đoạn định nghĩa yêu cầu với công ty phát triển của Thái Lan, viết rằng đây là hợp đồng bán ủy thác sẽ không truyền đạt được ý nghĩa nào. Thứ phải làm là mô tả cụ thể ngay trong hợp đồng, dưới dạng tính chất của công việc, rằng công việc đó là cam kết hoàn thành sản phẩm bàn giao hay là trả thù lao cho việc cung cấp dịch vụ. Phải viết trọn bằng câu chữ điều khoản rằng sẽ nộp cái gì làm sản phẩm, thù lao phát sinh để đổi lấy điều gì, và có bao gồm bảo đảm hoàn thành hay không.

Nếu phát triển ở nước láng giềng thì khác biệt thực tiễn theo từng khu vực cũng không thể bỏ qua. Các điểm cần lưu ý khi phát triển tại Việt Nam được chúng tôi tổng hợp trong bài viết về phát triển hệ thống tại Việt Nam.

Ước tính riêng – chi phí làm lại sinh ra từ việc chọn sai loại hợp đồng

Bây giờ hãy thử quy toàn bộ lập luận trên thành tiền. Phần dưới đây là ước tính riêng của chúng tôi dựa trên một tình huống mô hình, không phải con số của bất kỳ doanh nghiệp có thật nào. Hãy đọc nó như tư liệu để kiểm chứng cấu trúc, chứ không phải để nhìn vào độ lớn của số tiền.

Đặt giả thiết trước. Giả sử một nhà máy Nhật Bản tại Thái Lan đang đặt hàng làm mới hệ thống quản lý sản xuất. Giá trị hợp đồng của giai đoạn lập trình là 3,000,000 THB. Đơn giá tiêu chuẩn cho phát triển bổ sung là 3,000 THB một người-ngày, và khối lượng phát triển tiêu chuẩn cho mỗi thay đổi đặc tả là 3 người-ngày. Trên nền đó, so sánh 2 trường hợp có mức độ chốt yêu cầu khác nhau.

Trường hợp A là khi ký hợp đồng khoán việc trọn gói cho giai đoạn lập trình trong lúc định nghĩa yêu cầu mới chốt được 60%. Sau khi ký hợp đồng đã phát sinh 8 thay đổi đặc tả.

Con số 4,500 THB một thay đổi là cách quy ra tiền khối lượng công việc phát sinh để xử lý một thay đổi đặc tả bằng đàm phán riêng sau khi đã ký hợp đồng. Khảo sát phạm vi ảnh hưởng, làm lại báo giá và họp thống nhất bổ sung cộng lại được đặt ở mức tương đương 1.5 người-ngày cho mỗi thay đổi. Trong hợp đồng khoán việc, công việc nằm ngoài phạm vi hợp đồng không thể triển khai miễn phí, nên cuộc đàm phán này lặp lại mỗi lần.

Còn có những chi phí không hiện ra thành tiền. Trong 8 thay đổi đó, các thay đổi trải rộng qua nhiều mô đun là 5, và mỗi cái cần trung bình 6.4 ngày làm việc để đi đến thống nhất. Cộng lại, 5 thay đổi × 6.4 ngày làm việc cho ra 32 ngày làm việc chồng chất thành chậm trễ trên đường găng. Phần chậm trễ này chúng tôi không quy ra tiền. Thêm nữa, đàm phán càng kéo dài thì rủi ro bùng thành tranh chấp càng cao, và quan hệ tin cậy giữa những người phụ trách cũng tổn thương theo. Những thứ này không định lượng được, nhưng trên thực tế có thể là chi phí nặng nề nhất.

Trường hợp B là khi tách riêng giai đoạn định nghĩa yêu cầu thành hợp đồng bán ủy thác, nâng mức độ chốt lên 95% rồi mới ký hợp đồng khoán việc cho giai đoạn lập trình. Giai đoạn định nghĩa yêu cầu kéo dài 2.5 tháng, mỗi tháng 150,000 THB, nên giá trị hợp đồng là 375,000 THB.

Thay đổi đặc tả sau khi ký hợp đồng giảm xuống còn 2. Tổng chi phí phát sinh là 27,000 THB. So với 108,000 THB của trường hợp A, phép tính 108,000 ÷ 27,000 cho ra chênh lệch 4.0 lần. Phần chênh là 108,000 − 27,000, tức 81,000 THB.

Ở đây có điều phải viết ra một cách trung thực. Trường hợp B đã đầu tư trước 375,000 THB vào giai đoạn định nghĩa yêu cầu. Trong khi đó chi phí phát sinh cắt giảm được là 81,000 THB. Vì 81,000 THB thấp hơn 375,000 THB, khoản đầu tư này không hoàn vốn nếu tính bằng tiền mặt. Nói rằng tách riêng định nghĩa yêu cầu thì chi phí sẽ giảm là không chính xác.

Vậy tại sao vẫn khuyến nghị tách riêng định nghĩa yêu cầu. Vì thứ thu hồi được không phải là tiền, mà là việc tránh được 32 ngày làm việc chậm trễ và việc giảm rủi ro bùng thành tranh chấp. Hãy đánh giá trên một trục khác với tiền rằng việc vận hành trễ 32 ngày làm việc nặng đến đâu với kế hoạch kinh doanh của công ty mình, và công ty sẽ mất gì nếu đàm phán sau khi ký chuyển thành tranh chấp. Khi ngày chạy dây chuyền hay hạn chốt sổ kế toán không thể dịch chuyển, thì 32 ngày làm việc chậm trễ mang ý nghĩa nặng hơn nhiều so với khoản chênh 81,000 THB. Ngược lại, với dự án quy mô nhỏ có thời hạn còn dư dả và yêu cầu tương đối đơn giản, cách làm của trường hợp A đôi khi lại hợp lý.

Dù thế nào đi nữa, quyết định tách định nghĩa yêu cầu thành hợp đồng bán ủy thác được đưa ra vì muốn dập tắt sự bất định trước, chứ không phải vì sẽ rẻ hơn. Bắt đầu với kỳ vọng hiệu quả đầu tư quá lớn thì sẽ kết thúc trong thất vọng.

Danh mục kiểm tra hợp đồng – những mục cần rà trước khi đặt hàng

Phần này sắp xếp lại toàn bộ nội dung trên theo trình tự nên rà khi nhận được bản hợp đồng. Khi đọc bản mẫu do công ty phát triển đưa, đi theo thứ tự này sẽ ít bị bỏ sót.

Trong danh mục này, những mục bên đặt hàng tự quyết được là 5 mục đầu, tức loại hợp đồng, phạm vi công việc, định nghĩa sản phẩm bàn giao, tiêu chí nghiệm thu và thời hạn nghiệm thu. Đừng để công ty phát triển điền hộ phần này, mà hãy mang dự thảo của chính mình vào bàn đàm phán. Các mục còn lại mang tính chất đọc kỹ nội dung bản mẫu và rà xem điều kiện có bất lợi hay không.

Không cần phải hoàn hảo mọi thứ ngay một lúc. Nhưng với bốn hạng mục là loại hợp đồng, tiêu chí nghiệm thu, trách nhiệm do không phù hợp hợp đồng và quyền sở hữu trí tuệ, nhất định phải kiểm tra xem chúng có nhất quán dưới cùng một thước đo là mức độ chốt của yêu cầu hay không. Một bản hợp đồng mà bốn thứ này lệch pha nhau sẽ không vận hành được, dù có bao nhiêu điều khoản đi nữa.

Dùng hợp đồng mẫu của IPA như thế nào

Không cần soạn hợp đồng từ con số không, vì đã có sẵn bản mẫu trung lập do cơ quan nhà nước công bố.

Cơ quan Xúc tiến Công nghệ Thông tin Nhật Bản (IPA) đã công bố ấn bản thứ hai của bộ hợp đồng và mẫu giao dịch chuẩn cho hệ thống thông tin vào ngày 22 tháng 12 năm 2020. Tài liệu này được xây dựng hướng tới nội dung trung lập, không nghiêng về phía doanh nghiệp sử dụng hay phía nhà cung cấp công nghệ thông tin, và cùng thời điểm đó cũng có hướng dẫn về đặc tả an toàn thông tin được công bố.

Giá trị của hợp đồng mẫu này không nằm ở chỗ dùng được ngay. Nó nằm ở chỗ cho ta thấy các vấn đề như tư duy chia loại hợp đồng theo giai đoạn, thủ tục nghiệm thu, cách xử lý quyền sở hữu trí tuệ được sắp xếp thành câu chữ điều khoản dưới hình thức nào. Đem đọc đối chiếu với bản mẫu do công ty phát triển đưa ra, sẽ thấy rõ điều khoản nào bị cắt đi và điều khoản nào bị viết lại theo hướng có lợi cho một bên.

Về cách dùng thực tế, chúng tôi khuyến nghị trình tự sau. Trước hết đọc hết hợp đồng mẫu để nắm bức tranh tổng thể các vấn đề. Tiếp theo, đối chiếu hợp đồng do công ty phát triển đưa với mục lục của hợp đồng mẫu. Nếu thiếu vấn đề nào thì hỏi công ty phát triển lý do. Trên cơ sở đó, viết lại phần loại hợp đồng và tiêu chí nghiệm thu cho khớp với mức độ chốt yêu cầu của công ty mình.

Cũng có điểm cần lưu ý. Hợp đồng mẫu này đặt trên nền pháp luật Nhật Bản nên không thể áp dụng nguyên xi cho hợp đồng tại Thái Lan. Ba điều khoản đã nói ở trên gồm luật áp dụng, thứ tự ưu tiên ngôn ngữ và thẩm quyền tài phán đều phải bổ sung, và cách xử lý loại hợp đồng bán ủy thác cũng cần diễn giải lại. Hãy dùng nó thuần túy như một tấm bản đồ để kiểm tra xem có bỏ sót vấn đề nào không, còn câu chữ cuối cùng thì để chuyên gia am hiểu thực tiễn pháp lý sở tại rà soát.

Câu hỏi thường gặp

Hợp đồng khoán việc và hợp đồng bán ủy thác, loại nào an toàn hơn

Không loại nào an toàn hơn tự thân nó. Với công đoạn mà yêu cầu đã chốt, hợp đồng khoán việc có lợi hơn cho bên đặt hàng vì đẩy được trách nhiệm hoàn thành sang công ty phát triển. Nhưng ký hợp đồng khoán việc cho công đoạn mà yêu cầu chưa chốt thì mỗi lần thay đổi đặc tả lại phải đàm phán riêng, rốt cuộc thành bất lợi. An toàn hay không được quyết định bởi tổ hợp giữa loại hợp đồng và mức độ chốt của yêu cầu, chứ không phải bởi loại hợp đồng.

Nên chốt tiêu chí nghiệm thu vào lúc nào

Trước khi bắt tay vào phát triển. Các hướng dẫn thực hành liên tục chỉ ra rằng sự mơ hồ của tiêu chí nghiệm thu là nguyên nhân lớn nhất gây rắc rối, và tiêu chí cần được chốt trước khi khởi công. Cố dựng tiêu chí ngay trước ngày bàn giao thì không bao giờ ngã ngũ, vì mỗi bên sẽ khăng khăng theo tiêu chí có lợi cho mình. Lý tưởng nhất là khi chốt tài liệu định nghĩa yêu cầu thì quyết luôn cách kiểm tra từng yêu cầu đó.

Thời hạn trách nhiệm do không phù hợp hợp đồng bao lâu là hợp lý

Không có đáp án đúng cho mọi trường hợp. Bộ luật Dân sự sửa đổi đặt khung là thông báo trong vòng một năm kể từ khi biết về sự không phù hợp, nhưng hợp đồng vẫn có thể ấn định thời hạn ngắn hơn, và trên thực tế những điều khoản như vậy không hiếm. Một căn cứ để cân nhắc là hệ thống có tính mùa vụ hay không. Nếu có chức năng chốt sổ kế toán hay kiểm kê chỉ chạy mỗi năm một lần, thì thời hạn ngắn khiến việc phát hiện lỗi trở nên bất khả thi.

Có nhất thiết phải yêu cầu chuyển giao quyền tác giả cho công ty mình không

Không nhất thiết. Đòi chuyển giao có thể làm báo giá tăng lên. Điều quan trọng trên thực tế không phải là quyền sở hữu, mà là bảo đảm được trạng thái có thể tiếp tục chỉnh sửa hệ thống trong tương lai. Ngay cả khi quyền tác giả vẫn ở công ty phát triển, nếu có cấp phép sử dụng và chỉnh sửa, đồng thời cho phép giao bảo trì cho bên thứ ba, thì bất tiện thực tế sẽ rất nhỏ. Ngược lại, dù có điều khoản chuyển giao, nếu phạm vi mô đun dùng chung mơ hồ thì cũng không biết rốt cuộc mình được tự do tới đâu.

Dịch hợp đồng Nhật Bản sang tiếng Thái là đủ chưa

Chưa đủ. Cần ba điều khoản là luật áp dụng, thứ tự ưu tiên ngôn ngữ và thẩm quyền tài phán. Đặc biệt nếu không ghi rõ thứ tự ưu tiên ngôn ngữ thì cần lưu ý rằng theo quy định của Bộ luật Dân sự và Thương mại Thái Lan, bản tiếng Thái sẽ được hiểu là được ưu tiên. Ngoài ra, do luật Thái Lan không có loại hợp đồng tương ứng chặt chẽ với hợp đồng bán ủy thác của luật Nhật Bản, nên phải mô tả cụ thể tính chất công việc ngay trong các điều khoản.

Dự án quy mô nhỏ có cần làm hợp đồng kỹ đến mức này không

Số tiền nhỏ không tỷ lệ thuận với khả năng ít xảy ra tranh chấp. Tuy vậy, nếu thời gian có hạn và phải xếp thứ tự ưu tiên, hãy ưu tiên 2 thứ là tiêu chí nghiệm thu và quyền sở hữu trí tuệ. Tiêu chí nghiệm thu gắn trực tiếp với việc có thanh toán hay không, còn quyền sở hữu trí tuệ gắn trực tiếp với mức tự do đổi nhà cung cấp sau vài năm. Giữ được hai thứ này thì dù các điều khoản khác vẫn theo bản mẫu tiêu chuẩn, việc tránh tình huống chí mạng cũng dễ hơn nhiều.

Kết luận

Những thứ phải quyết trong hợp đồng phát triển hệ thống là bốn hạng mục gồm loại hợp đồng, tiêu chí nghiệm thu, trách nhiệm do không phù hợp hợp đồng và quyền sở hữu trí tuệ. Bốn thứ này không phải bốn vấn đề độc lập mà bị chi phối bởi một biến số duy nhất là yêu cầu đã chốt đến mức nào. Vì vậy, quyết rời rạc từng thứ sẽ tạo ra bản hợp đồng tự mâu thuẫn bên trong.

Tranh luận xem khoán việc hay bán ủy thác mới đúng là vô nghĩa. Cách làm thực tế là dùng phân theo giai đoạn, ví dụ giai đoạn định nghĩa yêu cầu dùng bán ủy thác, còn giai đoạn lập trình sau khi yêu cầu đã chốt thì dùng khoán việc. Tiêu chí nghiệm thu chốt trước khi khởi công, và chia thành nhiều mốc gồm khi hoàn tất định nghĩa yêu cầu, khi hoàn tất thiết kế và nghiệm thu cuối cùng, sẽ giảm được phần làm lại ở các công đoạn sau. Trách nhiệm do không phù hợp hợp đồng đã thay đổi cả mốc tính thời hạn lẫn biện pháp khắc phục theo Bộ luật Dân sự sửa đổi có hiệu lực từ tháng 4 năm 2020, nhưng vẫn có thể điều chỉnh bằng hợp đồng, nên nhất định phải kiểm tra cách ghi thời hạn và mức trần. Quyền sở hữu trí tuệ, nếu không quy định gì, sẽ thuộc về công ty phát triển. Trên thực tế, việc có được phép chỉnh sửa và giao bảo trì cho bên thứ ba hay không có sức nặng hơn chính quyền sở hữu.

Trong ước tính riêng, trường hợp A ký khoán việc trọn gói khi yêu cầu mới chốt 60% có chi phí phát sinh là 108,000 THB, còn trường hợp B tách định nghĩa yêu cầu thành bán ủy thác là 27,000 THB, chênh nhau 4.0 lần. Tuy nhiên khoản đầu tư trước 375,000 THB cho định nghĩa yêu cầu không hoàn vốn bằng tiền mặt chỉ với phần chênh 81,000 THB. Thứ thu hồi được là việc tránh 32 ngày làm việc chậm trễ và giảm rủi ro tranh chấp, những giá trị khó quy thành tiền. Việc có giải thích được điều này một cách không né tránh trong nội bộ hay không cũng rất quan trọng khi trình duyệt ngân sách.

Khi ký hợp đồng tại Thái Lan, nhất định phải bổ sung ba điều khoản là luật áp dụng, thứ tự ưu tiên ngôn ngữ và thẩm quyền tài phán. Chỉ dịch hợp đồng Nhật Bản thì sẽ không vận hành được. Và xin nhắc lại, bài viết này là hướng dẫn thực hành, không phải tư vấn pháp lý. Với nội dung của từng hợp đồng cụ thể, hãy xác nhận với luật sư hoặc chuyên gia.

Việc điền các điều khoản hợp đồng ra sao, rốt cuộc phụ thuộc vào yêu cầu của công ty bạn đã chốt tới đâu. Ngay cả khi bạn đang ở giai đoạn khó tự phán đoán mức độ chốt đó, hoặc chưa biết nên đàm phán phần nào trong bản hợp đồng mà công ty phát triển đưa ra, cũng không sao. Với kinh nghiệm triển khai hệ thống quản lý sản xuất và thực tiễn hợp đồng tại Thái Lan, chúng tôi sẵn sàng hỗ trợ dù chỉ là việc sắp xếp lại tình hình. Mời bạn liên hệ qua trang liên hệ của chúng tôi.

Thông tin tham khảo

• BUSINESS LAWYERS — Sự khác biệt giữa hợp đồng khoán việc và hợp đồng bán ủy thác cùng cách vận dụng trong phát triển hệ thống
• BUSINESS LAWYERS — Thực tiễn trách nhiệm do không phù hợp hợp đồng trong phát triển hệ thống
• Văn phòng luật Tokyo Startup — Trách nhiệm do không phù hợp hợp đồng trong phát triển hệ thống
• Human Navi — Nghiệm thu trong phát triển hệ thống và cách đặt tiêu chí nghiệm thu để tránh rắc rối
• Văn phòng Shu Sogo — Quyền tác giả và quyền chỉnh sửa trong phát triển hệ thống
• Cơ quan Xúc tiến Công nghệ Thông tin Nhật Bản (IPA) — Hợp đồng và mẫu giao dịch chuẩn cho hệ thống thông tin, ấn bản thứ hai
• Nikkei — Bản án phúc thẩm trong vụ kiện phát triển hệ thống giữa ngân hàng Suruga và IBM Japan
• Văn phòng luật GVA — Thực tiễn hợp đồng tại Thái Lan cùng cách xử lý luật áp dụng, ngôn ngữ và thẩm quyền tài phán
• Legal Execution Thailand — Bộ luật Dân sự và Thương mại Thái Lan, Quyển 3 Thiên 7 Khoán việc