TrungTamDinhGia.comTrung Tâm Định Giá
Định giá tài sản vô hình

Định giá phần mềm: phương pháp chi phí tái tạo, thu nhập và trừ lỗi thời

Phần mềm nội bộ thường định giá theo chi phí tái tạo, phần mềm bán ra theo thu nhập. Bài hướng dẫn ước lượng công sức, trừ lỗi thời và rà soát quyền với mã nguồn.

Over-the-shoulder view of a Vietnamese software engineer at a standing desk facing two blank dark monitors, city lights through window at dusk, deep indigo and warm orange palette

Định giá phần mềm dựa trên câu hỏi: phần mềm này được dùng để làm gì? Phần mềm nội bộ phục vụ vận hành (quản lý kho, điều phối giao hàng, hệ thống lõi) thường được định giá bằng cách tiếp cận chi phí: tạo lại một hệ thống có công dụng tương đương hôm nay tốn bao nhiêu, trừ đi mức lỗi thời. Phần mềm là sản phẩm bán ra (bản quyền, dịch vụ thuê bao SaaS) thường được định giá bằng cách tiếp cận thu nhập, từ dòng doanh thu và tuổi đời công nghệ.

Hai sai lầm hay gặp nhất là lấy tổng chi phí đã chi trong quá khứ làm giá trị, và quên kiểm tra quyền sở hữu mã nguồn. Phần mềm có thể được viết bởi lập trình viên thuê ngoài chưa chuyển giao quyền, hoặc chứa thư viện mã nguồn mở với giấy phép ràng buộc; cả hai đều có thể làm giá trị giảm mạnh dù kỹ thuật tốt.

Phần mềm là tài sản gì: bốn tình huống định giá khác nhau

Về pháp lý, phần mềm ở Việt Nam được bảo hộ chủ yếu dưới dạng quyền tác giả đối với chương trình máy tính; thuật toán và ý tưởng không được bảo hộ, chỉ có mã nguồn và mã máy cụ thể. Một số giải pháp kỹ thuật chạy bằng phần mềm có thể được cấp bằng sáng chế nếu đáp ứng điều kiện, nhưng chương trình máy tính tự thân không phải đối tượng sáng chế. Về kế toán, phần mềm mua hoặc phát triển đủ điều kiện được ghi nhận là tài sản cố định vô hình. Định giá thì cần phân biệt bốn tình huống.

Phần mềm nội bộ tự phát triển, như hệ thống điều phối của một công ty logistics: không bán ra ngoài, giá trị nằm ở việc doanh nghiệp không phải mua hoặc thuê giải pháp khác. Phần mềm thương mại bán bản quyền: giá trị là dòng tiền từ bán và bảo trì. Nền tảng SaaS: phần mềm, dữ liệu khách hàng và hợp đồng thuê bao gắn chặt nhau, phải tách để định giá riêng. Mã nguồn chuyển giao, như khi một công ty bán quyền sở hữu một sản phẩm phần mềm cho bên khác: giá trị phụ thuộc năng lực khai thác của bên mua.

Mỗi tình huống dẫn tới một cách tiếp cận chính. Đây cũng là lý do một con số "giá trị phần mềm" không có ý nghĩa nếu không nói rõ phần mềm được dùng trong bối cảnh nào và ai là người sở hữu sau giao dịch.

Cách tiếp cận chi phí: ước lượng công sức tái tạo

Cách tiếp cận chi phí đặt câu hỏi: nếu hôm nay phải viết lại một phần mềm có cùng chức năng, cần bao nhiêu người-tháng và tốn bao nhiêu? Có hai khái niệm cần phân biệt. Chi phí tái tạo là chi phí làm ra bản sao gần như y hệt, cùng kiến trúc, cùng công nghệ. Chi phí thay thế là chi phí làm ra phần mềm có công dụng tương đương bằng công nghệ hiện đại. Chi phí thay thế thường thấp hơn vì công cụ, thư viện và nền tảng đám mây hiện nay rút ngắn nhiều công đoạn, và nó tự động loại bỏ một phần lỗi thời chức năng.

Để ước lượng công sức, thẩm định viên có vài công cụ. Cách thô nhất là đếm dòng mã rồi nhân với năng suất trung bình, nhưng dòng mã phụ thuộc ngôn ngữ và phong cách viết, nên chỉ dùng làm kiểm tra. Phương pháp điểm chức năng do Allan Albrecht phát triển ở IBM cuối thập niên 1970 đo kích thước phần mềm theo chức năng người dùng nhận được (đầu vào, đầu ra, truy vấn, tệp dữ liệu), độc lập với ngôn ngữ lập trình. Mô hình COCOMO của Barry Boehm, công bố trong cuốn Software Engineering Economics (1981) và được cập nhật thành COCOMO II vào khoảng năm 2000, chuyển kích thước phần mềm thành công sức người-tháng với các hệ số điều chỉnh theo độ phức tạp, kinh nghiệm đội ngũ, công cụ.

Các mô hình này được hiệu chỉnh trên dữ liệu dự án ở nước ngoài, nên khi áp dụng ở Việt Nam cần thận trọng với năng suất và đơn giá nhân công. Cách làm chắc chắn hơn là kết hợp: ước lượng theo mô hình, đối chiếu với nhật ký dự án thực tế của chính doanh nghiệp (nếu có), và hỏi ý kiến một công ty phát triển phần mềm độc lập về báo giá viết lại.

Ví dụ giả định: tính chi phí thay thế một phần mềm quản lý kho

Một doanh nghiệp phân phối tự phát triển phần mềm quản lý kho trong bốn năm. Bảng dưới là cách tính chi phí thay thế theo từng cấu phần (ví dụ giả định, đơn vị triệu đồng).

Cấu phầnCông sức ước tính (người-tháng)Đơn giá đầy đủ/người-thángChi phí
Phân tích nghiệp vụ và thiết kế1445630
Lập trình lõi nghiệp vụ kho60402.400
Tích hợp với kế toán và vận chuyển1840720
Kiểm thử và chuyển đổi dữ liệu2035700
Quản lý dự án (khoảng 10%)——445
Lợi nhuận hợp lý của nhà phát triển và chi phí cơ hội——700
Tổng chi phí thay thế trước lỗi thời5.595

Hai dòng cuối thường bị bỏ sót. Đơn giá phải là chi phí đầy đủ (lương, bảo hiểm, văn phòng, công cụ), không chỉ lương. Lợi nhuận của nhà phát triển và chi phí cơ hội phản ánh thực tế rằng một bên muốn có phần mềm ngay sẽ phải trả cho người làm ra nó, và trong thời gian chờ viết lại, doanh nghiệp mất lợi ích của việc có hệ thống.

Con số 5,6 tỷ chưa phải giá trị. Bước tiếp theo là trừ các loại lỗi thời; với phần mềm bốn năm tuổi, khoản trừ này có thể đáng kể.

Trừ lỗi thời: chức năng, công nghệ và kinh tế

Lỗi thời chức năng. Phần mềm có những tính năng không còn ai dùng, hoặc thiếu tính năng mà phần mềm hiện đại có sẵn. Nếu dùng chi phí thay thế thay vì tái tạo, phần lớn lỗi thời chức năng đã được loại bỏ; nếu dùng chi phí tái tạo, phải trừ riêng.

Lỗi thời công nghệ. Ngôn ngữ lập trình hoặc nền tảng đã cũ, khó tuyển người bảo trì, không chạy được trên hạ tầng mới, nhà cung cấp hệ điều hành hay cơ sở dữ liệu ngừng hỗ trợ. Với phần mềm, đây thường là khoản trừ lớn nhất, và nó tăng nhanh theo năm.

Nợ kỹ thuật. Mã viết vội, thiếu tài liệu, thiếu kiểm thử tự động làm chi phí sửa đổi và bảo trì cao hơn bình thường. Người mua sẽ phải chi tiền để trả món nợ này, nên giá trị cần trừ đi chi phí ước tính để đưa mã về trạng thái bảo trì được. Một đánh giá mã độc lập là bằng chứng tốt nhất.

Lỗi thời kinh tế. Phần mềm được thiết kế cho quy mô hoặc mô hình kinh doanh mà doanh nghiệp không còn theo đuổi, hoặc ngành đã chuyển sang giải pháp thuê bao rẻ hơn nhiều so với tự vận hành. Nếu một dịch vụ thuê ngoài có chức năng tương đương chỉ tốn một phần nhỏ chi phí, giá trị của phần mềm tự phát triển bị giới hạn bởi chi phí của phương án đó.

Kiểm tra mức trần. Sau khi trừ lỗi thời, so con số với chi phí mua hoặc thuê giải pháp thương mại tương đương trong cùng thời gian sử dụng còn lại. Một người mua hợp lý không trả cho phần mềm tự viết nhiều hơn chi phí của phương án thay thế sẵn có.

Cách tiếp cận thu nhập cho phần mềm thương mại và SaaS

Khi phần mềm là sản phẩm tạo doanh thu, cách tiếp cận thu nhập phù hợp hơn. Với doanh nghiệp SaaS, phần mềm thường là tài sản chính, nên phương pháp thu nhập vượt mức nhiều kỳ hay được dùng: lấy dòng tiền từ sản phẩm, trừ phần đóng góp của các tài sản khác (vốn lưu động, hạ tầng, đội ngũ, thương hiệu), phần còn lại gán cho công nghệ. Nếu doanh nghiệp có một tài sản chính khác mạnh hơn, chẳng hạn quan hệ khách hàng doanh nghiệp lớn, công nghệ có thể được định giá bằng phương pháp miễn trả phí bản quyền thay thế.

Đặc thù của phần mềm là công nghệ mất dần tỷ trọng đóng góp. Mã viết hôm nay sẽ được viết lại dần qua các phiên bản; sau vài năm, phần lớn mã đang chạy là mã mới, không thuộc tài sản đang được định giá. Thẩm định viên mô hình điều này bằng một đường suy giảm: ví dụ giả định, công nghệ hiện tại đóng góp 100% doanh thu năm đầu, 80% năm thứ hai, 55% năm thứ ba, rồi về gần không sau năm hoặc sáu năm. Đường suy giảm nên dựa trên lịch sử thay mã của chính sản phẩm, không chọn tuỳ ý.

Một bẫy khác là tính cả doanh thu từ khách hàng tương lai vào giá trị phần mềm. Khách hàng mới sẽ đến nhờ đội bán hàng, thương hiệu và cả phiên bản phần mềm tương lai; nếu định giá trong bối cảnh mua bán doanh nghiệp, phần đó thường nằm trong lợi thế thương mại, không nằm trong công nghệ hiện hữu.

Rà soát pháp lý trước khi định giá phần mềm

Một phần mềm có kỹ thuật tốt vẫn có thể giảm giá trị mạnh vì vấn đề quyền. Danh sách dưới là những điểm cần kiểm tra trước khi đưa ra bất kỳ con số nào.

  • Ai sở hữu quyền tác giả: phần mềm do nhân viên viết trong phạm vi công việc thường thuộc doanh nghiệp theo hợp đồng lao động và quy định hiện hành, nhưng phần do người làm tự do hoặc công ty thuê ngoài viết chỉ thuộc doanh nghiệp nếu hợp đồng có điều khoản chuyển giao quyền rõ ràng.
  • Mã nguồn mở và giấy phép: liệt kê thư viện bên thứ ba. Giấy phép dễ dãi (MIT, BSD, Apache) ít ràng buộc; giấy phép copyleft như GPL có thể buộc công bố mã nguồn khi phân phối sản phẩm phái sinh, ảnh hưởng trực tiếp đến mô hình kinh doanh bán bản quyền. Các công cụ quét thành phần phần mềm giúp lập danh sách nhanh.
  • Phần mềm và dữ liệu của bên thứ ba: giấy phép thương mại có chuyển nhượng được khi bán doanh nghiệp không, có điều khoản thay đổi quyền kiểm soát không.
  • Mã nguồn có đầy đủ không: có kho mã, lịch sử phiên bản, tài liệu, quy trình triển khai; hay chỉ có bản chạy trên máy chủ mà không ai còn giữ mã gốc.
  • Phụ thuộc vào người: nếu chỉ một hai lập trình viên hiểu hệ thống và họ không đi theo giao dịch, giá trị chuyển giao giảm rõ rệt.
  • Dữ liệu cá nhân trong hệ thống: phần mềm chứa dữ liệu khách hàng phải tuân thủ quy định bảo vệ dữ liệu cá nhân; dữ liệu là tài sản riêng, định giá riêng, không mặc định đi kèm.

Mỗi vấn đề phát hiện được nên chuyển thành một điều chỉnh có căn cứ: chi phí khắc phục, chiết khấu rủi ro, hoặc điều kiện trong hợp đồng. Bỏ qua chúng là để người mua phát hiện ở bước thẩm định chi tiết và đẩy giá xuống mạnh hơn nhiều.

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

Có thể lấy tổng lương đội phát triển trong quá khứ làm giá trị phần mềm không?

Không nên. Chi phí lịch sử bao gồm cả những hướng đi bị bỏ, tính năng không còn dùng, và phản ánh đơn giá của thời điểm đó. Cách tiếp cận chi phí đúng dùng chi phí thay thế ở thời điểm định giá, rồi trừ lỗi thời. Chi phí lịch sử chỉ dùng để đối chiếu mức hợp lý.

Phần mềm SaaS nên định giá theo bội số doanh thu không?

Bội số doanh thu thuê bao là công cụ định giá cả doanh nghiệp, không phải định giá riêng phần mềm. Khi cần giá trị riêng của công nghệ, chẳng hạn để phân bổ giá mua hay góp vốn bằng phần mềm, phải tách đóng góp của công nghệ khỏi quan hệ khách hàng, thương hiệu và đội ngũ.

Nợ kỹ thuật được đo thế nào để đưa vào định giá?

Cách thực tế là thuê đánh giá mã độc lập: rà kiến trúc, độ bao phủ kiểm thử, phiên bản thư viện, lỗ hổng bảo mật đã biết, rồi ước tính số người-tháng cần để đưa hệ thống về mức bảo trì bình thường. Con số đó được trừ khỏi giá trị hoặc phản ánh trong tỷ suất chiết khấu, không trừ hai lần.

Phần mềm dùng nhiều mã nguồn mở có giá trị thấp hơn không?

Không nhất thiết. Hầu hết phần mềm hiện đại dùng mã nguồn mở, và điều đó giảm chi phí tạo ra. Giá trị nằm ở phần doanh nghiệp tự viết và cách ghép các thành phần thành sản phẩm hữu ích. Vấn đề chỉ phát sinh khi giấy phép mâu thuẫn với mô hình kinh doanh hoặc doanh nghiệp vi phạm điều kiện giấy phép.

Tuổi đời kinh tế của phần mềm thường là bao lâu?

Tuỳ loại. Phần mềm hệ thống lõi trong ngân hàng hay sản xuất có thể chạy hơn mười năm; ứng dụng di động hay phần mềm web cạnh tranh gay gắt có thể phải viết lại sau ba đến năm năm. Căn cứ tốt nhất là lịch sử thay thế hệ thống trong chính doanh nghiệp và ngành, kèm lộ trình hỗ trợ của nền tảng công nghệ đang dùng.

Phần mềm có thể góp vốn vào công ty không?

Quyền tác giả đối với chương trình máy tính là quyền tài sản có thể góp vốn nếu người góp là chủ sở hữu hợp pháp. Cần làm rõ góp quyền sở hữu hay chỉ góp quyền sử dụng, định giá theo đúng phạm vi đó và hoàn tất thủ tục chuyển quyền. Nên kiểm văn bản hiện hành và hỏi luật sư trước khi lập hồ sơ.

Cần tư vấn cụ thể cho trường hợp của bạn?

Chúng tôi sẽ liên hệ trong vòng 24 giờ.

Đăng ký tư vấn ngay

Bài viết liên quan

Bạn cần hỗ trợ thêm?

Để lại thông tin, chúng tôi sẽ liên hệ trong 24 giờ.