Viết phần mềm theo yêu cầu: vì sao vẫn cần khi SaaS tràn ngập

Viết phần mềm theo yêu cầu vẫn cần năm 2026, nhưng chỉ cho một phần nhỏ của công ty: phần quy trình làm nên khác biệt và gói phần mềm có sẵn không diễn đạt được. Kế toán, hoá đơn điện tử, email, lưu trữ tài liệu nên mua. Cách công ty tính thưởng, chia ca, duyệt đơn theo luật riêng, chăm sóc khách theo kiểu riêng thì nên may đo, hoặc ít nhất may đo lớp nối các gói có sẵn lại với nhau. Sai lầm hay gặp nhất là làm ngược lại: viết lại thứ thị trường đã làm tốt, rồi mua phần mềm đóng gói cho đúng chỗ công ty cần khác người.

Bài này đi từ số liệu thị trường SaaS, qua các tiêu chí chọn, tới cái giá thật của phần mềm riêng. Ví dụ lấy từ ALODEV AIO, phần mềm quản trị nội bộ ALODEV tự viết và đang dùng hằng ngày, với số đo lấy thẳng từ kho mã.

SaaS tràn ngập, và phí thì nằm ở chỗ không ai nhìn

Zylo, công ty quản lý chi tiêu phần mềm, công bố bộ chỉ số SaaS Management Index 2026 ngày 29/01/2026, dựa trên hơn 40 triệu giấy phép SaaS họ theo dõi. Một tổ chức trung bình trong dữ liệu của họ quản lý 305 ứng dụng, và để trống trung bình 36% số giấy phép đã mua. Tập khách của Zylo nghiêng về doanh nghiệp lớn ở Mỹ, nên con số tuyệt đối không áp thẳng cho công ty 50 người ở Việt Nam. Nhưng hình dạng của vấn đề thì giống: mỗi phòng tự mua một công cụ, dữ liệu nằm rải rác, và không ai biết tổng mình đang trả cho bao nhiêu thứ.

Với doanh nghiệp vừa và nhỏ ở Việt Nam, câu chuyện quen thuộc hơn là ba tới năm phần mềm không nói chuyện với nhau: một phần mềm bán hàng, một phần mềm chấm công, một bảng tính lương, một nhóm chat để duyệt đơn. Mỗi thứ đều tốt ở phần của nó. Chi phí thật nằm ở người phải chép dữ liệu từ chỗ này sang chỗ kia mỗi cuối tháng, và ở những lần chép sai.

Phần mềm có sẵn giỏi ở đâu, hụt ở đâu

Phần mềm đóng gói được viết cho điểm chung của hàng nghìn khách. Ở những nghiệp vụ mà luật pháp hoặc thông lệ đã chuẩn hoá, như hạch toán, hoá đơn điện tử, khai báo bảo hiểm, điểm chung đó gần như là toàn bộ nhu cầu. Viết lại những phần này là đốt tiền: phải tự theo kịp mỗi lần luật đổi, trong khi nhà cung cấp đã có cả đội làm việc đó.

Hụt hẫng bắt đầu ở những quy tắc chỉ công ty mình có. Nhà cung cấp SaaS thường cho cấu hình trường dữ liệu, trạng thái, mẫu in. Họ hiếm khi cho cấu hình luật tính toán phụ thuộc lẫn nhau giữa nhiều phân hệ. Khi luật của công ty không vừa khuôn, người dùng đi vòng: xuất Excel, tính tay, nhập lại. Phần mềm vẫn chạy, còn quy trình thật thì sống ngoài phần mềm.

Một ví dụ nhỏ từ ALODEV. Công ty có lịch trực bếp buổi trưa: mỗi ca ba người, ba người tự chia nhau nấu, rửa bát của bữa trước và đổ rác, tính vào giờ làm, không có ca vào Chủ nhật và ngày lễ, người nghỉ phép hôm đó được bỏ qua mà không bị đẩy khỏi vòng xoay. Luật này được CEO chốt ngày 07/09/2026 qua 15 câu hỏi và ghi thành tệp thiết kế trong kho mã. Nó cần đọc dữ liệu nghỉ phép thật để quyết định ai trực hôm nay. Một phần mềm chia ca có sẵn làm được phần xoay vòng, nhưng không biết ai đang nghỉ phép vì dữ liệu đó nằm ở phần mềm nhân sự khác.

Bảng so sánh ba cách làm

Cái giá thật của phần mềm may đo

Người bán dịch vụ viết phần mềm thường nói nhiều về lợi ích và ít về cái giá. Số đo dưới đây lấy từ chính kho mã ALODEV AIO, để người mua hình dung một phần mềm nội bộ cỡ vừa đòi hỏi bao nhiêu công sức.

Ngày 25/09/2026, ALODEV AIO có 105 màn hình (71 màn khu quản trị, 28 màn cổng nhân viên, còn lại là đăng nhập, in ấn), khoảng 125 nghìn dòng Go ở backend và 161 nghìn dòng TypeScript ở giao diện, phục vụ khoảng mười một người dùng thật hằng ngày. Con số dòng mã gồm cả chú thích, nhưng vẫn cho thấy: một phần mềm quản trị nội bộ đủ dùng không phải là vài màn nhập liệu.

Cái giá thứ hai ít người nói: phần mềm may đo rất dễ phình ra những thứ không ai dùng. Ngày 17/09/2026, ALODEV xoá 11 màn của chính AIO sau khi đo 12 ngày trên hệ thống thật và thấy 0 lượt mở, hoặc dữ liệu đã chuyển sang màn mới. Trước đó, một tính năng thảo luận được dựng hai giao diện trong khi cả công ty mới dùng đúng một lần. Khi viết phần mềm theo yêu cầu, mọi ý tưởng của người đặt hàng đều trở thành được. Đó vừa là điểm mạnh, vừa là cách chi phí bảo trì tăng mà không ai để ý.

Khi nào nên viết phần mềm theo yêu cầu

• Quy trình là lợi thế cạnh tranh: cách báo giá, cách chia hoa hồng, cách điều phối đơn mà đối thủ không có. Đưa quy trình đó vào phần mềm chung là tự san phẳng lợi thế.
• Nhiều phân hệ phải đọc dữ liệu của nhau theo luật riêng, như chấm công ảnh hưởng thưởng, nghỉ phép ảnh hưởng lịch trực. Nối nhiều gói có sẵn cho việc này thường mong manh hơn một hệ thống thống nhất.
• Số người dùng lớn và tăng đều, khiến phí thuê bao tính theo đầu người vượt chi phí tự vận hành trong vài năm.
• Dữ liệu nhạy cảm cần nằm trên máy chủ công ty kiểm soát, hoặc cần phân quyền chi tiết hơn mức gói có sẵn cho phép.
• Công ty đã thử gói có sẵn và thấy nhân viên đi vòng bằng Excel ở cùng một chỗ, tháng này qua tháng khác.

Khi nào KHÔNG nên viết phần mềm theo yêu cầu

• Nghiệp vụ đã được luật chuẩn hoá: kế toán, hoá đơn điện tử, khai thuế, bảo hiểm xã hội. Mua phần mềm chuyên dụng và dùng API của nó.
• Công ty chưa viết ra được quy trình của chính mình. Phần mềm may đo chỉ tốt bằng yêu cầu; quy trình còn đổi hằng tuần thì mua gói linh hoạt để học trước, may đo sau.
• Không có ai phía công ty chịu trách nhiệm sản phẩm: duyệt màn, trả lời câu hỏi nghiệp vụ, quyết định bỏ tính năng. Thiếu vai trò này, đơn vị làm phần mềm sẽ đoán, và đoán thì sai.
• Ngân sách chỉ đủ cho lần viết đầu, không có phần bảo trì hằng năm. Phần mềm không được bảo trì sẽ tụt bản thư viện, lộ lỗ hổng, và thành gánh nặng sau hai năm.
• Nhu cầu chỉ là một website giới thiệu hoặc một cửa hàng trực tuyến tiêu chuẩn.

Cách chia đôi hợp lý: mua lõi chuẩn, may đo phần khác biệt

Con đường ít rủi ro nhất cho phần lớn doanh nghiệp vừa là chia hai lớp. Lớp dưới là các phần mềm chuẩn đã mua: kế toán, hoá đơn, email. Lớp trên là phần mềm may đo mỏng, chỉ chứa quy trình riêng và các đường nối dữ liệu. Mã của website alodev.vn được viết theo kiểu này: form khách để lại trên website gửi thẳng vào AIO qua một đường nhận dữ liệu riêng, nếu AIO không trả lời thì xếp vào hàng đợi và gửi lại sau mỗi phút, nên không có khách nào bị rơi giữa hai hệ thống.

Ba điều khoản nên có trong hợp đồng viết phần mềm theo yêu cầu để tránh phụ thuộc đơn vị làm:

1. Công ty sở hữu mã nguồn và nhận kho mã (kể cả lịch sử commit), không chỉ nhận bản cài đặt.
2. Tài liệu vận hành nằm trong kho mã: cách chạy, cách sao lưu, cách đưa bản mới lên, những luật đã trả giá. Người mới đọc là tiếp quản được.
3. Dữ liệu xuất được ra định dạng chuẩn bất cứ lúc nào, và có môi trường chạy thử tách khỏi hệ thống thật để kiểm từng bản trước khi dùng.

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

Viết phần mềm theo yêu cầu mất bao lâu?

Bản đầu dùng được cho một quy trình rõ ràng thường mất vài tuần tới vài tháng. Thời gian phụ thuộc vào độ rõ của yêu cầu nhiều hơn số màn: một quy trình đã viết ra giấy đầy đủ nhanh hơn nhiều so với vừa làm vừa bàn.

Phần mềm may đo khác phần mềm đóng gói thế nào?

Phần mềm đóng gói viết một lần cho nhiều khách, công ty cấu hình trong giới hạn nhà cung cấp cho phép. Phần mềm may đo viết cho quy trình của một công ty, công ty sở hữu mã và tự quyết lộ trình, đổi lại phải tự lo bảo trì.

Có nên thay toàn bộ phần mềm đang dùng bằng một hệ thống tự viết không?

Hiếm khi nên. Giữ những phần mềm chuẩn đang chạy ổn như kế toán, hoá đơn điện tử, và chỉ viết phần quy trình riêng cộng lớp nối dữ liệu giữa chúng.

Làm sao tránh bị phụ thuộc vào đơn vị viết phần mềm?

Ghi vào hợp đồng quyền sở hữu mã nguồn, nhận toàn bộ kho mã kèm lịch sử, và yêu cầu tài liệu vận hành nằm trong kho. Mỗi quý thử cho một người ngoài đọc tài liệu và chạy hệ thống trên máy thử.