Bỏ qua để đến Nội dung

12 bước triển khai dự án Odoo ERP - Phần 1

Chắc hẳn bạn từng băn khoăn: Khi triển khai một dự án ERP trên nền tảng có sẵn như Odoo, quy trình cụ thể sẽ gồm những bước nào? Liệu có những điểm nào cần đặc biệt lưu ý hay không?

Trong bài viết này, mình chia sẻ 12 bước triển khai dự án Odoo ERP mà mình đã trực tiếp thực hiện và đúc kết trong hơn 6 năm qua.

Lưu ý: Bài viết được chia sẻ dưới góc nhìn thực tế của một IT Business Analyst kiêm Project Manager trong các dự án Odoo.


1. Tiếp nhận dự án

1.1 Kickoff nội bộ

Đầu tiên, bạn cần thực hiện bước kickoff nội bộ, mục đích để người quản lý dự án & đội sale, consultant có sự hiểu biết chung về thông tin dự án. Các thông tin chính gồm thông tin khách hàng (doanh nghiệp), mục tiêu, phạm vi, thời gian golive dự kiến mong muốn và đặc biệt các vấn đề mà doanh nghiệp đang gặp phải. Do đó, trước khi diễn ra buổi kickoff nội bộ, bạn cần chủ động đọc qua thông tin hợp đồng & phụ lục đi kèm, đồng thời nếu có thắc mắc, bạn cần chuẩn bị sẵn danh sách câu hỏi,... các hành động này nhằm đảm bảo rằng sau khi buổi kickoff nội bộ kết thúc, tất cả các thành viên trong cuộc họp & đặc biệt là quản lý dự án đã nắm rõ các thông tin liên quan đến dự án.   

Sau khi hoàn thành bước kickoff nội bộ, bạn cần lên roadmap dự án để xác định rõ các milestone, ở mỗi milestone cần nêu rõ các kết quả mong muốn đạt được. Sau đó, bạn cần trình bày roadmap để đội sale, consultant feedback thông tin. Nên nhớ rằng ở giai đoạn đầu dự án, hầu như mọi thông tin bạn nhận được đều từ phía đội sale, do đó việc này cần phải thực hiện trước khi tiến hành kickoff dự án với business.

1.2 Chuẩn bị nguồn nhân lực

 Dựa vào các thông tin ban đầu về mục tiêu, phạm vi, thời gian golive dự kiến & roadmap. Bạn cần thực hiện công tác chuẩn bị nguồn nhân lực - đây là một bước không thể thiếu trong công tác lên kế hoạch dự án, đồng thời giảm thiểu rủi ro về việc deliver outcome ở từng milestone diễn ra không đúng kế hoạch. Trong trường hợp đội ngũ của bạn không đủ để run theo đúng roadmap, bạn có thể yêu cầu cấp trên bổ sung thêm nguồn nhân lực, nếu không bạn cần deal roadmap với business để phù hợp với nguồn nhân lực hiện tại, tuy nhiên bạn cần chuẩn bị kỹ lưỡng về nội dung & cách trình bày. Trong trường hợp này, bạn cần build thêm roadmap backup để trình bày với business trong buổi kickoff dự án. 

1.3 Kickoff 

Ở giai đoạn khởi tạo dự án, toàn bộ thông tin ban đầu mang tính chất chủ quan từ nội bộ, các tình huống nhầm lẫn thông tin là điều khó tránh khỏi. Do đó, ngoài mục đích gặp gỡ, buổi kickoff còn giúp các bên xác nhận các thông tin về dự án. Các thông tin cần xác nhận gồm 

  • Bối cảnh sử dụng phần mềm hiện tại của doanh nghiệp
  • Phạm vi, mục tiêu dự án
  • Thời gian golive mong muốn 
  • Cách thức giao tiếp giữa hai bên; 
  • Các milestone chính ở từng giai đoạn 

và đặc biệt là các yêu cầu đến từ business (business requirement). 

2. Khởi gợi /khảo sát yêu cầu

2.1 Lập kế hoạch khảo sát chi tiết

Lập kế hoạch là một bước thiết yếu trong khi thực hiện dự án, đặc biệt ở giai đoạn khảo sát chi tiết. Để đạt được mục tiêu thu thập yêu cầu đầy đủ và đúng nhất có thể bạn nên dựa vào ngữ cảnh của doanh nghiệp mà có phương pháp khảo sát phù hợp. Nếu business có thể cung cấp đủ danh sách quy trình nghiệp vụ, bạn nên tổ chức khảo sát theo quy trình, nếu business không thể cung cấp danh sách quy trình vì một số lý do, bạn nên tổ chức khảo sát theo chức vụ. Cần lưu ý rằng, khi khảo sát theo quy trình, bạn cần nắm rõ các role tham gia trong quy trình tương ứng để lên kế hoạch khảo sát chi tiết. Nếu không, có thể trong buổi khảo sát, các role tương ứng sẽ vắng mặt vì lý do họ chưa được mời để tham gia các buổi làm việc tương ứng. Dẫn đến không đạt được kết quả như kỳ vọng và ảnh hưởng gián tiếp đến timeline của dự án.

Khi đã xác định rõ cách thức khảo sát, bạn cần lên kế hoạch khảo sát chi tiết. Các thông tin chính trong kế hoạch gồm thời gian thực hiện khảo sát, nội dung, địa điểm, các bên tham gia & mục tiêu của từng buổi khảo sát. Lưu ý cần có sự tham gia của trưởng bộ phận và ban dự án cho dù bạn lựa chọn cách thức khảo sát theo quy trình hoặc theo chức vụ. 

2.2 Chuẩn bị khảo sát

Ngoài việc lập kế hoạch khảo sát, bạn cần chuẩn bị danh sách câu hỏi khảo sát gồm các nhóm câu hỏi về công việc hằng ngày hoặc công việc tương ứng trong quy trình, các mẫu báo cáo cần thực hiện theo từng quy trình hoặc chức vụ. Tuy nhiên, bạn cũng có thể nhóm câu hỏi theo từng phân hệ triển khai. Đặc biệt, bạn cần nhấn mạnh để doanh nghiệp lưu ý chuẩn bị các vấn đề họ đang gặp phải về quy trình, hệ thống hiện tại.  

Tiếp theo, cần phân công vai trò cụ thể, chi tiết về vai trò, nhiệm vụ của từng thành viên khi tham gia khảo sát. Điều này rất quan trọng để tránh việc “cha chung không ai khóc”, một nhân sự đảm nhiệm việc điều phối cuộc họp, một nhân sự đảm nhiệm việc hỏi đáp, một nhân sự đảm nhiệm việc ghi chú thông tin & biên bản. Tuy nhiên, nhân sự đảm nhiệm hỏi đáp có thể nhận nhiệm vụ điều phối cuộc họp để tiết kiệm nguồn lực, thay vào đó vị trí còn lại sẽ chịu trách nhiệm sơ đồ hóa quy trình tại thời điểm diễn ra cuộc họp. Việc này sẽ giúp tiết kiệm thời gian triển khai dự án. Bên cạnh đó, cần đảm bảo rằng nhân sự đảm nhiệm hỏi đáp được trang bị đủ năng lực, kinh nghiệm tham gia khảo sát & đặc biệt cần nắm rõ bối cảnh của doanh nghiệp & các yêu cầu về mặt kinh doanh (business requirement). 

2.3 Chuẩn bị khảo sát

Khi bắt đầu buổi khảo sát, nhân sự điều phối sẽ giới thiệu về mục đích, nội dung chính của buổi họp, các thành phần trong ban khảo sát & vai trò của từng thành viên. Tiếp theo, bạn cần xin phép các thành viên tham gia phía doanh nghiệp về việc ghi âm hoặc record trong buổi meeting nhằm mục đích làm tư liệu. Hầu hết họ sẽ vui vẻ đồng đồng ý, tuy nhiên nếu họ “lắc đầu”, bạn cần tôn trọng quyết định của họ & không quên nhắc nhở thư ký cần tập trung nhất có thể để hoàn thành tốt nhiệm vụ ghi chú thông tin.

Tiếp theo, nhân sự đảm nhiệm hỏi đáp cần dựa vào danh sách câu hỏi khảo sát để khơi gợi yêu cầu nhưng cũng cần linh động ở việc hỏi đáp để tránh rập khuôn. Nhân sự thực hiện hỏi đáp lúc này giống như MC truyền hình, cần đặt ra các câu hỏi gợi mở để giúp các thành viên tham gia cuộc họp dễ dàng chia sẻ các thông tin liên quan đến công việc của họ. Cần chú ý rằng, khi ở vai trò hỏi đáp, bạn không chỉ đơn thuần thực hiện việc hỏi và đáp, thay vào đó, bạn hãy đặt mình vào vị trí của họ để có sự đồng cảm. Đồng thời, bạn cần tiếp nhận, phân tích & luôn có tư duy phản biện ở mỗi thông tin. Đặc biệt, bạn luôn cần đặt các câu hỏi tại sao để hiểu rõ mục đích về từng công việc, các vấn đề mà họ đang gặp phải hoặc các mong muốn mà họ đặt ra cho bạn. 

Nếu stakeholder đặt câu hỏi về mặt giải pháp, bạn có thể “say no” nhưng cần trả lời một cách khéo léo. Đôi lúc, stakeholder sẽ đề cập các thông tin liên quan đến dự án nhưng không phù hợp với mục tiêu của buổi khảo sát. Lúc này, bạn có thể đề cập lại mục tiêu của buổi khảo sát để họ hiểu rằng mình nên đưa ra các thông tin hoặc câu hỏi phù hợp. Một số trường hợp khác, stakeholder không nắm rõ nghiệp vụ hoặc nội bộ chưa thống nhất về mặt thông tin, họ thường sẽ trao đổi rất chi tiết về các vấn đề này. Việc này sẽ ảnh hưởng đến thời gian cuộc họp, lúc này bạn cần yêu cầu họ trao đổi & thống nhất ở các buổi họp nội bộ sau đó. Lưu ý, thư ký cần ghi chú lại các thông tin này để tránh tình trạng sót thông tin.

Các nhân sự còn lại ngoài nhiệm vụ chính, có thể hỗ trợ host đặt ra các câu hỏi, feedback về các thông tin cần phải làm rõ, hoặc bất kỳ thông tin nào khác mang lại giá trị cho buổi khảo sát.

 Vào cuối buổi khảo sát, thư ký cần review lại các nội dung của buổi họp, điều phối sẽ thực thông tin về next step để các bên cùng nắm thông tin. Sau buổi họp, thư ký cần format, điều chỉnh văn phong ở biên bản khảo sát, thực hiện gửi email đến các bên tham gia buổi họp & cần cc đến ban dự án hai bên. Trong email, bạn cần nhấn mạnh về tầm quan trọng của việc kiểm tra & phản hồi nội dung khảo sát của các thành viên tham gia, đây là dữ liệu quan trọng, là cơ sở để thực hiện các bước tiếp theo trong quá trình triển khai dự án. Và đặc biệt đừng quên đặt thời hạn cho bất kỳ công việc nào từ phía business.


3. Sơ đồ hóa hóa quy trình

Khi business xác nhận hoặc đưa ra feedback về nội dung trong biên bản khảo sát, bạn cần thực hiện bước sơ đồ hóa quy trình vận hành. Bạn có thể áp dụng các framework như BPMN, Flowchart,... để thực hiện việc này. Tuy nhiên, bạn cần lưu ý rằng kết quả vẫn là quan trọng nhất, hãy lựa chọn framework phù hợp. Ngoài ra, bạn có thể thực hiện bước sơ đồ hóa này ở thời điểm hoàn thành buổi họp & trước khi business xác nhận thông tin để tiết kiệm thời gian.

Ngoài việc sơ đồ hóa, bạn cần thực hiện báo cáo khảo sát gồm danh sách quy trình, các mong muốn ở từng quy trình & mô tả cụ thể ở từng bước. Việc này giúp cho các thành viên của toàn bộ dự án có thể hình dung được quy trình nghiệp vụ hiện tại của doanh nghiệp mà không cần tham gia trực tiếp vào các buổi khảo sát. 

4. Phân tích khoảng trống

Trong các dự án triển khai phần mềm trên nền tảng có sẵn, đội ngũ triển khai cần tham chiếu giữa các yêu cầu, mong muốn & quy trình của doanh nghiệp với hệ thống có sẵn. Từ đó, tài liệu phân tích khoản trống - GAP Analysis Document ra đời. Trong tài liệu cần đầy đủ các thông tin gồm mã GAP, mã tham chiếu bước thực hiện ở quy trình, nội dung yêu cầu được viết dưới dạng User Story, khả năng đáp ứng của hệ thống (fit / gap) & giải pháp. 

Tùy vào mức độ chi tiết của yêu cầu, một yêu cầu có thể có một hoặc nhiều GAP, một GAP có thể có một hoặc nhiều giải pháp. Trường hợp có trên 2 giải pháp ở cùng một GAP, bạn cần cụ thể về ưu điểm & nhược điểm của mỗi giải pháp xoay quanh các tiêu chí về chi phí, thời gian thực hiện & độ đáp ứng của hệ thống. Trong trường hợp có hơn hai giải pháp, stakeholder sẽ gặp khó khăn ở việc lựa chọn, do đó không nên có nhiều hơn hai giải pháp ở một GAP.

Sau khi hoàn thành tài liệu GAP, cần tổ chức cuộc họp review nội bộ để chắc chắn rằng các giải pháp mà bạn đã đưa ra đảm bảo tiêu chí đúng, đủ & hợp lý. Đúng về giải pháp, đủ về yêu cầu & hợp lý về mặt chi phí triển khai. Cuộc họp nội bộ này cần có sự tham gia đầy đủ đội triển khai dự án, đặt biệt cần technical lead để verify về mặt giải pháp. Trường hợp một số giải pháp cần lập trình hoặc vượt ngoài phạm vị của dự án, bạn cần có thông tin đến sale để cụ thể về phương án giá cho từng giải pháp.

Cuối cùng bạn cần gửi tài liệu này đến business & tổ chức cuộc họp để demo về giải pháp cụ thể, từ đó họ có thể hình dung sơ bộ về mặt giải pháp mà đội ngũ đề xuất. Bạn cần chuẩn bị về mặt hệ thống, chuẩn bị dữ liệu & phân quyền cụ thể trên hệ thống demo.

5. Demo giải pháp và hệ thống

5.1 Setup hệ thống demo

Sau buổi review giải pháp nội bộ, bạn cần setup hệ thống demo để phục vụ demo giải pháp và hệ thống. Checklist setup gồm:

  • Chuẩn bị một database mới hoàn toàn
  • Thực hiện cài đặt module và addon
  • Cấu hình bật / tắt tính năng ở từng phân hệ
  • Chuẩn bị sample master data và import lên hệ thống
  • Tạo transaction data và các report
  • Cấu hình các biểu mẫu / mẫu in theo yêu cầu thực tế
  • Cấu hình dashboard
  • Tạo các bộ favorite template và export template
  • Tạo và phân quyền người dùng

Tiếp theo, bạn cần mô phỏng buổi demo trên hệ thống demo vừa setup để phát hiện các lỗi hệ thống hoặc các issue mà bạn có thể không lường trước. Đồng thời, đây là bước để bạn có thể tập luyện tốt việc trình bày trước khi tiến hành demo.

5.2 Thực hiện demo giải pháp

Trong khi demo, bạn cần trình bày về quy trình và các use case để stakeholder nắm về ngữ cảnh. Bạn cần thực hiện demo trên hệ thống tối đa nhất có thể, trường hợp một số giải pháp cần thực hiện lập trình, nếu không thể sử dụng studio để prototype, bạn có thể trình bày giải pháp bằng Wire Frame. Lưu ý rằng, stakeholder sẽ luôn đặt câu hỏi, trường hợp bạn không thể trả lời, hãy note lại thông tin và phản hồi ở thời điểm sau đó. Nếu stakeholder có biểu hiện không tập trung hoặc không có bất kỳ câu hỏi nào, đó chính là vấn đề. Bạn cần có động thái để mọi người tập trung vào buổi demo. 



Định nghĩa và ứng dụng CRM
CRM – Định nghĩa Học thuật và Ứng dụng trong Kinh doanh, Giáo dục, Y tế và Phi Lợi Nhuận