Khi doanh nghiệp quyết định xây một hệ thống phần mềm riêng, việc khó không chỉ nằm ở chỗ xác định mình cần CRM, ERP hay một phần mềm quản lý nội bộ. Bài toán khó hơn là lựa chọn đúng đơn vị phát triển phần mềm có khả năng biến nhu cầu đó thành một hệ thống thực sự dùng được. Ba công ty có thể cùng nhận một yêu cầu và gửi lại ba mức giá rất khác nhau, trong khi bảng báo giá lại có những tên chức năng gần giống nhau như quản lý khách hàng, workflow, dashboard, báo cáo, phân quyền hay mobile responsive. Nếu chỉ nhìn vào danh sách tính năng và tổng giá cuối cùng, doanh nghiệp rất khó biết phương án nào thực sự tốt hơn.
Điểm khác biệt nằm ở chỗ phần mềm tùy chỉnh chưa tồn tại đầy đủ tại thời điểm ký hợp đồng. Doanh nghiệp không thể dùng thử sản phẩm hoàn chỉnh rồi mới quyết định như khi mua một phần mềm đóng gói. Vì vậy thứ cần đánh giá không chỉ là giá hay số lượng chức năng, mà là năng lực của đơn vị phát triển trong toàn bộ quá trình từ hiểu nghiệp vụ, thiết kế giải pháp, kiểm soát phạm vi, phát triển, kiểm thử cho tới bàn giao và tiếp tục vận hành sau này. Một lựa chọn sai có thể khiến doanh nghiệp tốn thêm nhiều tháng để sửa hệ thống, phụ thuộc lâu dài vào nhà cung cấp hoặc thậm chí phải xây lại từ đầu sau vài năm.
1. Đơn vị phát triển phải hiểu cách doanh nghiệp đang vận hành trước khi nói về công nghệ
Một dự án phần mềm tùy chỉnh không nên bắt đầu bằng việc liệt kê module. CRM, quản lý dự án, kho, báo giá hay dashboard chỉ là tên gọi của từng nhóm chức năng, trong khi giá trị của hệ thống nằm ở cách những chức năng đó phản ánh hoạt động thực tế của doanh nghiệp. Hai công ty cùng cần CRM có thể có quy trình bán hàng hoàn toàn khác nhau. Một doanh nghiệp bán hàng nhanh có thể chỉ cần quản lý lead và pipeline, trong khi một công ty bán thiết bị dự án phải theo dõi mối quan hệ với nhiều bên liên quan, lịch sử tiếp cận kéo dài nhiều năm, nhiều phiên bản báo giá và những thay đổi kỹ thuật trong suốt vòng đời dự án.
Nếu đơn vị phát triển chỉ nghe tên phần mềm rồi áp một cấu trúc quen thuộc vào doanh nghiệp, sản phẩm cuối cùng rất dễ trở thành một phiên bản khác của phần mềm đóng gói. Phần mềm tùy chỉnh chỉ thực sự có ý nghĩa khi đội phát triển hiểu được ai đang làm gì, dữ liệu đi qua đâu, bộ phận nào đang phải nhập lại thông tin, điểm nghẽn nằm ở đâu, bước nào có thể tự động hóa và bước nào vẫn cần con người quyết định. Sau giai đoạn khảo sát, một đơn vị có năng lực phải có khả năng mô tả lại quy trình của doanh nghiệp rõ hơn lúc bắt đầu và chỉ ra được những điểm phần mềm có thể cải thiện, chứ không chỉ gửi lại danh sách yêu cầu mà khách hàng đã cung cấp.
Đây cũng là lý do doanh nghiệp không nên đánh giá một đơn vị phát triển chỉ dựa vào khả năng viết code. Code là phần quan trọng, nhưng trước đó còn có một câu hỏi quan trọng hơn: hệ thống đang được xây có đúng là thứ doanh nghiệp cần hay không. Một hệ thống viết rất tốt nhưng giải quyết sai bài toán vẫn là một dự án thất bại.
2. Những gì đã hiểu phải được chuyển thành phạm vi triển khai đủ rõ
Sau khi hiểu nghiệp vụ, bước tiếp theo là biến những trao đổi ban đầu thành một phạm vi mà cả hai bên cùng hiểu giống nhau. Đây là một trong những phần quan trọng nhất của dự án vì phần lớn tranh cãi về sau không xuất phát từ lỗi kỹ thuật mà từ việc mỗi bên hình dung một chức năng theo một cách khác nhau. Một yêu cầu nghe rất đơn giản như “quản lý báo giá” có thể bao gồm nhiều phiên bản báo giá, quy trình duyệt chiết khấu, lịch sử thay đổi, xuất PDF, liên kết với BOQ và quyền xem khác nhau giữa sales, kỹ thuật và quản lý. Nếu những chi tiết này không được làm rõ ngay từ đầu, rất dễ phát sinh tình trạng một bên nghĩ chức năng đã nằm trong phạm vi còn bên kia xem đó là yêu cầu mới.
Phạm vi tốt không nhất thiết phải là một tài liệu dài hàng trăm trang. Với doanh nghiệp vừa và nhỏ, điều quan trọng hơn là nó đủ rõ để xác định hệ thống gồm những module nào, dữ liệu nào được quản lý, ai sử dụng, vai trò và quyền hạn ra sao, luồng chính vận hành thế nào, phần nào thuộc phiên bản đầu tiên và phần nào có thể phát triển sau. Khi các yếu tố này đã rõ, doanh nghiệp cũng dễ kiểm soát ngân sách hơn vì biết được đâu là phần lõi bắt buộc phải làm trước và đâu là những chức năng có thể tạm hoãn.
Báo giá vì vậy cũng nên phản ánh phạm vi thay vì chỉ đưa ra một con số tổng. Doanh nghiệp cần nhìn thấy cấu trúc của chi phí và hiểu mình đang trả tiền cho phần nào của hệ thống. Cách làm này không chỉ giúp kiểm soát chi phí mà còn tạo nền tảng cho việc nghiệm thu sau này, vì cả hai bên đã thống nhất ngay từ đầu thế nào mới được xem là hoàn thành.
3. Kinh nghiệm phải liên quan tới loại bài toán doanh nghiệp đang có
Quy mô công ty, số lượng developer hay danh sách khách hàng lớn đều có giá trị nhất định, nhưng chúng không tự động chứng minh một đơn vị phù hợp với dự án cụ thể. Một công ty có đội ngũ rất đông vẫn có thể mất nhiều thời gian để hiểu quy trình của một doanh nghiệp kỹ thuật nếu trước đó họ chủ yếu làm các hệ thống ở lĩnh vực hoàn toàn khác. Ngược lại, một đội nhỏ hơn nhưng đã từng xử lý các bài toán như BOQ, báo giá nhiều phiên bản, phân quyền nhiều cấp, quản lý lịch sử thay đổi, tích hợp hệ thống hoặc dữ liệu kỹ thuật có thể tiếp cận dự án nhanh và chính xác hơn.
Kinh nghiệm phù hợp cũng không có nghĩa nhà cung cấp nhất thiết phải từng làm đúng một sản phẩm giống hệt. Điều quan trọng hơn là họ đã từng giải quyết những vấn đề có mức độ phức tạp tương tự hay chưa. Một dự án ERP và một CRM bán hàng dự án có thể khác nhau rất nhiều về chức năng, nhưng cả hai đều có thể yêu cầu phân quyền phức tạp, audit, workflow, tích hợp nhiều hệ thống và quản lý dữ liệu xuyên suốt nhiều phòng ban. Đây mới là loại kinh nghiệm có khả năng chuyển đổi từ dự án cũ sang dự án mới.
Cách đánh giá tốt nhất không phải nhìn vào số lượng dự án đã làm mà xem đơn vị đó có thể giải thích được cách họ từng xử lý một vấn đề khó hay không. Khi một đội thực sự có kinh nghiệm, họ thường nói được khá rõ những lựa chọn đã cân nhắc, rủi ro từng gặp và lý do kiến trúc cuối cùng được chọn. Điều này có giá trị hơn nhiều so với một danh sách dài logo khách hàng.
4. Doanh nghiệp phải nhìn thấy sản phẩm trong suốt quá trình phát triển
Một dự án phần mềm không nên vận hành theo kiểu ký hợp đồng rồi chờ tới ngày cuối mới được xem sản phẩm hoàn chỉnh. Càng đợi lâu để kiểm tra, chi phí sửa sai càng lớn. Một màn hình hoặc một luồng thao tác chưa hợp lý nếu được phát hiện từ lúc mới thiết kế có thể sửa rất nhanh, nhưng nếu database, API và hàng loạt chức năng phía sau đã được xây quanh cấu trúc đó thì một thay đổi nhỏ có thể ảnh hưởng tới cả hệ thống.
Cách triển khai hợp lý hơn là chia quá trình thành từng giai đoạn có thể kiểm tra được. Sau khi phân tích có thể duyệt cấu trúc dữ liệu và luồng thao tác chính, tiếp theo là giao diện hoặc prototype, sau đó phát triển từng module và demo theo từng đợt. Khi hệ thống đã tương đối ổn định, doanh nghiệp nên được chạy thử với dữ liệu thật và một nhóm người dùng thật trước khi Go-live toàn bộ. Nhờ vậy, những vấn đề chỉ xuất hiện trong thực tế sử dụng có thể được phát hiện trước khi hệ thống trở thành công cụ vận hành chính thức.
Việc này không nhằm để khách hàng theo dõi lập trình viên làm việc từng ngày. Giá trị nằm ở chỗ doanh nghiệp có thể kiểm chứng rằng sản phẩm đang được xây đúng hướng. Phần mềm quản trị thường liên quan tới nhiều vai trò khác nhau, nên có những chi tiết chỉ lộ ra khi sales, quản lý, kỹ thuật hoặc kế toán trực tiếp sử dụng. Một quy trình nhìn rất hợp lý trên sơ đồ có thể trở nên bất tiện khi người dùng thực hiện hàng chục lần mỗi ngày. Phát hiện những vấn đề này trong quá trình phát triển luôn tốt hơn để tới ngày bàn giao mới nhận ra.
5. Quyền sở hữu dữ liệu, source code và hạ tầng phải được làm rõ từ đầu
Đây là tiêu chí thường bị bỏ qua vì ở giai đoạn đầu dự án, doanh nghiệp chủ yếu quan tâm hệ thống có hoạt động được hay không. Nhưng sau vài năm, quyền sở hữu có thể trở thành vấn đề quan trọng hơn rất nhiều. Doanh nghiệp cần biết source code được lưu ở đâu, repository thuộc tài khoản nào, database nằm trên hạ tầng của ai, domain đứng tên bên nào, backup được giữ ở đâu và ai đang nắm quyền quản trị cao nhất đối với hệ thống.
Một hệ thống có thể do đơn vị bên ngoài xây dựng và vận hành nhưng doanh nghiệp vẫn cần đủ khả năng tiếp quản nếu hoàn cảnh thay đổi. Điều này không có nghĩa khách hàng phải tự vận hành server hoặc tự quản lý kỹ thuật mỗi ngày. Nhiều doanh nghiệp không có đội IT riêng và hoàn toàn hợp lý khi thuê đối tác phụ trách những phần đó. Điểm quan trọng là quyền sở hữu và quyền kiểm soát phải rõ ràng, để khi cần doanh nghiệp có thể lấy dữ liệu, chuyển hệ thống hoặc bàn giao cho một đội kỹ thuật khác mà không bị giữ lại bởi một tài khoản hoặc hạ tầng chỉ nhà cung cấp mới có quyền truy cập.
Với phần mềm tùy chỉnh, đây là một phần của bảo mật chứ không chỉ là vấn đề hợp đồng. Dữ liệu khách hàng, lịch sử giao dịch, báo giá, quy trình nội bộ và nhiều năm vận hành có thể trở thành một trong những tài sản số quan trọng nhất của doanh nghiệp. Một hệ thống càng gắn sâu với hoạt động kinh doanh thì doanh nghiệp càng nên hiểu rõ chính xác phần nào mình sở hữu và phần nào đang phụ thuộc vào nhà cung cấp.
6. Hệ thống phải có khả năng tiếp tục sống sau ngày Go-live
Nghiệm thu không phải điểm kết thúc của một phần mềm doanh nghiệp. Sau vài tháng sử dụng thực tế, gần như chắc chắn sẽ xuất hiện những nhu cầu mới như thay đổi cơ cấu tổ chức, thêm quyền, bổ sung báo cáo, chỉnh workflow, kết nối phần mềm khác hoặc mở thêm một nhóm nghiệp vụ mới. Một hệ thống tốt phải có khả năng thích nghi với những thay đổi này mà không cần xây lại từ đầu mỗi lần doanh nghiệp thay đổi cách vận hành.
Vì vậy ngay trước khi ký hợp đồng, doanh nghiệp nên hiểu rõ cơ chế hỗ trợ sau bàn giao. Thời gian bảo hành, cách xử lý bug, chi phí thay đổi, maintenance có bắt buộc hay không và cách tính khi bổ sung chức năng đều cần được làm rõ. Một báo giá ban đầu thấp nhưng mọi thay đổi nhỏ về sau đều đắt hoặc chỉ một người duy nhất có thể sửa hệ thống chưa chắc là phương án rẻ khi nhìn trong vòng ba đến năm năm.
Khả năng tiếp quản về kỹ thuật cũng cần được tính đến. Code không nhất thiết phải hoàn hảo hoặc tài liệu phải dày, nhưng hệ thống không nên trở thành một hộp đen mà chỉ đúng người viết ban đầu mới hiểu. Cấu trúc dữ liệu, tài khoản, deployment và những phần quan trọng của hệ thống phải đủ rõ để một đội kỹ thuật khác có khả năng tiếp tục phát triển khi cần. Khi đạt được điều này, phần mềm mới thực sự trở thành một tài sản dài hạn của doanh nghiệp thay vì một dự án phải phụ thuộc vô hạn vào một nhà cung cấp.
Giá thấp nhất chưa chắc là lựa chọn có chi phí thấp nhất
Giá chắc chắn vẫn là một tiêu chí quan trọng khi doanh nghiệp lựa chọn đơn vị phát triển. Không có lý do gì phải trả nhiều hơn nếu hai phương án thực sự tương đương. Vấn đề là hai bảng báo giá cùng ghi CRM, workflow hay dashboard chưa chắc đang nói về cùng một mức chất lượng, cùng một kiến trúc hoặc cùng một mức độ hoàn thiện.
Một bên có thể chỉ xây các màn hình nhập và xem dữ liệu cơ bản, trong khi bên khác đã tính tới lịch sử thay đổi, audit, phân quyền, backup, tích hợp và khả năng tiếp tục mở rộng. Nếu chỉ nhìn số lượng module, hai giải pháp có vẻ giống nhau nhưng chi phí vận hành dài hạn có thể rất khác. Ngược lại, doanh nghiệp cũng không nên chạy theo một hệ thống quá lớn ngay từ đầu. Phần mềm tùy chỉnh tốt không nhất thiết phải nhiều chức năng; nhiều trường hợp nên làm phần lõi thật chắc, đưa vào sử dụng rồi mới đầu tư tiếp khi nhu cầu thực sự xuất hiện.
Do đó tiêu chí lựa chọn cuối cùng không nên là công ty lớn nhất hay báo giá thấp nhất, mà là đơn vị có khả năng cân bằng được ba thứ: hiểu đúng bài toán, xây đúng mức doanh nghiệp cần và bàn giao một hệ thống mà doanh nghiệp có thể kiểm soát lâu dài.
Lựa chọn đơn vị phát triển thực chất là lựa chọn một đối tác giải quyết bài toán vận hành
Khi nhìn lại toàn bộ quá trình, sáu tiêu chí trên tạo thành một chuỗi khá rõ. Đơn vị phát triển phải hiểu cách doanh nghiệp vận hành, biến hiểu biết đó thành phạm vi cụ thể, có kinh nghiệm phù hợp, cho khách hàng nhìn thấy sản phẩm trong quá trình xây dựng, làm rõ quyền sở hữu và đảm bảo hệ thống có khả năng tiếp tục phát triển sau khi bàn giao. Thiếu một mắt xích trong chuỗi này đều có thể tạo ra rủi ro về sau.
Đây cũng là điểm khác biệt giữa việc thuê một đội nhận yêu cầu rồi viết code với việc tìm một đơn vị có khả năng xây phần mềm tùy chỉnh theo yêu cầu từ chính cách doanh nghiệp đang vận hành. Một dự án custom tốt không bắt đầu ở công nghệ và cũng không kết thúc ở ngày nghiệm thu. Nó bắt đầu từ bài toán vận hành và chỉ thực sự hoàn thành khi hệ thống trở thành một phần tự nhiên trong cách doanh nghiệp làm việc.
Chọn đơn vị phát triển phần mềm vì vậy không đơn giản là chọn người có thể viết ra một hệ thống. Doanh nghiệp đang chọn một đối tác sẽ cùng mình biến quy trình, dữ liệu và cách vận hành thành một tài sản số có thể sử dụng trong nhiều năm.