Vì sao việc đánh giá đối tác cần xét cả năng lực lẫn trách nhiệm giải trình, cấp độ đối tác Odoo cho biết gì và không cho biết gì, cùng checklist thực tế cho doanh nghiệp.
Doanh nghiệp thường mất nhiều tháng để cân nhắc một giải pháp ERP: lập hồ sơ yêu cầu (RFP), xem demo, đàm phán bản quyền và tính toán ngân sách cho nhiều năm. Thế nhưng, đơn vị trực tiếp thiết kế, cấu hình, lập trình và đồng hành cùng hệ thống đôi khi lại được lựa chọn trong một khoảng thời gian ngắn hơn rất nhiều.
Sự lệch pha này là điều người mua nên lưu ý.
Vấn đề không phải vì chọn đối tác quá khó, mà vì nhiều quy trình đánh giá xem rất kỹ năng lực triển khai, trong khi trách nhiệm của đối tác lại thường chỉ được kiểm tra như một thủ tục.
Một quy trình đánh giá thực chất nên bắt đầu bằng hai câu hỏi cốt lõi:
- Năng lực: Đối tác có đủ khả năng thực hiện đúng loại dự án bạn đang triển khai không?
- Trách nhiệm giải trình: Đề xuất của đối tác có phù hợp với lợi ích của bạn không, các cam kết có thể kiểm chứng được không, và ai sẽ đứng ra chịu trách nhiệm khi mọi thứ không đi đúng kế hoạch?
Partner status chính thức, chứng chỉ chuyên môn và sự hiện diện trong danh bạ đối tác của Odoo là những tín hiệu tham khảo hữu ích và là một điểm khởi đầu hợp lý. Tuy nhiên, với một dự án Odoo phức tạp, những thông tin đó chỉ phản ánh một phần những gì doanh nghiệp cần biết.
Trước khi đánh giá đối tác: hãy hiểu rõ loại hình dự án của bạn
Tiêu chí đánh giá đối tác phụ thuộc rất nhiều vào loại dự án doanh nghiệp đang triển khai.
- Dự án ưu tiên tính năng chuẩn (Configuration-led): Chủ yếu sử dụng các phân hệ tiêu chuẩn của Odoo và hạn chế phát triển tùy chỉnh. Với nhóm này, số lượng dự án đã thực hiện, chứng chỉ chuyên môn và kinh nghiệm triển khai theo mô hình chuẩn của Odoo có thể là những chỉ số hữu ích.
- Dự án ưu tiên tùy biến (Customization-led): Cần phát triển thêm các phân hệ riêng, xử lý nghiệp vụ đặc thù hoặc tích hợp sâu với hệ thống khác. Lúc này, kinh nghiệm thiết kế kiến trúc và chiều sâu kỹ thuật trở nên quan trọng hơn. Một đơn vị từng triển khai nhiều dự án chuẩn chưa chắc đã phù hợp với một bài toán mà phần lớn phạm vi nằm ở phát triển tùy chỉnh.
- Dự án sử dụng Odoo Community: Community có thể là lựa chọn phù hợp khi những chức năng doanh nghiệp thực sự cần chưa đủ để hợp lý hóa chi phí thuê bao Enterprise, đặc biệt với doanh nghiệp có nhiều người dùng, quy trình cần tùy chỉnh nhiều hoặc vẫn sử dụng một hệ thống kế toán riêng. Community mang lại nhiều quyền chủ động hơn trên nền tảng mã nguồn mở, nhưng cũng đòi hỏi một kế hoạch rõ ràng cho phát triển tùy chỉnh, bảo trì, bảo mật và nâng cấp.
Ranh giới giữa các dạng dự án này không hoàn toàn tách biệt. Một dự án Enterprise vẫn có thể được tùy biến rất sâu, trong khi một dự án Community có thể gần như sử dụng chuẩn hoặc phát triển thành một hệ thống lớn và phức tạp về mặt kỹ thuật. Điều quan trọng là bạn phải hiểu rõ bài toán của chính mình trước khi bắt đầu so sánh các đối tác.
Câu hỏi 1: Năng lực triển khai
Tìm kiếm độ phức tạp tương đồng, đừng chỉ nhìn vào ngành nghề
Kinh nghiệm ngành là một lợi thế, nhưng việc chỉ tìm đối tác có dự án trong cùng ngành có thể dẫn đến đánh giá chưa đầy đủ nếu bản chất kỹ thuật giữa hai dự án rất khác nhau.
- Độ phức tạp: Đối tác đã từng xử lý mức độ phát triển tùy chỉnh, kiến trúc tích hợp hay logic nghiệp vụ đặc thù tương tự chưa? Một đơn vị từng xây dựng hệ thống bổ sung hàng đa kho phức tạp cho doanh nghiệp phân phối thực phẩm có thể mang lại kinh nghiệm kỹ thuật phù hợp hơn cho một dự án phân phối dược phẩm so với một đơn vị mà kinh nghiệm trong ngành dược chỉ là triển khai theo quy trình chuẩn.
- Quy mô: Số lượng người dùng, dung lượng dữ liệu, số pháp nhân, các điểm tích hợp, khối lượng giao dịch và phạm vi vận hành đều tác động trực tiếp đến độ khó khi triển khai và hỗ trợ hệ thống.
- Am hiểu ngành: Năng lực kỹ thuật không thể thay thế hoàn toàn kiến thức ngành. Đối tác cần hiểu đủ về bối cảnh kinh doanh của bạn để nhận diện các ràng buộc quan trọng mà không cần bạn phải giải thích lại mọi khái niệm từ đầu.
Vì lý do bảo mật (NDA), đối tác không phải lúc nào cũng có thể công khai danh tính khách hàng. Điều quan trọng hơn là họ có thể mô tả công việc đã làm đủ cụ thể và thuyết phục hay không.
Câu nói “Chúng tôi đã triển khai nhiều dự án sản xuất phức tạp” tự nó cho bạn rất ít thông tin. Giá trị nằm ở việc đối tác có thể giải thích bài toán gặp phải, vì sao Odoo chuẩn chưa đáp ứng, họ đã xử lý như thế nào và kết quả sau đó ra sao.
Nếu có cơ hội trao đổi trực tiếp với khách hàng cũ của họ (reference call), hãy hỏi: “Dự án đã gặp vấn đề gì và đối tác đã xử lý ra sao?” Cách một đơn vị phản ứng khi có vấn đề thường cho thấy nhiều hơn về năng lực triển khai so với một lời nhận xét chung rằng khách hàng có hài lòng hay không.
Hiểu rõ cách giải pháp sẽ được xây dựng
Đối với bất kỳ dự án nào có phát triển tùy chỉnh, bạn cần làm rõ giải pháp sẽ được thiết kế, phát triển và kiểm soát chất lượng như thế nào.
Một số đơn vị có đội ngũ tư vấn nghiệp vụ mạnh nhưng năng lực phát triển kỹ thuật hạn chế. Số khác thuê ngoài một phần công việc hoặc phụ thuộc nhiều vào các lập trình viên ít kinh nghiệm. Không mô hình nào mặc nhiên là vấn đề, nhưng bạn cần hiểu rõ mô hình delivery trước khi ký hợp đồng.
Hãy hỏi rõ:
- Ai chịu trách nhiệm về kiến trúc giải pháp?
- Đội ngũ được bố trí cho dự án dự kiến cần có mức độ kinh nghiệm Odoo như thế nào?
- Họ có sử dụng các phân hệ từ cộng đồng OCA khi phù hợp không?
- Phần phát triển tùy chỉnh được phân công và review như thế nào?
Trong các hợp đồng trọn gói (fixed-price), thành phần nhân sự cụ thể có thể thay đổi trong quá trình triển khai. Điều quan trọng là đối tác duy trì được mức năng lực cần thiết và tiếp tục chịu trách nhiệm về kết quả đã cam kết.
Nếu câu trả lời chỉ dừng lại ở quy mô nhân sự chung chung hay tổng số chứng chỉ của công ty, hãy tiếp tục hỏi. Những con số đó không cho bạn biết mô hình delivery có đủ năng lực để thiết kế, phát triển và duy trì giải pháp của mình hay không.
Đánh giá khả năng xử lý vấn đề
Dự án ERP phức tạp hiếm khi đi chính xác theo kế hoạch ban đầu. Yêu cầu thay đổi, các điểm tích hợp hoạt động khác dự kiến, dữ liệu chưa chuẩn hoặc giai đoạn UAT làm bộc lộ khoảng cách giữa tài liệu thiết kế và nhu cầu thực tế của người dùng.
Hãy hỏi đối tác cách họ quản lý thay đổi phạm vi (scope change), xử lý vấn đề trong UAT hoặc những trường hợp tính năng bàn giao không đúng với những gì đã thống nhất. Điều bạn cần không phải là một phương pháp luận cụ thể, mà là bằng chứng cho thấy họ đã gặp những tình huống tương tự và có cách xử lý thực tế.
Kế hoạch cho giai đoạn sau go-live
Phát triển tùy chỉnh làm thay đổi đáng kể bài toán bảo trì và nâng cấp về sau.
Trên bản Enterprise, Odoo cung cấp lộ trình nâng cấp cho các ứng dụng tiêu chuẩn và những phần tùy chỉnh thuộc phạm vi của các thỏa thuận bảo trì tương ứng. Các phân hệ tùy chỉnh khác cần có kế hoạch bảo trì và nâng cấp riêng.
Hãy làm rõ: Ai sẽ hỗ trợ phần code viết riêng sau khi bàn giao? Cam kết chất lượng dịch vụ (SLA) ra sao? Điều gì sẽ xảy ra khi nâng cấp lên phiên bản Odoo mới?
Nếu sau 18 tháng, đội ngũ phát triển ban đầu không còn tham gia và cũng không có tài liệu bàn giao hay kế hoạch bảo trì rõ ràng, vấn đề cuối cùng sẽ quay trở lại với doanh nghiệp.
Quan sát cách đối tác làm việc ngay từ giai đoạn pre-sales
Quá trình đánh giá đối tác thực chất đã bắt đầu từ những buổi làm việc đầu tiên.
Một đội ngũ có kinh nghiệm thường chủ động tìm hiểu về chất lượng dữ liệu, hệ thống tích hợp, quy trình ra quyết định, nguồn lực nội bộ, quản trị thay đổi và các ràng buộc trước khi cam kết ngân sách hay tiến độ.
Tốc độ gửi proposal không quan trọng bằng chất lượng của quá trình discovery đứng phía sau nó. Một bản đề xuất đáp ứng mọi kỳ vọng nhưng không chỉ ra bất kỳ rủi ro nào là điều doanh nghiệp nên xem xét kỹ hơn.
Câu hỏi 2: Trách nhiệm giải trình
Năng lực trả lời cho câu hỏi đối tác có thể làm được hay không. Trách nhiệm giải trình liên quan đến cách họ đưa ra khuyến nghị, những chứng chỉ và partner status thực sự cho biết điều gì, và ai sẽ chịu trách nhiệm cho kết quả cuối cùng.
Hỏi tại sao giải pháp này được khuyến nghị
Đối tác triển khai có ảnh hưởng đáng kể đến các quyết định quan trọng: sử dụng edition nào, licensing ra sao, lựa chọn hạ tầng thế nào, mức độ tùy chỉnh đến đâu và phạm vi dự án gồm những gì.
Những đề xuất này nên bắt đầu từ nhu cầu thực tế và bài toán kinh tế dài hạn của doanh nghiệp.
Cả Enterprise và Community đều có thể là lựa chọn đúng. Phương án phù hợp phụ thuộc vào các yếu tố như số lượng người dùng, khoảng trống chức năng, nhu cầu tùy chỉnh, chiến lược nâng cấp và tổng chi phí theo thời gian. Trong một số trường hợp, tính năng và dịch vụ hỗ trợ của Enterprise có thể giảm đủ khối lượng phát triển tùy chỉnh để chi phí thuê bao trở nên hợp lý. Trong những trường hợp khác, chi phí thuê bao Enterprise khó hợp lý hóa hơn, và Community sẽ là lựa chọn phù hợp hơn.
Đề xuất đúng đôi khi cũng có thể là làm ít đi. Một phạm vi nhỏ hơn có thể hợp lý hơn, hoặc áp dụng quy trình chuẩn có thể tốt hơn một tùy chỉnh mà doanh nghiệp yêu cầu ban đầu.
Vì vậy, bạn nên yêu cầu đối tác giải thích không chỉ nên chọn phương án nào, mà còn tại sao. Những phương án thay thế nào đã được cân nhắc? Mỗi phương án có những đánh đổi gì về chức năng, tùy chỉnh, bảo trì, nâng cấp và tổng chi phí?
Động cơ thương mại tồn tại ở tất cả các phía. Đối tác Odoo có thể nhận hoa hồng từ subscription Enterprise, trong khi đơn vị triển khai cũng tạo doanh thu từ các dịch vụ như phân tích, phát triển, tùy chỉnh, hosting và hỗ trợ.
Điều này hoàn toàn bình thường trong kinh doanh. Chính vì vậy, việc doanh nghiệp muốn hiểu một khuyến nghị được hình thành như thế nào là hợp lý.
Hiểu đúng về cấp độ đối tác (partner status)
Partner status và các chứng chỉ Odoo là những chứng nhận chính thức, nhưng chúng đo lường những chỉ số rất cụ thể.
Cấp độ đối tác Odoo được xác định dựa trên số lượng người dùng Odoo Enterprise mới, số nhân sự nội bộ có chứng chỉ và tỷ lệ giữ chân khách hàng, chứ không trực tiếp dựa trên quy mô hay độ phức tạp kỹ thuật của các dự án mà một công ty đã triển khai.
Do các dự án Community không đóng góp vào chỉ số người dùng Enterprise, kinh nghiệm triển khai Community của một đơn vị có thể không được phản ánh qua cấp độ đối tác chính thức.
Bạn nên xác minh thông tin trong danh bạ đối tác công khai của Odoo, hiểu rõ các chỉ số đó đại diện cho điều gì, rồi tiếp tục xem xét những bằng chứng liên quan trực tiếp đến bài toán của doanh nghiệp.
Danh bạ này cũng là một cách thực tế để tìm kiếm đối tác, nhưng nó liệt kê các công ty được công nhận thông qua chương trình đối tác chính thức của Odoo. Bên ngoài chương trình này cũng có những đơn vị triển khai độc lập và các đơn vị chuyên về mã nguồn mở, và một số có lịch sử triển khai các dự án đáng kể. Việc không có tên trong danh bạ không chứng minh năng lực, nhưng cũng không có nghĩa là đơn vị đó không có năng lực. Điều đó chỉ có nghĩa là bằng chứng cần được tìm ở những nơi khác: các case study phù hợp, khách hàng tham chiếu, lịch sử kỹ thuật, đóng góp mã nguồn khi có liên quan, khả năng hỗ trợ liên tục và trách nhiệm được quy định trong hợp đồng.
Xác định rõ ai chịu trách nhiệm cuối cùng
Đơn vị đứng tên ký hợp đồng chưa chắc đã là bên trực tiếp thực hiện toàn bộ công việc. Phần phát triển có thể được thuê ngoài, chia sẻ với công ty liên kết hoặc phân chia cho nhiều bên chuyên trách.
Hãy làm rõ ai chịu trách nhiệm về chất lượng, hỗ trợ và escalation path.
Hợp đồng cũng cần quy định rõ về quyền sở hữu mã nguồn tùy chỉnh và quyền sở hữu trí tuệ (IP), tài liệu và nghĩa vụ bàn giao, trách nhiệm hỗ trợ, phương án xử lý khi nhân sự chủ chốt hoặc một bên tham gia triển khai rời dự án, cũng như luật áp dụng và cơ chế giải quyết tranh chấp có thực tế đối với các bên liên quan hay không.
Danh sách kiểm tra thực tế dành cho người mua
Trước khi quyết định chọn đối tác triển khai Odoo, hãy đảm bảo bạn đã có câu trả lời rõ ràng cho các câu hỏi sau:
- Đơn vị này đã từng triển khai các dự án có độ phức tạp, quy mô và yêu cầu tích hợp tương đương chưa?
- Mô hình triển khai của họ là gì, và phần phát triển tùy chỉnh sẽ được bố trí nguồn lực cũng như review như thế nào?
- Đội ngũ dự án xử lý ra sao khi có thay đổi phạm vi, vấn đề UAT hay các tình huống phát sinh trong quá trình triển khai?
- Điều gì sẽ xảy ra với các phân hệ viết riêng và các điểm tích hợp sau Go-Live và trong những lần nâng cấp Odoo sau này?
- Tại sao edition, mô hình licensing và kiến trúc được đề xuất lại phù hợp với dự án này, và những phương án thay thế nào đã được cân nhắc?
- Partner status và các chứng chỉ Odoo của đối tác thực sự xác nhận điều gì?
- Ai chịu trách nhiệm cuối cùng về kết quả triển khai nếu có nhà thầu phụ, công ty liên kết hoặc nhiều bên cùng tham gia?
- Hợp đồng có cung cấp các điều khoản bảo vệ thực tế cho doanh nghiệp nếu mối quan hệ hợp tác hoặc dự án gặp vấn đề không?
Nếu những câu hỏi này chưa thể được trả lời rõ ràng trước khi dự án bắt đầu, quá trình đánh giá đối tác có lẽ vẫn chưa hoàn tất.
Hãy áp dụng chính tiêu chuẩn này với Trobz
Nếu bạn đang đánh giá Trobz, hãy hỏi chúng tôi sẽ bố trí nguồn lực và quản trị dự án như thế nào, đã triển khai những hệ thống tương đương nào, sẽ lựa chọn giữa Enterprise và Community ra sao, hỗ trợ phần phát triển tùy chỉnh như thế nào và hệ thống sẽ được duy trì ra sao trong dài hạn.
Trobz đã làm việc với Odoo từ năm 2009 trên cả các dự án Enterprise và Community tại Đông Nam Á và các thị trường quốc tế.
Với một dự án Odoo phức tạp, chúng tôi sẵn sàng trao đổi về phạm vi, các phương án đánh đổi và những rủi ro cần xem xét trước khi bạn đưa ra quyết định. Những câu hỏi trong bài viết này cũng chính là những câu hỏi mà chúng tôi mong khách hàng đặt ra cho Trobz.
