Contact Now
Kiến trúc & Quyết định

Mua phần mềm hay tự xây — khung quyết định cho doanh nghiệp Việt Nam

Không phải quy trình nào cũng đáng viết riêng, và không phải phần mềm đóng gói nào cũng vừa. Bài viết đưa ra bốn câu hỏi để quyết định, và cách tính chi phí thật của cả hai hướng.

Đăng ngày: 10 phút đọc Nice Solutions

Câu hỏi thường được đặt sai ngay từ đầu. "Nên mua hay nên tự xây" ngụ ý phải chọn một cho toàn bộ công ty. Thực tế, một doanh nghiệp vận hành tốt thường mua phần lớn và tự xây một phần rất nhỏ — và phần nhỏ đó được chọn rất kỹ.

Vấn đề vì thế không phải mua hay xây, mà là quy trình nào của bạn đủ đặc thù để đáng viết riêng.

Mặc định nên là mua

Điểm khởi đầu hợp lý: mua, trừ khi có lý do rõ ràng để không mua.

Lý do rất đơn giản. Một sản phẩm phục vụ mười nghìn khách hàng đã gặp và xử lý hàng nghìn trường hợp biên mà bạn chưa nghĩ tới. Nó có tài liệu, có cộng đồng, có người thứ ba biết dùng nó, và nó tiếp tục được cải thiện bằng tiền của mười nghìn khách hàng chứ không phải tiền của riêng bạn.

Kế toán, chấm công, email, quản lý tài liệu, CRM cơ bản — những bài toán này giống nhau ở mọi công ty. Tự xây một hệ thống chấm công là chọn cách trả nhiều tiền hơn để có sản phẩm kém hơn.

Bốn câu hỏi trước khi quyết định tự xây

Quy trình này có phải lợi thế cạnh tranh không?

Nếu khách hàng chọn bạn một phần vì cách bạn làm việc đó, thì đóng gói nó vào phần mềm riêng là hợp lý. Nếu quy trình chỉ là việc phải làm cho xong, giống mọi công ty khác, thì không.

Một đại lý vé máy bay có logic gộp giá và phân phối tồn chỗ riêng — đó là lợi thế. Cũng đại lý đó tính lương nhân viên như mọi công ty khác — đó không phải lợi thế.

Có sản phẩm nào trên thị trường mô tả đúng bài toán không?

Không phải "có gần giống không", mà là "có mô tả đúng không". Khoảng cách giữa hai điều đó thường được lấp bằng việc tuỳ chỉnh, và tuỳ chỉnh sâu một sản phẩm đóng gói thường đắt hơn và giòn hơn viết mới — vì mỗi lần nhà cung cấp nâng cấp, phần tuỳ chỉnh có thể vỡ.

Quy trình này còn thay đổi nhiều không?

Nếu nghiệp vụ đang thay đổi liên tục vì công ty đang tìm mô hình đúng, viết riêng lúc này là đóng băng một thứ chưa ổn định. Nên dùng tạm giải pháp có sẵn, kể cả khi không vừa lắm, cho tới khi quy trình đứng yên.

Ngược lại, nếu quy trình đã ổn định nhiều năm và mọi người đều biết nó phải chạy thế nào, đó là lúc viết riêng có nghĩa.

Bạn có người vận hành nó về sau không?

Đây là câu hay bị bỏ qua nhất, và nó quyết định nhiều hơn ba câu trên. Phần mềm viết riêng cần người bảo trì trong suốt vòng đời của nó, không chỉ trong lúc xây. Nếu công ty không có đội kỹ thuật và cũng không định thuê ngoài dài hạn, một hệ thống riêng sẽ dần trở thành thứ không ai dám động vào.

Tính chi phí cho đúng

So sánh thường bị lệch vì chỉ so tiền bỏ ra ban đầu.

Chi phí thật của mua gồm: phí thuê bao nhân với số năm dự kiến dùng, chi phí cấu hình và đào tạo ban đầu, chi phí tích hợp với hệ thống hiện có, và chi phí chuyển đổi nếu sau này phải đổi nhà cung cấp. Khoản cuối thường bị quên, và nó có thể lớn — dữ liệu nằm trong hệ thống của người khác không phải lúc nào cũng lấy ra được dễ dàng.

Chi phí thật của tự xây gồm: chi phí phát triển ban đầu, chi phí bảo trì hàng năm — kinh nghiệm chung là khoảng 15–20% chi phí ban đầu mỗi năm, nhưng con số này thay đổi nhiều theo loại hệ thống — chi phí hạ tầng, và chi phí cơ hội của thời gian đội kỹ thuật dành cho nó thay vì việc khác.

Có một khoản nữa hiếm khi được đưa vào bảng tính: chi phí của việc không làm gì. Nếu quy trình hiện tại đang khiến năm người dành mỗi ngày hai tiếng để chép dữ liệu giữa hai hệ thống, khoản đó đã đang được trả rồi, chỉ là nó nằm rải rác trong bảng lương nên không ai thấy.

Hướng thứ ba thường bị bỏ qua

Giữa mua và xây còn một lựa chọn: mua phần lõi, xây phần rìa.

Dùng một sản phẩm có sẵn cho phần chung, và viết riêng lớp mỏng phía trên để xử lý phần đặc thù, nối với nhau qua API. Cách này giữ được lợi thế của sản phẩm đóng gói ở phần không đặc thù, đồng thời cho phép làm đúng ý ở phần thực sự quan trọng.

Điều kiện để cách này chạy được là sản phẩm bạn mua phải có API tử tế. Đây nên là một tiêu chí đánh giá khi chọn nhà cung cấp, ngang hàng với tính năng — một sản phẩm nhiều tính năng nhưng đóng kín sẽ trở thành ngõ cụt sau vài năm.

Một phép thử nhanh

Nếu phải rút gọn thành một câu hỏi duy nhất: hàng ngày có ai đang xuất dữ liệu ra Excel để làm nốt phần việc mà hệ thống hiện tại không làm được không?

Nếu có, và việc đó lặp lại đều đặn, thì quy trình của bạn đã vượt ra ngoài thứ đang dùng. Bước tiếp theo chưa phải là đặt hàng viết phần mềm — mà là ngồi xem file Excel đó chứa gì. Nó là bản đặc tả yêu cầu chính xác nhất mà bạn có, và nó được viết bởi chính người cần dùng.


Nice Solutions phát triển phần mềm theo yêu cầu và tư vấn kiến trúc hệ thống cho doanh nghiệp. Nếu bạn đang cân nhắc giữa hai hướng và muốn có ý kiến từ bên ngoài, liên hệ với chúng tôi — kể cả khi kết luận là bạn nên mua.

  • phát triển phần mềm
  • chi phí
  • kiến trúc hệ thống

Bạn đang có một bài toán cụ thể?

Mô tả ngắn gọn tình huống của bạn. Chúng tôi phản hồi trong vòng 24 giờ làm việc, và nếu bài toán không thuộc phạm vi của mình, chúng tôi sẽ nói thẳng.

Liên hệ với chúng tôi

Điền thông tin bên dưới, chúng tôi sẽ liên hệ lại sớm nhất có thể