Giới thiệu 

Với tư cách là nhà lãnh đạo dự án, công việc của chúng tôi thật tuyệt vời: chúng tôi có cơ hội cải thiện công việc của mọi người bằng cách tự động hóa các nhiệm vụ nhàm chán và giúp các công ty nâng cao năng suất. Hiếm có giải pháp nào có tác động tương tự đối với những người sử dụng.

Nhưng việc triển khai một phần mềm quản lý cũng khó khi nó có nhiều tác động. Odoo kết nối tất cả các phòng ban, nghĩa là nó tạo ra rất nhiều thay đổi và rất nhiều người dùng dựa vào bạn để cải thiện luồng công việc của họ.

Rất khó để bạn trở thành một Nhà lãnh đạo dự án tuyệt vời. Hơn 50% việc triển khai hoạch định nguồn lực doanh nghiệp (ERP) độc quyền không thành công và chỉ 18% doanh nghiệp vừa và nhỏ triển khai phần mềm quản lý tích hợp vì nó quá phức tạp và đắt đỏ đối với họ. Nhưng những thất bại liên tục trong việc cung cấp thực sự là cơ hội để chúng ta mau trưởng thành.

Bằng cách giúp các dự án triển khai diễn ra suôn sẻ, có thể dự đoán và giá cả phải chăng, Odoo đang chuyển đổi thị trường và đáp ứng một nhu cầu rất lớn. Trong 5 năm qua, hơn 95% việc triển khai của chúng tôi đã thành công, trái ngược hẳn với các nhà cung cấp giải pháp khác.

Để đạt được điều đó, chúng tôi đã có một góc nhìn quan trọng về cách tiếp cận của mình và vai trò của 80 Nhà lãnh đạo dự án của chúng tôi. Chúng tôi đã tinh chỉnh phương pháp của mình, phân tích cách những lãnh đạo hàng đầu hành xử và nhận ra điều gì khiến một số dự án thành công hơn những dự án khác. Hướng dẫn này tóm tắt các thực hành tốt nhất của chúng tôi và tất cả những mẹo hay mà chúng tôi đã học được.

1. Các khái niệm chính 

 Trách nhiệm

• Với tư cách là Nhà lãnh đạo dự án, ưu tiên hàng đầu của chúng tôi là đảm bảo dự án luôn đúng tiến độ và ngân sách.

•  Khách hàng xác định nhu cầu kinh doanh của họ (tại sao và cái gì) và cách thức đáp ứng những nhu cầu này được xác định bằng sản phẩm thông qua chúng tôi (như thế nào).

• Odoo xem xét nhu cầu của khách hàng để đảm bảo lợi ích xứng đáng với chi phí bỏ ra.

Giữ mọi việc đơn giản

• Ít cuộc họp hơn, ít thủ tục giấy tờ hơn, quyết định nhanh hơn.

• Hạn chế số lượng các bên liên quan để đẩy nhanh chu kỳ ra quyết định.

• Hạn chế phát triển tùy chỉnh ở mức cần thiết tối thiểu.

• Làm việc tại văn phòng không hiệu quả đối với trách nhiệm hoàn thành mọi việc, nhưng hiệu quả cho việc quản lý thay đổi và đào tạo. Chỉ làm việc ngoài văn phòng khi cần thiết.

Con người

• Nhà lãnh đạo dự án phải là người giải quyết vấn đề, đồng thời là chuyên gia về sản phẩm và kinh doanh.

• Tránh những người trung gian không phải là người ra quyết định.

• Đào tạo những người dùng chính ngay từ giai đoạn đầu của dự án. Họ nên tin tưởng vào sản phẩm và cam kết với dự án.

Các nhà quản lý dự án

• Yếu tố thành công quan trọng của bất kỳ hoạt động triển khai nào là Nhà quản lý dự án (hay còn gọi là Người lãnh đạo dự án tại Odoo).

• Tuyển dụng và đào tạo nhân tài tốt nhất. Chỉ giữ lại những người có năng suất cao nhất.

• Ngay cả những Nhà lãnh đạo dự án giỏi nhất cũng bỏ lỡ những chi tiết quan trọng. Để hạn chế rủi ro, các Chuyên gia của Odoo nên xem xét công việc của họ ở các bước quan trọng trong dự án.

2. Thế nào là một dự án thành công?

Với tư cách là Người lãnh đạo dự án, sẽ rất khó để bạn cân bằng giữa việc làm hài lòng khách hàng, chấp nhận nhiều yêu cầu thay đổi hơn, giữ ngân sách ở mức thấp, tuân thủ nghiêm ngặt các thỏa thuận, dành ít hoặc nhiều thời gian cho việc phân tích, căn chỉnh sao cho phù hợp với lịch trình dự án, v.v…

Ưu tiên quan trọng cho một dự án thành công là hướng tới người dùng trong Odoo đồng thời thực hiện việc này đúng thời gian và trong phạm vi ngân sách. Khi một dự án thất bại, luôn là vì nó mất quá nhiều thời gian hoặc tốn quá nhiều chi phí.

Thời gian và ngân sách là những yếu tố quan trọng để cấu trúc phương pháp của bạn. Phần còn lại là thứ yếu:

• Việc phát triển các tính năng tùy chỉnh không phải là ưu tiên.

• Sự hài lòng của khách hàng trong quá trình thực hiện không phải là ưu tiên.

• Việc bán thêm dịch vụ sớm không quan trọng.

Việc phát triển các tính năng cụ thể không giúp ích gì cho dự án

Việc phát triển theo yêu cầu luôn tăng thêm chi phí và kéo dài thời gian triển khai dự án, đôi khi đến mức đưa dự án vào rủi ro. Ngoài ra, việc phát triển tùy chỉnh dẫn đến nợ kỹ thuật mà khách hàng sẽ phải trả trong những năm tới dưới dạng chi phí bảo trì và nâng cấp bổ sung.

Mỗi tùy chỉnh trông có vẻ đơn giản và giá cả phải chăng. Nhưng mức độ phức tạp của một dự án tăng lên theo cấp số nhân khi số lượng tùy chỉnh tăng lên, chứ không theo tuyến tính.

Một dự án thành công nếu nó được bàn giao đúng thời gian và trong giới hạn ngân sách. Việc phát triển các tính năng tùy chỉnh cho những nhu cầu cụ thể của khách hàng không khiến dự án thành công, nhưng đôi khi cần thiết để hỗ trợ hoạt động kinh doanh cốt lõi của khách hàng.

Sự hài lòng của khách hàng không phải một KPI hữu ích

Sự hài lòng của khách hàng không phải thước đo tốt cho thành công của một dự án. Đầu tiên, nó biến đổi liên tục trong suốt các giai đoạn khác nhau của một dự án. Thứ hai, mỗi người có thể có những kỳ vọng khác nhau, ví dụ: một người dùng chính muốn các tính năng bổ sung, nhưng giám đốc điều hành muốn dự án hoàn thành đúng thời hạn và ngân sách.

Việc tập trung vào sự hài lòng của khách hàng khiến Người lãnh đạo dự án mất tập trung khỏi các mục tiêu chính của dự án. Chúng tôi chắc chắn muốn khách hàng của mình tạm thời không hài lòng (vì họ đã tranh luận gay gắt về một quyết định phức tạp) hơn là bỏ lỡ thời hạn thực hiện. Sự không hài lòng là điều cố hữu trong bất kỳ dự án nào.

Mặc dù sự hài lòng của khách hàng không phải mục tiêu trong quá trình triển khai, đây vẫn là một cách hữu ích để đánh giá động lực của những người dùng chính.

Do đó, chúng tôi xếp hạng khách hàng định kỳ để biết khách hàng nào cần được quan tâm nhiều hơn (chứ không phải để đánh giá phẩm chất của Người lãnh đạo dự án). 

Diễn biến sự hài lòng của khách hàng trong suốt dự án.

Bán các dịch vụ bổ sung trước khi "bàn giao dự án" không phải là ưu tiên

Các công ty dịch vụ muốn lập hóa đơn cho khách hàng càng nhiều càng tốt. Rốt cuộc, đó là hoạt động kinh doanh cốt lõi của họ! Các công ty dịch vụ lớn thậm chí có những phương pháp phức tạp dẫn đến việc cần nhiều dịch vụ hơn, như các giai đoạn phân tích với danh nghĩa hạn chế rủi ro trong một dự án.

Chúng tôi tin rằng việc bán nhiều hơn không bao giờ nên là mục tiêu ban đầu. Sự phát triển của công ty phải là kết quả của một dịch vụ chất lượng hoặc của những khách hàng hài lòng (lý tưởng là cả hai). Chúng tôi thực sự nghĩ rằng tốt hơn nên triển khai khách hàng trong ít ngày làm việc hơn. Việc này không chỉ làm giảm nguy cơ thất bại của dự án mà còn giúp cạnh tranh tốt hơn trên thị trường.

Việc có tốc độ tốt trong suốt dự án là lợi thế cạnh tranh rất lớn để thu được khách hàng mới. Và khi bạn xây dựng cơ sở khách hàng của mình, việc bán các dịch vụ bổ sung cho khách hàng hiện tại trở nên rất dễ dàng:

Việc bán thêm cho người dùng hiện tại dễ hơn gấp 7 lần so với bán cho khách hàng mới.

Bạn luôn có thể chia dự án thành các giai đoạn và bán những tính năng không bắt buộc sau khi “bàn giao dự án”. Bằng cách này, bạn sẽ không bao giờ cần phải thắt chặt biên lợi nhuận của mình vì ngân sách đã tiêu tốn.

Tóm lại, để đạt được tăng trưởng bền vững, hãy tập trung vào thành công của dự án. Nếu bạn có những dự án thành công, sau này khách hàng sẽ mua nhiều dịch vụ hơn. Mỗi khi bán thêm trước khi "bàn giao dự án", bạn làm suy yếu lòng tin của khách hàng; họ có thể suy nghĩ rất kỹ trước khi mua các dịch vụ bổ sung trong tương lai.

​

Cách đây vài năm, tôi đã phỏng vấn 15 khách hàng để thu thập phản hồi về phương pháp triển khai và dịch vụ của chúng tôi. Một khách hàng đã nói với tôi: “Trong 3 tháng đầu tiên, tôi không thích làm việc với Frédéric [Nhà quản lý dự án]. Anh ấy liên tục chất vấn mọi thứ tôi yêu cầu, đến mức tôi có cảm giác mình đang lãng phí thời gian. Điều đó khiến tôi có chút bực bội.

Nhưng sau này, tôi hiểu rằng đó là vì lợi ích của dự án. Anh ấy thường tìm ra những giải pháp tốt hơn những gì tôi yêu cầu trong quá trình triển khai. Bây giờ, mặc dù chúng tôi đang trong quá trình sản xuất, nhưng mỗi khi tôi có quyết định kinh doanh về một quy trình nào đó, tôi đều gọi để xin lời khuyên của anh ấy.”

Câu chuyện này minh họa một cách hoàn hảo cách tiếp cận của chúng tôi: bằng cách ưu tiên sự thành công của dự án hơn là sự hài lòng của khách hàng trong ngắn hạn, chúng tôi thực sự khiến khách hàng hài lòng về lâu dài. Frédéric có thể đã đồng ý phát triển mọi tính năng tùy chỉnh mà khách hàng yêu cầu để khiến họ hài lòng ngay từ đầu, nhưng dự án sẽ tốn nhiều chi phí hơn, bị trì hoãn và chúng tôi có nguy cơ mất khách hàng.

3. Vai trò

Các nhà cung cấp ERP truyền thống xác định các vai trò khác nhau trong việc phân tích hoạt động kinh doanh: Nhà quản lý dự án, Nhà phân tích kinh doanh cấp thấp, Nhà phân tích kinh doanh cấp cao, Nhân viên kiểm tra, Người đào tạo, v.v… Nhưng lắm thầy thối ma!

Việc đưa ra quyết định đúng luôn liên quan đến sự cân đối giữa những nhu cầu kinh doanh cụ thể và các tính năng hiện có của sản phẩm. Nếu phân chia vai trò của nhà phân tích kinh doanh và chuyên gia sản phẩm, bạn có thể đưa ra những quyết định không hiệu quả.

Odoo là sản phẩm dễ sử dụng hơn nhiều so với các hệ thống ERP truyền thống. Odoo cho phép một người hiểu cả doanh nghiệp và sản phẩm – điều mà các đối thủ cạnh tranh không thể làm được.

Odoo: Người lãnh đạo dự án

Người lãnh đạo dự án là người ra quyết định chính của dự án. Tuy nhiên, những Người lãnh đạo dự án có nhiều vai trò – họ cùng lúc phải đóng vai trò nhà quản lý dự án, nhà phân tích kinh doanh và chuyên gia sản phẩm.

Với tư cách nhà quản lý dự án, chúng tôi dẫn dắt dự án bằng cách:

• Xác định kế hoạch dự án và tuân theo nó

• Tập trung vào các mục tiêu chính

• Giới thiệu SPoC (Điểm liên lạc duy nhất) vào dự án

• Sử dụng đúng nguồn lực và lường trước rủi ro

Với tư cách là nhà phân tích kinh doanh và chuyên gia sản phẩm, chúng tôi giữ mọi thứ đơn giản bằng cách:

• Quyết định cách thực hiện các nhu cầu cụ thể

• Thách thức các nhu cầu của khách hàng và quản lý những kỳ vọng của họ

• Thiết lập cấu hình Odoo

• Chuyển dữ liệu cần thiết

• Viết các đặc điểm kỹ thuật (nếu có yêu cầu phát triển)

Người lãnh đạo dự án Odoo phải được khách hàng coi là đầu mối liên lạc chính trong quá trình thực hiện của họ.

Odoo: Giám đốc dự án

Trong các dự án lớn hơn hoặc có môi trường chính trị cao, Giám đốc dự án được chỉ định ngoài Người lãnh đạo dự án. Trong khi Người lãnh đạo dự án tập trung vào việc triển khai, Giám đốc dự án giúp trình bày dự án và quản lý các kỳ vọng của lãnh đạo, với góc nhìn cao hơn về dự án.

Vai trò của họ là giữ cho những người ra quyết định nắm được thông tin và cam kết với dự án bằng cách:

• Báo cáo tiến độ dự án cho ban chỉ đạo

• Theo dõi hiệu quả của dự án

• Đưa ra các giải pháp để khắc phục sự kém hiệu quả về cách xử lý dự án (ở cả hai phía)

Trái ngược với Người lãnh đạo dự án, Giám đốc dự án không làm việc toàn thời gian cho một dự án nhưng theo từ đầu đến cuối. Trong các dự án nhỏ hơn, vai trò này thường do Người lãnh đạo dự án trực tiếp thực hiện.

Đối với một công ty giao dịch công chúng lớn, chúng tôi có sứ mệnh triển khai ERP toàn diện cho hơn 3.000 người dùng trong sự hợp nhất phức tạp giữa hai công ty.

Chúng tôi bắt đầu bằng cách làm theo cách quản lý dự án của họ. Là một công ty dịch vụ giàu kinh nghiệm, họ muốn dạy chúng tôi cách làm mọi việc. Nhưng sau vài tháng, dự án bắt đầu trượt dốc.

Tôi đã đề xuất một cách tiếp cận mới cho ban chỉ đạo, chặt chẽ hơn với phương pháp của chúng tôi. Chúng tôi đã thay đổi cơ chế để thực hiện theo cách của Odoo:

• Làm việc bằng SPoC và cung cấp bản demo hằng tuần (chỉ một người quyết định, không cần thêm ủy ban).

• Thách thức mọi yêu cầu để xem liệu nó có thể bị loại bỏ hoặc được thực hiện theo cách khác (càng bám sát môi trường tiêu chuẩn càng tốt).

• Nói Không! với các yêu cầu tiêu tốn thời gian không hợp lý.

• Bỏ qua hầu hết các thành viên trong nhóm dự án để đưa những người ra quyết định tham gia trực tiếp (tránh lãng phí thời gian trong các chu kỳ xác nhận).

​

Ban đầu, khách hàng rất thất vọng (dù sao thì chúng tôi, một đội trẻ, đã thử thách cách quản lý dự án của một công ty lớn và giàu kinh nghiệm), nhưng khi dự án tiến triển, các lãnh đạo rất vui và chúng tôi đã hoàn thành đúng thời hạn!

Odoo: Chuyên gia ứng dụng

Đối với các ứng dụng chính (quản lý, kiểm kê, tiếp thị, sản xuất, trang web), người am hiểu nhất về ứng dụng sẽ đóng vai trò là Chuyên gia ứng dụng Odoo. Họ đã phát triển kiến thức chức năng sâu sắc về các tính năng Odoo cụ thể của ngành và đã có được kinh nghiệm kinh doanh vững chắc.

Odoo: Nhà phát triển

Không phải tất cả dự án đều yêu cầu nhà phát triển. Hầu hết các công ty nhỏ (<50 người dùng) đều sử dụng Odoo và không yêu cầu phát triển tùy chỉnh. Họ sẽ tham gia nếu và chỉ khi doanh nghiệp yêu cầu phát triển.

Khách hàng: Điểm liên lạc duy nhất (SPoC)

Để thực hiện nhanh chóng, đơn giản và hợp lý nhất có thể, chúng tôi cũng cần có một đồng minh mạnh mẽ ở phía khách hàng. Để làm như vậy, Nhà quản lý dự án Odoo sẽ cần một hồ sơ tương đương trước mặt họ.

Với tư cách là nhà quản lý dự án, SPoC làm việc chặt chẽ với Nhà quản lý dự án Odoo bằng cách:

• Theo dõi dự án

• Trở thành đại sứ thuyết phục người dùng cuối (Quản lý thay đổi)

• Đảm bảo kế hoạch dự án phù hợp với chương trình làm việc và các ràng buộc của công ty

Hoạt động với tư cách là “siêu người dùng chính”, SPoC có hiểu biết toàn diện về các yêu cầu của dự án bằng cách:

• Thu thập và đánh giá các yêu cầu của dự án

• Đào tạo người dùng cuối với sự hỗ trợ của Nhà quản lý dự án (một đồng nghiệp nắm rõ các quy trình nội bộ của công ty bạn là người đào tạo tốt nhất)

• Trở thành chuyên gia nội bộ của Odoo và đảm bảo mức độ hỗ trợ đầu tiên cho đồng nghiệp của họ

Khi chia sẻ trách nhiệm về sự thành công của dự án với Người lãnh đạo dự án, chúng tôi mong muốn SPoC sẽ tham gia vào từng bước của dự án. Do đó, chúng ta cần SPoC để: 

• Sẵn sàng cho dự án

• Có quyền ra quyết định
  

Khách hàng: Vai trò phụ

Trong các dự án lớn, các vai trò phụ có thể được xác định như sau:

• Ban chỉ đạo: một ủy ban (bao gồm những người ra quyết định của khách hàng và Giám đốc dự án của Odoo) quyết định về các ưu tiên, phương pháp của dự án và theo dõi sự thành công của dự án

• Người dùng chính: ngoài SPoC, người dùng chính đóng vai trò là chuyên gia trong miền cụ thể của họ và sẽ giúp SPoC xác định các yêu cầu. Họ cũng kiểm tra và đánh giá các sản phẩm phân phối

• Nhà tài trợ: thường là Giám đốc điều hành hoặc Giám đốc tài chính, người trả tiền cho dự án và người có mục tiêu cấp cao. Họ cũng thường là một phần của Ban chỉ đạo
  

​

Hai năm trước, tôi đã bắt đầu hai dự án với hai công ty sản xuất có nguồn cung ứng giống nhau và cùng một chủ. Khi bắt đầu dự án, chúng tôi có hai SPoC: người thứ nhất là giám đốc vận hành của một trong hai công ty, và người thứ hai là CEO của tập đoàn.

Việc triển khai đầu tiên diễn ra rất thuật lợi. Trong vài tháng, chúng tôi đã đi vào sản xuất toàn bộ quy mô. Đó là nhờ sự hợp tác tốt với SPoC. Ngược lại, việc triển khai thứ hai rất khó quản lý do không có sẵn CEO (hoạt động như SPoC).

Chúng tôi đã quyết định thay đổi SPoC, nhưng CEO không tin tưởng người mới này. Mọi quyết định đều phải được CEO xác nhận, điều đó khiến quá trình này kéo dài thêm nhiều ngày. Các cuộc thảo luận với SPoC mới rất tốt, nhưng anh ta không có thẩm quyền. Dự án dã trở thành một cơn ác mộng và phải mất nhiều tháng để triển khai giai đoạn đầu tiên.

Sau khi bắt đầu sản xuất lần đầu tiên, chúng tôi quyết định thay đổi SPoC một lần nữa. Người chịu trách nhiệm triển khai ở công ty thứ nhất nhận trách nhiệm thực hiện ở công ty thứ hai cho các giai đoạn tiếp theo. CEO tin tưởng vào các quyết định mà anh ta sẽ đưa ra và không cần xác nhận. Mọi thứ bắt đầu tiến triển nhanh hơn nhiều. Chỉ bằng cách cải thiện quy trình ra quyết định, chúng tôi đã tăng hiệu quả.

4. Các giai đoạn triển khai

Các giai đoạn triển khai một dự án và thời lượng tương đối của chúng là:

Phân tích ROI

Đối với các dự án lớn, phân tích ROI được bán trước khi khách hàng cam kết về toàn bộ dự án và ngân sách. Theo quy mô của dự án, có thể mất từ 3-50 ngày. Đối với các dự án rất nhỏ (<4 tháng), phân tích ROI không phải là một giai đoạn riêng biệt, mà được thực hiện trong giai đoạn Khởi động.

Phân tích ROI cho phép khách hàng:

• Có được một kế hoạch và ngân sách chính xác

• Đánh giá lợi tức đầu tư (ROI): các lợi ích cho chi phí

• Xem xét các thông số kỹ thuật của họ theo phần mềm

• Xóa bỏ nghi ngờ của họ về tính khả thi của dự án

• Đánh giá Người lãnh đạo dự án

Nhà lãnh đạo dự án cung cấp:

• Phân tích các khoản tiết kiệm và lợi ích cho khách hàng (Lợi nhuận)

• Ngân sách và kế hoạch triển khai (Đầu tư)

• Sự kết nối giữa nhu cầu kinh doanh và tính năng sản phẩm

• Một bằng chứng về tính khả thi (POC): các bản mẫu về hoạt động kinh doanh chính

• Một chiến lược để quản lý sự thay đổi

Các giai đoạn của Phân tích ROI:

- Gặp gỡ các bên liên quan, xác định các mục tiêu, động cơ và rủi ro trong sơ đồ tư duy Khởi động ROI (Phụ lục A).

- Gặp gỡ những người dùng chính trong mỗi bộ phận bằng cách sử dụng sơ đồ tư duy ROI phỏng vấn người dùng chính (Phụ lục B):

• Hiểu tình hình hiện tại

• Nhận ra chỗ lãng phí thời gian và điểm đau (các tiết kiệm tiềm năng)

• Xác định những gì nên làm

- Ghi lại phân tích ROI và việc phân chia giai đoạn.

- Đánh giá ngang hàng bởi các Chuyên gia và nhà phát triển của Odoo để kiểm định các giải pháp được đề xuất

- Trình bày kết quả cho khách hàng bằng cách sử dụng bài thuyết trình Kết thúc ROI (Phụ lục D) và làm demo sản phẩm.

Mẹo phân tích

Trong các cuộc phỏng vấn:

• Hãy là một nhân viên kinh doanh, vì dự án chưa được bán! Ở giai đoạn này, mục tiêu của bạn là trấn an mọi người và thúc đẩy họ: làm các bản demo về các tính năng chính.

• Sau khi trấn an những người dùng chính về dự án, hãy đánh giá cách mọi người dành thời gian của họ (X% cho cái này, Y% cho cái kia); một yếu tố chính để đánh giá lợi nhuận tiềm năng.

• Việc quan sát cách họ hiện đang làm việc luôn cần thiết: yêu cầu các bản demo của phần mềm hiện tại của họ và lấy một bản sao của mỗi tài liệu mà họ sử dụng. Tình hình hiện tại quan trọng hơn mục tiêu tương lai của họ, vì nó xác định phạm vi bao quát tối thiểu. Nếu bạn hoàn toàn hiểu cách họ làm việc ngày hôm nay, bạn sẽ có thể kiểm định các yêu cầu của họ tốt hơn và phát hiện ra những điểm kém hiệu quả của họ.

• Xác định điểm đau của người dùng chính. Sử dụng mẫu Phân tích ROI để lấy ý tưởng về các điểm đau chung cho mỗi bộ phận.

• Tìm giải pháp cho từng vấn đề, cố gắng càng bám sát các giải pháp tiêu chuẩn càng tốt. Bạn không bắt buộc phải làm mọi thứ mà người dùng chính yêu cầu, yêu cầu của họ phải được thử thách.

• Không bao giờ trình bày các lựa chọn khác nhau cho khách hàng: với tư cách là Người lãnh đạo dự án, bạn phải đề xuất lựa chọn tốt nhất và tự mình đưa ra quyết định. Vai trò của khách hàng là thử thách những gì bạn cung cấp chứ không phải quyết định phải làm gì.

• Tránh để khách hàng quyết định xem một tính năng là “cần thiết” hay “tùy chọn” hoặc mọi thứ sẽ là bắt buộc. Đưa ra quyết định cho họ bằng cách phân loại các mục là “tùy chọn”, khi bạn nghĩ rằng chúng nên được loại trừ khỏi phạm vi phân loại. Vai trò của khách hàng là thử thách đề xuất của bạn.

Sau khi phỏng vấn:

- Đánh giá ngang hàng được tổ chức với Chuyên gia của Odoo, người không thuộc dự án. Họ không bị khách hàng ảnh hưởng và có thể dễ dàng đưa ra những quyết định khắt khe và đưa ra những lời chỉ trích.

- Mục tiêu của đánh giá ngang hàng là

• Đánh giá xem việc phát triển tùy chỉnh có thực sự cần thiết không và nếu có thì ưu tiên việc đó nhằm giảm ngân sách cũng như thời gian lập kế hoạch và

• Kiểm tra xem bạn có bỏ sót những điểm chính yếu theo ngành hay không.

- Tất cả sự phát triển cần thiết nên được chia thành hai loại:

• Phát triển hoàn toàn cần thiết trước khi đi vào sản xuất (tức là bạn không thể vận hành doanh nghiệp mà không có nó).

• Phát triển có thể được thực hiện trong giai đoạn triển khai thứ hai, sau khi dự án đi vào hoạt động (tức là bạn có thể vận hành công việc kinh doanh mà không cần nó, nhưng nó không phải là tối ưu).

Khi kết thúc nhiệm vụ:

• Tóm tắt phân tích của bạn (phạm vi chức năng và kinh doanh, nguồn lực cần thiết cho cả hai bên, lập kế hoạch và rủi ro).

•  Tổ chức các bản demo cụ thể để trấn an các bên liên quan và chỉ ra những lợi ích mà họ sẽ nhận được khi sử dụng Odoo.
  

Khởi động dự án

Chúng tôi cần mọi người cùng tham gia. Đó là nội dung của Khởi động dự án. Tạo lượt mua trong công ty của khách hàng, quản lý kỳ vọng, khiến họ đồng ý với cách tiếp cận của chúng tôi và trên hết là xây dựng một kế hoạch vững chắc!

Bạn nên biết bước này quan trọng như thế nào. Thành công của toàn bộ dự án phụ thuộc vào cách bạn sẽ thực hiện nó. Đó là lý do tại sao bạn sẽ dành ít nhất 10% dự án vào việc này.

Mục tiêu của việc khởi động là để:

• Tích hợp SPoC về phương pháp và điều chỉnh tầm nhìn

• Thực hiện phân tích ROI nhanh chóng nhằm đánh giá tính khả thi của dự án (nếu chưa được thực hiện)

• Hoàn thiện kế hoạch dự án

• Đào tạo SPoC và đảm bảo họ đầu tư thời gian vào việc học Odoo

• Đào tạo nhóm dự án của khách hàng trong chiến lược thay đổi

​

Tôi từng được giao một dự án có tên “Electronics123”. Nhân viên bán hàng có những dòng thông điệp như sau: “Khách hàng này HOÀN TOÀN CẦN Quản lý kho hàng, Sản xuất, Mua hàng, Quản lý Bán hàng và Trang web/Thương mại điện tử của anh ấy triển khai nhanh và chạy trong 2 tuần. Hợp đồng Netsuite của anh ấy sẽ kết thúc sau đó mà không có hệ thống.”

Tôi chỉ có 12 ngày theo lịch để chuyển hệ thống ERP đầy đủ của anh ấy vào sản xuất.

Đây là những gì tôi đã nói với giám đốc điều hành Johan trong cuộc họp khởi động dự án: “Đầu tiên, dự án là bất khả thi. Chúng tôi sẽ thất bại. Chúng tôi thường cần 2 tuần cho mỗi ứng dụng. Nhưng nếu chỉ có một cơ hội nhỏ để hoàn thành nó, chúng tôi phải làm những điều này: 1) Chúng tôi thực hiện theo đầy đủ tiêu chuẩn, 2) Anh làm những gì tôi nói và không đặt câu hỏi, vì tôi sẽ không có thời gian để giải thích mọi quyết định của mình.” Anh ấy đã đồng ý.

Chúng tôi đã cùng nhau làm việc cả ngày lẫn đêm trong 9 ngày tiếp theo. Anh ấy giải thích các quy trình kinh doanh của mình và tôi tự đưa ra tất cả quyết định trong khi kiểm tra lại hệ thống. Công ty bắt đầu đi vào sản xuất 9 ngày sau đó trong đêm, trên tất cả các ứng dụng. Đó là một trong những dự án và khách hàng tuyệt nhất mà tôi từng có.

Tôi không thể nhấn mạnh đủ tầm quan trọng của cuộc họp khởi động dự án. Dự án “bất khả thi” này đã được thực hiện chỉ nhờ những kỳ vọng được đặt ra ngay trong thời gian khởi động. Bạn cũng nên nhớ rằng các nhà quản lý dự án không nên ngại đưa ra quyết định thay mặt khách hàng, điều này sẽ khiến quá trình này trở nên dễ dàng hơn nhiều. Vai trò của khách hàng không phải là quyết định phải làm gì, mà là chấp thuận những gì bạn đề xuất.

Mẹo khởi động dự án

• Trực tiếp giải quyết các vấn đề: nếu bạn cho rằng kế hoạch quá ngắn, hãy thương lượng về việc trì hoãn và yêu cầu lùi thời hạn càng sớm càng tốt. Tương tự, nếu bạn phát hiện ra sự hiểu lầm về tính khả thi, tư duy hoặc tính năng, hãy thảo luận về những điều này càng sớm càng tốt, thay vì trì hoãn cuộc trao đổi. Các nhà quản lý dự án thiếu kinh nghiệm có xu hướng tránh các cuộc thảo luận phức tạp, đây là một sai lầm phổ biến.

• Kiểm tra sự tham gia của khách hàng: đảm bảo đúng người có liên quan về phía khách hàng. Đảm bảo họ có đủ thời gian và kiến thức để hoàn thành nhiệm vụ của mình.

• Đầu tư thời gian vào việc đào tạo SPoC: giới thiệu nền tảng eLearning, tài liệu trực tuyến đến họ và đào tạo họ về các nghiệp vụ chính. Họ sẽ không thể thực hiện nhiệm vụ của mình nếu bản thân họ không trở thành chuyên gia về sản phẩm.

• Quản lý kỳ vọng của khách hàng: đây là kỹ năng then chốt của bất kỳ Người lãnh đạo dự án nào. Đừng đặt thời hạn quá ngắn, đừng hứa hẹn những tính năng phức tạp, đừng nói rằng sẽ đễ để thay đổi, đừng nói đồng ý với mọi thứ. Tóm lại, nếu hứa ít, bạn có thể làm nhiều.
  

​

Tôi có 2 câu chuyện minh họa tầm quan trọng của việc tuân theo các quy tắc này.

Trường hợp 1: Triển khai thất bại

Khách hàng của tôi biết chính xác những gì anh ấy muốn. Thay vì thử thách họ ngay từ đầu, tôi chấp nhận mọi thứ vì anh ấy có đủ khả năng. Đây là sai lầm lớn.

Ngày nay, chi phí bảo trì đã bắt đầu tạo gánh nặng cho khách hàng. Anh ấy tiếp tục yêu cầu phát triển thêm. Rồi không hiểu tại sao tôi bắt đầu từ chối và giờ thì anh ấy không cởi mở với các giải pháp thay thế (tiêu chuẩn) nữa.

Kết quả là dự án đã bị trì hoãn trong vài tháng và tôi phải thừa nhận rằng khách hàng không hề hài lòng.

Trường hợp 2: Triển khai  thành công

Tôi đã bắt đầu dự án theo cách khác bằng việc đặt ra những kỳ vọng phù hợp. Tôi đã giải thích với khách hàng rằng tôi sẽ nói không với bất kỳ yêu cầu phát triển nào trừ khi nhu cầu “phải có” là chính đáng và không có giải pháp thay thế phù hợp.

Việc làm điều này đã thay đổi mọi thứ. Khách hàng thực sự cởi mở với các đề xuất của tôi và chúng tôi đã tiết kiệm được 100 giờ phát triển bằng cách sử dụng các giải pháp thay thế tiêu chuẩn.

Thực hiện

Bất kể mức độ phức tạp như thế nào, dự án phải liên tục tiến lên phía trước.

Giữ một tốc độ ổn định là một yếu tố thành công chính. Cách tốt nhất để duy trì mức độ tham gia cao là giữ cho SPoC gắn kết với mọi thứ.

Sau giai đoạn Khởi động, giải pháp được thiết kế đã được chứng minh cho những người dùng chính. Đã đến lúc biến nó thành hiện thực!

Trong mỗi giai đoạn, nhóm dự án làm việc theo chu kỳ ngắn để cung cấp các chức năng hằng tuần. Giải pháp được định hình dần dần trong suốt giai đoạn và được xác nhận bởi Người lãnh đạo dự án và SPoC. Việc thiết lập cấu hình, nhập dữ liệu và phát triển cụ thể được xử lý song song bởi Người lãnh đạo dự án và nhà phát triển, nếu được yêu cầu.

Thiết lập cấu hình

Người lãnh đạo dự án tự thiết lập cấu hình phần mềm, bao gồm tùy chỉnh với ứng dụng Studio, nhưng không có phát triển tùy chỉnh. Sau khi các ứng dụng đã được thiết lập cấu hình, Người lãnh đạo dự án sẽ liên hệ với SPoC và những người dùng chính thông qua một loạt buổi đào tạo để xác nhận thiết lập.

Nhập dữ liệu

Tùy thuộc vào khối lượng và độ phức tạp của dữ liệu để nhập, nhiệm vụ này do Người lãnh đạo dự án hoặc nhà phát triển xử lý. Theo hướng dẫn của Người lãnh đạo dự án, SPoC và những người dùng chính thu thập dữ liệu và chuẩn bị tài liệu để nhập.

Quá trình chuyển dữ liệu từ phần mềm hiện tại sang Odoo có thể gây ra sự chậm trễ và yêu cầu đưa ra quyết định đúng đắn:

• Đừng trì hoãn việc khởi chạy sản xuất do chất lượng dữ liệu: Nhập dữ liệu rõ ràng nhất có thể là tối ưu, nhưng không phải trả giá bằng việc trì hoãn dự án. Vì vậy, nếu khách hàng của bạn không làm rõ dữ liệu đúng thời hạn và đang sử dụng dữ liệu của họ ở trạng thái này, đừng trì hoãn việc khởi chạy sản xuất để làm rõ dữ liệu đó. Một số thao tác làm rõ có thể được thực hiện trực tiếp tại Odoo trong hậu kỳ.

• Nhập dữ liệu chính, nhưng tránh sử dụng toàn bộ lịch sử dữ liệu (nếu có thể): mất nhiều thời gian và tiền bạc với ROI rất thấp về lâu dài. 
  

Phát triển cụ thể

Người lãnh đạo dự án chịu trách nhiệm về sự thành công của dự án. Do đó, họ cũng chịu trách nhiệm quyết định xem việc phát triển tùy chỉnh (có nguy cơ làm trì hoãn dự án) có đáng giá hay không. Không bao giờ là quá muộn để đặt câu hỏi liệu một sự phát triển cụ thể có phải là điều bắt buộc hay không. Hãy nhớ rằng: bạn càng cắt giảm số lượng phát triển thì càng tốt.

Ở giai đoạn này, Người lãnh đạo dự án phê duyệt những gì cần được phát triển; thường là những điều cần thiết để vận hành doanh nghiệp, không phải những thứ chỉ đơn giản là “tốt nếu có” (bạn có thể vận hành doanh nghiệp mà không cần chúng, nhưng điều đó không lý tưởng).

Nhà lãnh đạo dự án viết các thông số kỹ thuật, bao gồm các kịch bản sẽ được kiểm tra và SPoC chứng thực sự phù hợp với các yêu cầu kinh doanh. Sau đó, nhà phát triển tiếp nhận và hoàn thành nhiệm vụ. Họ cũng chịu trách nhiệm về các cuộc kiểm tra tự động.

Nhà lãnh đạo dự án kiểm tra các tính năng mới và đảm bảo chúng tích hợp với các tính năng hoặc ứng dụng khác. Sau khi các phát triển được xác nhận, họ sẽ đào tạo SPoC và những người dùng chính.

SPoC cũng có trách nhiệm kiểm tra và xác nhận các phát triển. Nếu phát hiện các vấn đề, họ sẽ thông báo cho Người lãnh đạo dự án, người đưa ra phản hồi với nhà phát triển để sửa lỗi và thực hiện các thay đổi cần thiết.

Xác nhận & Đào tạo người dùng cuối

Khi tất cả các yêu cầu của một giai đoạn đã được hoàn thành, SPoC sẽ chịu trách nhiệm về tất cả các thử nghiệm cuối cùng và cho phép bàn giao dự án.

Với tư cách là các chuyên gia nội bộ của Odoo, SPoC và/hoặc những người dùng chính tổ chức và đào tạo tất cả những người dùng cuối.

Tương tự, việc viết hướng dẫn sử dụng là trách nhiệm của khách hàng vì hướng dẫn tốt phải phù hợp với các quy trình và thuật ngữ nội bộ của khách hàng. Ngoài ra, việc để khách hàng viết hướng dẫn sử dụng là một cách tốt để đảm bảo họ đã kiểm tra đầy đủ phần mềm theo “thực hành tiêu chuẩn” trước khi đưa vào sản xuất (chúng ta đừng bao giờ nói những điều như thế này. Không có gì là “quá đắt”, mà thay vào đó chi phí không đảm bảo ROI).

Mẹo triển khai

• Yêu cầu SPoC tự thực hiện công việc của họ. Họ sẽ học nhanh hơn. Bạn có thể hướng dẫn họ, nhưng họ phải tự cầm chuột và đánh máy. Việc này thay đổi mọi thứ về hiệu quả đào tạo và sự tham gia của họ. Bạn cũng sẽ nhanh chóng biết được họ không hiểu khái niệm chính nào.

• Biến kế hoạch dự án của bạn thành một loạt chiến thắng nhanh chóng: Để giữ khách hàng của bạn tham gia vào dự án, hãy giao hàng thường xuyên. Nếu người dùng bắt đầu sử dụng hệ thống, ngay cả khi nó ở phạm vi nhỏ, kiến thức của họ về hệ thống sẽ nhanh chóng được cải thiện.

• Tiếp tục thử thách khách hàng của bạn: Không phải vì chúng tôi có một danh sách các yêu cầu mà khách hàng của bạn sẽ ngừng có những ý tưởng mới. Nói chung, bạn không chấp nhận các thay đổi trong một chu kỳ đang diễn ra ngoại trừ trường hợp thời hạn và ngân sách không bị ảnh hưởng. Nếu một thay đổi phải được thực hiện, nó sẽ được hoàn thành trong một chu kỳ sau đó. Nếu việc thay đổi ảnh hưởng đến một yêu cầu cần được hoàn thành trong giai đoạn/chu kỳ sau đó, chỉ chấp nhận nó chỉ khi một yêu cầu khác bị loại bỏ để bù đắp.

• Đừng làm điều gì đó mà bạn không thấy thuyết phục: Lời hứa của nhân viên bán hàng có thể bị bác bỏ. Một hợp đồng ít quan trọng hơn sự thành công của dự án. Bạn luôn có thể thuyết phục một giám đốc điều hành không thực hiện một ý tưởng (ngay cả khi nó nằm trong hợp đồng ban đầu).

• Tiến hành các cuộc gặp mặt trực tiếp. Đó là một cách tốt để giải quyết các tình huống phức tạp: sợ thay đổi, cần được trấn an hoặc thiếu sự tham gia.

• Kiểm soát việc thực hiện thay đổi diễn ra như thế nào: Về mặt quản lý thay đổi, khách hàng của bạn phải thực hiện chiến lược truyền thông của họ và chuẩn bị đào tạo người dùng cuối. Nhiệm vụ của bạn là thường xuyên kiểm tra xem mọi thứ có diễn ra tốt đẹp không và giúp họ thích nghi với thực tế.
  

Hành trình triển khai cơ bản

Bàn giao

Khi đến lúc bàn giao, bạn có thể gặp phải các sự cố không mong muốn. Có thể vấn đề không mong muốn sẽ xuất hiện. Thông thường, điều này do một hoặc cả hai điều sau:

• Cơ sở dữ liệu chưa được kiểm tra đầy đủ: cố gắng đảm bảo những người dùng chính đã kiểm tra đầy đủ nhất có thể tất cả các nghiệp vụ.

• Người sử dụng không được đào tạo bài bản: nếu khóa đào tạo được hoàn thành cách đây vài tháng, họ có thể đã quên. Nếu không tự thực hành trong quá trình đào tạo, họ có thể đã bỏ lỡ các bước quan trọng.

Mẹo bàn giao

• Một khóa đào tạo không phải là một cuộc thảo luận. Khuyến khích SPoC để những người dùng chính tự thực hiện công việc với sự hướng dẫn của họ.

• Người dùng chính không phải là chuyên gia kiểm tra. Việc kiểm tra chất lượng rất khó, vì vậy họ có thể bỏ sót các vấn đề. Hãy kiểm tra chéo các bộ phận rủi ro với họ.

• Tạo động lực. Tối đa hóa sự chấp nhận của mọi người thông qua việc tạo ra thứ gì đó mà giai đoạn bàn giao kỳ vọng và thậm chí là những việc họ muốn thử nghiệm.

• Phản ứng nhanh. Mọi thứ vẫn ổn khi có vấn đề xảy ra nếu bạn giải quyết chúng nhanh chóng.

• Tránh lùi ngày bàn giao. Mặc dù dự án có thể là lựa chọn tốt nhất vào thời điểm đó, nhưng rất nhiều thứ có thể thay đổi trong 2 tháng: mọi người có thể mất động lực, các yêu cầu thay đổi mới sẽ xuất hiện, có thể bạn cần phải thực hiện lại quá trình nhập dữ liệu, v.v… Việc lùi thời hạn cho thấy dự án có chi phí và rủi ro phát sinh. Thông thường, tốt hơn bạn nên bàn giao nhanh chóng, ngay cả khi dự án chưa hoàn hảo.

• Có mặt vào những ngày đầu tiên của quá trình triển khai nếu có những người dùng phản đối thay đổi. Bạn sẽ huấn luyện họ.

• Chờ một vài ngày, kiểm tra xem họ có thực sự áp dụng dự án hay không. Đôi khi họ tiếp tục sử dụng phần mềm cũ của mình: thói quen rất khó thay đổi!
  

Hành trình bàn giao cơ bản 

Giai đoạn triển khai thứ hai

Một tháng sau lần triển khai đầu tiên, Người lãnh đạo dự án xem xét danh sách phát triển còn lại chưa được khởi chạy trong Giai đoạn 1 (tức là việc phát triển được lên lịch ở giai đoạn tiếp theo: bạn có thể vận hành doanh nghiệp mà không cần nó, nhưng việc này không phải là lý tưởng).

Với phản hồi của người dùng, mức độ ưu tiên của phát triển cụ thể thường sẽ thay đổi (thông thường, chúng tôi nhận thấy 50% phát triển là không cần thiết và phát triển mới đã được yêu cầu).

Báo cáo tiến độ

Trước khi chúng tôi triển khai báo cáo tiến độ trong phương pháp của mình, hầu hết khách hàng đã triển khai trong phạm vi ban đầu và không nhìn được xa hơn thế. Chúng tôi đã bỏ lỡ cơ hội tạo ra tác động lớn hơn cho khách hàng trong các lĩnh vực khác: không cần sử dụng giấy tờ, cải tiến quy trình nhân sự, tự động hóa hóa đơn, cải thiện việc chia sẻ kiến ​​thức, v.v…

Báo cáo tiến độ được sử dụng để lên lịch cho một cuộc họp với lãnh đạo cấp cao nhất để nói về tương lai hợp tác của bạn và đưa thêm thông tin cho họ về những điều khả thi.

Việc để các nhà lãnh đạo dự án suy nghĩ về ROI và các cơ hội kỹ thuật số sẽ giúp tận dụng các kỹ năng tư vấn kinh doanh của bạn. Chúng được định hướng bởi câu hỏi sau đây:

Làm cách nào tôi có thể giúp nhân viên của khách hàng làm được nhiều việc hơn trong thời gian ngắn hơn?

Ma trận cơ hội kỹ thuật số

Sử dụng ma trận cơ hội kỹ thuật số, bạn sẽ xác định các cơ hội kỹ thuật số hàng đầu để đề xuất cho khách hàng của mình.

Ví dụ về ma trận cơ hội kỹ thuật số

Đánh giá các cơ hội khác nhau thông qua tác động tiềm năng và khả năng dễ dàng chuyển đổi của chúng, bạn sẽ phân loại chúng thành 4 loại chính và đưa ra quyết định dựa trên đó:

• Để tránh – có tác động tiềm năng thấp và thực hiện khá phức tạp: không có lợi ích thực sự ở đây.

• Tinh chỉnh – có tác động tiềm năng thấp nhưng dễ thực hiện: những sáng kiến đó không phải là ưu tiên nhưng có thể được xem xét ở một số thời điểm.

• Những người thay đổi cuộc chơi – có tác động tiềm năng cao nhưng thực hiện khá phức tạp: những sáng kiến đó có sức mạnh để chuyển đổi công ty theo hướng tốt.

• Lợi ích thấy ngay: Những ưu tiên số 1 khi bạn có thể kỳ vọng một sự cải thiện nhanh chóng và quan trọng.

Bạn thường bắt đầu bằng cách thực hiện các lợi ích thấy ngay được. Sau đó, nó phụ thuộc vào chiến lược của công ty: một số người thích tinh chỉnh (rủi ro thấp, tác động thấp hơn), những người khác sẽ thích thay đổi cuộc chơi (tác động cao, nhưng rủi ro cao hơn).

Mẹo báo cáo tiến độ

• Cũng giống như trong phân tích ROI, mục tiêu của bạn là tìm ra các cách để giúp nhân viên tiết kiệm thời gian trong các hoạt động hằng ngày của họ;

• Bạn thường làm việc với các nhà quản lý dự án trong khi thực hiện giải pháp. Báo cáo tiến độ dự kiến sẽ được hiển thị cho lãnh đạo cao nhất. Hãy đảm bảo sắp xếp cuộc họp với họ.

• Giữ mọi việc rõ ràng và đơn giản: Ưu tiên 3 phần thông tin có tác động hơn là 10 phần chỉ vừa đủ ổn;

• Bắt đầu vào Ngày 1: Hãy chú ý theo dõi trong suốt quá trình triển khai và ghi lại những quan sát của bạn về các cơ hội tiềm năng trong tổ chức;

• Chủ động: Đừng ngần ngại tổ chức các cuộc họp để thu thập thêm thông tin và đưa ra các giả định của bạn.
  

5. Thách thức triển khai

Cách khuyến khích người dùng đón nhận Odoo

Con người luôn chống lại sự thay đổi. Không có sự thay đổi nhỏ và không bao giờ chỉ là một chi tiết nhỏ. Từ nhân viên mới nhất đến người sáng lập, thay đổi là một vấn đề lớn!

Để triển khai một phần mềm quản lý mới không chỉ bao gồm việc thay thế một công cụ được hầu hết nhân viên sử dụng mà còn tạo ra việc mua trữ từ những người dùng cuối để đạt được tầm nhìn của công ty. Đó chắc chắn là một vấn đề lớn. Vì bạn sẽ không bao giờ “dùng đũa để gọt củ cà rốt”, nên các nhân viên trong công ty cần phải tin rằng phần mềm quản lý mới là công cụ gọt vỏ tốt nhất từ trước đến nay!

Để làm điều này, Người lãnh đạo dự án có các nguồn lực sau:

• Bản thân sản phẩm: một khi người dùng bị thuyết phục bởi các tính năng và lợi ích, họ sẽ dễ chấp nhận. Đào tạo những người dùng chưa được thuyết phục về các tính năng chính mà họ sẽ được hưởng lợi từ đó.

• Sự hỗ trợ của SPoC và những người sử dụng chính: vai trò của họ trong công ty và sự tích cực về dự án trước mặt nhân viên sẽ giúp bạn dễ dàng quản lý thay đổi.

• Các nhà tài trợ dự án (ví dụ: giám đốc điều hành) hỗ trợ dự án.

Các dự án thành công nhất thường được hưởng lợi từ việc nhiều người dùng cuối chấp nhận, giúp quá trình tham gia vào Odoo diễn ra suôn sẻ hơn.

Cách đối phó với những người phản kháng

Một sai lầm phổ biến là gạt những người không bị thuyết phục sang một bên (xét cho cùng, tất cả chúng ta đều thích làm việc với những người đồng ý với điều mình đang nói). Nếu ai đó không bị thuyết phục, hãy làm ngược lại: dành thời gian giải thích cho họ lý do/cách thức và “bán” cho họ giải pháp bằng một khóa đào tạo.

Thay đổi luôn được coi là chi phí và rủi ro cho những người dùng bị ảnh hưởng. Và một khoản chi phí/rủi ro luôn đáng được thực hiện nếu lợi ích bạn nhận được cao hơn nhiều. Trong khi cố gắng thuyết phục mọi người, đừng nói rằng điều đó không có rủi ro hoặc không phải là vấn đề lớn. Một sự thay đổi là một vấn đề lớn.

Thay vào đó, bạn phải “bán” những lợi ích của việc sử dụng giải pháp mới. Sắp xếp các bản demo của sản phẩm, kiểm tra cách chúng ta có thể giải quyết các điểm đau của họ và giải thích cho họ lý do tại sao chúng ta làm việc theo cách đó. Nếu có thể nhìn thấy lợi ích của giải pháp, họ sẽ chấp nhận rủi ro.

​

Trong quá trình triển khai với Casual Cushions, nhân viên kế toán là người phản kháng nhiều nhất trong công ty. Đội ngũ sản xuất vui mừng về việc loại bỏ hệ thống trước đó và vô cùng lạc quan về dự án. Nhiều tháng sau, nhân viên kế toán tiếp tục thách thức tôi trong mọi khóa đào tạo và thảo luận – chúng tôi đã xem xét từng công việc đến kiệt sức (đối chiếu ngân hàng có lẽ là công việc tồi tệ nhất). Mặt khác, đội ngũ sản xuất ưa thích mọi khóa đào tạo, và họ chưa bao giờ thực sự đặt ra nhiều câu hỏi.

Cuối cùng, khi chúng tôi đi vào triển khai, mọi thứ đã thay đổi. Nhân viên kế toán đã chấp nhận sự thay đổi – và vì cô ấy đã suy nghĩ rất nhiều về Odoo cũng như các tính năng của nó, cô ấy đã sẵn sàng sử dụng nó. Cô ấy biết phải đi đâu, làm gì, và tất cả các trường hợp góc và bút toán khả thi của cô ấy đã được bảo vệ.

Mặt khác, đội ngũ sản xuất đã gặp khó khăn hơn nhiều. Họ liên tục quên việc đào tạo, và đã trình bày cho tôi rất nhiều trường hợp góc trong quá trình sản xuất mà trước đây chưa từng được giải quyết. Họ đã làm việc thâu đêm để bắt kịp việc sản xuất và rất thất vọng.

Tôi đã nói chuyện với nhân viên kế toán vào tuần trước, và cô ấy đã đề cập đến việc đối chiếu ngân hàng ở Odoo tốt hơn như thế nào và rất vui khi được tiếp tục sử dụng. Khi một khách hàng tò mò và sẵn sàng thử nghiệm cũng như thảo luận về quy trình (về cơ bản là tham gia vào dự án), dự án có nhiều khả năng thành công hơn.

Cách giữ mọi thứ đơn giản

Khách hàng có xu hướng khiến mọi thứ trở nên phức tạp hơn so với thực tế.

• Tránh đưa ra nhiều lựa chọn cho khách hàng và để họ chọn những gì họ thích. Thay vào đó, hãy đề xuất các giải pháp tốt nhất và không hiển thị các tùy chọn khác trừ khi khách hàng không hài lòng với đề xuất của bạn.

• Tránh trì hoãn các quyết định, buộc mọi người phải quyết định, ngay cả khi họ không chắc chắn. Hãy ngăn họ nói: “Chúng tôi sẽ hỏi những người dùng chính họ nghĩ gì” và “Tôi phải hỏi người quản lý về ý kiến của họ”.

Ngay cả khi bạn nghĩ mình đã đơn giản hóa mọi thứ, chúng ta luôn có thể làm tốt hơn:

• Mời một chuyên gia ứng dụng tham gia vào các giai đoạn quan trọng (ví dụ: Phân tích GAP) để đánh giá ngang hàng. Vì không tham gia vào dự án, họ có thể dễ dàng đưa ra những quyết định khó khăn và cung cấp quan điểm khác cho bạn.Nếu có thể nhìn thấy lợi ích của giải pháp, họ sẽ chấp nhận rủi ro.

Cách quản lý kỳ vọng của khách hàng

​

Vài năm trước, giám đốc điều hành của một khách hàng tiềm năng đã yêu cầu gặp tôi trước khi ký hợp đồng. Cô ấy nói với tôi: “Dự án này là sống còn đối với công ty của tôi, hãy nói với tôi rằng mọi thứ sẽ diễn ra suôn sẻ.” Tôi trả lời: “Không. Một dự án như vậy thực sự rất khó. Chúng ta sẽ có rất nhiều vấn đề. Nhưng cuối cùng, công ty của cô sẽ trở nên tốt hơn. Và tôi cần cô, với tư cách là giám đốc điều hành, hỗ trợ dự án khi đội ngũ của cô phàn nàn, để vượt qua những khó khăn này.”

Tôi không nhận được phản hồi từ khách hàng này cho đến hai năm sau khi vị giám đốc điều hành gọi điện cho tôi. Dự án đã bị trì hoãn nghiêm trọng và những người dùng chính mất lòng tin vào sản phẩm. Một trong những điều đầu tiên mà giám đốc điều hành nói với tôi là: “Dự án này là một cơn ác mộng, chúng tôi đã trễ 12 tháng và tôi không thấy điểm kết thúc. Nhưng tôi đã làm những gì anh yêu cầu: Tôi luôn hỗ trợ dự án, không bao giờ chỉ trích sản phẩm của anh trước cả nhóm và luôn thúc đẩy tích cực những người dùng chính muốn từ bỏ dự án. Nhưng, bây giờ, chúng tôi đang chạm ngưỡng giới hạn, tôi cần anh làm điều gì đó cho tôi…”

Vì vậy, hai phút này với vị giám đốc điều hành trước khi ký hợp đồng đã thực sự cứu được dự án. Nếu vị giám đốc điều hành đứng về phía những người dùng chính, dự án đã bị hủy bỏ vài tháng trước. Vì cô ấy nghiêm túc thực hiện vai trò hỗ trợ dự án nên dự án đã được cứu và triển khai sản xuất sau hai tháng.

Câu chuyện này minh họa hoàn hảo sức mạnh của việc quản lý kỳ vọng của khách hàng. Nếu Fabien nói: “Đừng lo lắng, dự án rất dễ dàng”, vị giám đốc điều hành đã mất tin tưởng vào dự án và có lẽ đã nghe theo lời khuyên của những người dùng chính từ lâu khi tình trạng căng thẳng leo thang nghiêm trọng.

Cách viết một thông số kỹ thuật tốt

Một thông số kỹ thuật tốt thường ngắn gọn, trực quan và có cấu trúc như sau:

• Nhu cầu kinh doanh: Trường hợp sử dụng (cái gì) và bằng chứng của nó giải thích tại sao khách hàng thực sự cần tính năng đó (tối đa 2 hoặc 3 đoạn).

• Thông số kỹ thuật về chức năng: nếu có thể, giải pháp được đề xuất sử dụng Odoo (cách thức) được minh họa bằng một loạt ảnh chụp màn hình hoặc mô hình thu nhỏ (mockup) có kèm ghi chú.

• Gợi ý kỹ thuật: Những thứ mà nhà phát triển sẽ phải quan tâm.

Tránh nhập lịch sử dữ liệu

Ngoài dữ liệu chính, khách hàng thường yêu cầu nhập toàn bộ lịch sử dữ liệu, chẳng hạn như báo giá và doanh số bán hàng trong vòng 7 năm trở lại đây. Việc này mất rất nhiều thời gian và sẽ chiếm một phần lớn ngân sách. Bởi nó làm tăng thêm rủi ro cho sự thành công của dự án, chúng ta chỉ nên làm điều đó khi nó thực sự hợp lý. 

Hãy đặt những câu hỏi sau để kiểm tra xem nó có thực sự cần thiết hay không:

• Có thể giữ thông tin đó trong phần mềm cũ hoặc tệp xuất không?

• Bao lâu thì khách hàng của bạn sẽ tham khảo thông tin đó? Dùng cho mục đích nào?

• Nó có thể có tác động chiến lược nào trong 2, 3 hoặc 4 năm?

Cũng giống như bất kỳ yêu cầu nào khác, miễn là khách hàng không thể thuyết phục bạn, bạn nên từ chối yêu cầu nhập hoặc trì hoãn cho đến sau khi bàn giao.

​

Vài tháng trước, tôi đã triển khai Kế toán Odoo (Odoo Accounting) cho Ibbeo Cosmetiques, một tập đoàn dược phẩm gồm ba công ty ở Pháp. Trong giai đoạn Khởi động, SPoC của tôi đã nói với tôi rằng cô ấy phải kiểm soát tất cả dữ liệu lịch sử từ Sage. Cô cần tất cả trong Odoo để kiểm tra nó khi cần thiết. Tôi đã giải thích với cô ấy rằng việc nhập dữ liệu lịch sử khiến tiến độ của dự án gặp rủi ro và sẽ mất nhiều ngày tra cứu để thu được rất ít giá trị gia tăng.

Tôi đã thỏa thuận với cô ấy: chúng tôi bắt đầu hạch toán cho cả ba công ty chỉ trong ba tuần, với việc cô ấy chỉ cần can thiệp rất ít. Nếu làm theo cách của tôi, chúng tôi sẽ còn vài giờ trên gói dịch vụ để sử dụng trong tương lai. Và nếu sau này, cô ấy quyết định vẫn cần nhập dữ liệu lịch sử vào Odoo, chúng tôi có thể làm điều đó trong giai đoạn hai. Cô ấy đã đồng ý.

Một tuần sau, chúng tôi có cuộc gọi đầu tiên và tôi đã nhập số dư đầu kỳ và dữ liệu chính. Cuối cùng, sau khóa đào tạo, dự án đã đi vào hoạt động cho cả ba công ty chỉ sau 2,5 tuần, với 9 giờ còn lại trong gói dịch vụ.

Một tháng trước, cô ấy đã gửi e-mail để cảm ơn tôi vì sự khởi động nhanh chóng và rằng Odoo thân thiện với người dùng hơn rất nhiều so với ERP trước đây mà cô ấy từng làm việc cùng. Cô ấy cũng nói với tôi rằng trong 3 tháng qua, cô ấy không cần phải kiểm tra lại bút toán kế toán trước đó lần nào và đã liên hệ với cố vấn bán hàng của mình để bổ sung các mô-đun và kiểm soát tất cả các hoạt động của mình tại Odoo.

Khi chúng tôi có thêm nhiều công ty kế toán tham gia Odoo, tôi thường nhận được yêu cầu nhập các bút toán kế toán từ 5 năm qua. Tôi thường sử dụng dự án này làm ví dụ và để họ quyết định. Hoặc triển khai dự án chỉ trong 2 tuần với ít nỗ lực và vài giờ tư vấn hoặc triển khai trong 2 tháng và trả gấp 4 lần cho một thứ mà họ sẽ sử dụng mỗi năm một lần.

Tránh viết tài liệu cho khách hàng của bạn

Khi triển khai Odoo, bạn có thể được định hướng tạo tài liệu cụ thể để giúp người dùng cuối “nhập môn” dễ dàng hơn. Ngay cả khi đó có vẻ là một ý tưởng hay, bạn sẽ nhận ra giá trị mà bạn có thể mang lại không xứng đáng với thời gian đầu tư. Là một Người lãnh đạo dự án, bạn nên tập trung vào những nhiệm vụ mà chỉ bạn mới có thể giao.

Nói cách khác, Người lãnh đạo dự án không nên lãng phí thời gian vào việc lặp lại những giải thích đã được đưa ra trong suốt dự án. Khách hàng phải chịu trách nhiệm xây dựng tài liệu riêng, dựa trên các trường hợp kinh doanh và thuật ngữ của riêng họ.

Ngoài ra, SPoC là người có kiến thức kinh doanh rộng nhất trong số tất cả các bên liên quan triển khai Odoo.

Hơn nữa, việc để khách hàng viết tài liệu của riêng họ đảm bảo các công việc của Odoo đã hoàn thiện sẽ được SPoC hiểu và xử lý đúng cách. Điều này giúp giảm bớt quy trình quản lý thay đổi vì những người dùng cuối có quyền truy cập trực tiếp vào nguồn kiến thức đáng tin cậy trong chính công ty của họ.

Tất nhiên, hầu hết các tiêu chuẩn đã được bao gồm trong tài liệu hiện có, Odoo chia sẻ tất cả kiến thức trực tuyến. Các dự án nhỏ thường không yêu cầu tài liệu cụ thể.

Cách giải quyết các nhu cầu cụ thể của khách hàng

Khi giao dịch với khách hàng, hãy nhớ rằng có sự khác biệt giữa mục tiêu của các bên liên quan và nhu cầu của người dùng chính. Hầu hết các ưu tiên của người ra quyết định là thời gian và ngân sách, trong khi những người dùng chính chủ yếu sẽ yêu cầu các tính năng cụ thể. Khi các mục tiêu này mâu thuẫn với nhau, bạn sẽ phải quyết định bạn muốn làm hài lòng ai?

Bạn nên luôn làm những gì bạn nghĩ là tốt nhất cho dự án; điều này có nghĩa là thử thách những gì người dùng chính yêu cầu, đến mức từ chối thực hiện nếu bạn cho rằng nó không đáng giá đối với dự án. Hãy sử dụng các chiến thuật sau để xử lý những yêu cầu phát triển tùy chỉnh:

• Nó có thực sự cần thiết?

• Nó có đáng để hỗ trợ chi phí (phát triển và duy trì) không?

• Mức lợi ích có đủ quan trọng không?

• Chúng ta có thể phục vụ cùng một mục tiêu với cách tiếp cận khác không?

Nếu bạn đi đến kết luận rằng không đáng để phát triển một tính năng cụ thể, bạn nên cố gắng nhiều hơn để thuyết phục khách hàng. Có các chiến thuật khác nhau cho việc này: giải thích “Tại sao”, thực hiện nó sau ngày “Bàn giao”, báo cáo cho người quản lý (mặc dù không phải là lý tưởng, nhưng đôi khi điều đó là cần thiết).

Chiến thuật 1: Nó có thực sự cần thiết?

Giả sử bạn có yêu cầu phát triển tùy chỉnh sau:

Khách hàng có một trang web được phát triển bằng Magento Commerce và không muốn thay đổi trang web của họ vì họ đã đầu tư rất nhiều vào nó. Nhưng họ muốn Odoo được tích hợp hoàn toàn với trang web Magento của họ (bao gồm các sản phẩm, phiếu giảm giá, lượt theo dõi trên các giỏ hàng bị bỏ quên, v.v…)

Cách tốt nhất để đánh giá xem nó có cần thiết hay không là kiểm tra xem khách hàng đã có tính năng này trong phần mềm cũ của họ chưa. Nếu khách hàng ghi lại tất cả các đơn hàng theo cách thủ công trong phần mềm cũ, họ có thể thực hiện theo cách tương tự với Odoo. Sau đó, chúng tôi khuyên bạn nên bắt đầu sản xuất trước mà không cần phát triển tích hợp với Magento, sử dụng Odoo trong vài tháng và sau đó quyết định xem nó có xứng đáng hay không. Hãy nhớ rằng, các ưu tiên của khách hàng thay đổi khi họ đi vào sản xuất.

Về mặt quản lý thay đổi, việc triển khai các thay đổi trong quy trình kinh doanh theo từng bước sẽ dễ dàng hơn thay vì làm mọi thứ cùng một lúc. Với mô-đun của Odoo, rất hợp lý khi triển khai theo nhiều giai đoạn: đầu tiên, với những gì khách hàng thực sự cần để vận hành doanh nghiệp và chỉ sau khi chuyển sang giai đoạn thứ hai, các tính năng khác mới cần thay đổi để cải thiện hiệu quả.

​

Một người dùng chính đã yêu cầu tôi sao lại một báo cáo phức tạp mà họ đã xây dựng hằng tuần trong Excel. Theo người dùng, báo cáo này rất quan trọng đối với giám đốc điều hành. Tuy nhiên, tôi đã thử thách người dùng nhằm biết được KPI nào liên quan đến giám đốc điều hành.

Dường như giám đốc điều hành chỉ kiểm tra một vài số tiền, đó là số dư của một số tài khoản phân tích. Thay vì tiếp tục phát triển, tôi đã chỉ cho giám đốc điều hành cách kiểm tra những số dư này trực tiếp trong Odoo và họ rất vui vì điều đó.

Thử thách khách hàng không chỉ làm giảm sự phát triển tùy chỉnh và rủi ro chậm trễ mà còn mang lại nhiều giá trị kinh doanh.

Chiến thuật 2: Nó có đáng để hỗ trợ chi phí không?

Bạn cần đánh giá lợi ích: khách hàng sẽ tiết kiệm được bao nhiêu ngày công mỗi tháng nhờ tính năng này? Thông thường, khách hàng chỉ tính xem hiện tại họ dành bao nhiêu thời gian cho loại công việc này và nghĩ rằng họ sẽ tiết kiệm được bao nhiêu trong tương lai. Trên thực tế, họ vẫn sẽ phải ghi lại tất cả dữ liệu cần thiết cho việc tính toán, xử lý các ngoại lệ theo cách thủ công... Ví dụ: Ngay cả khi khách hàng phát triển trình kết nối Magento, họ vẫn sẽ phải giải quyết tất cả các vấn đề, ghi lại chiết khấu giá trong cả hai giải pháp phần mềm, giải quyết vấn đề tồn kho vì việc đồng bộ hóa không theo thời gian thực...

Sau đó, bạn cần đánh giá các chi phí liên tục. Thông thường, khách hàng chỉ nhìn thấy “chi phí phát triển một lần”. Trên thực tế, bạn có thể nhân chi phí này với 2 hoặc 3 cho việc bảo trì và nâng cấp trong tương lai trong 5 năm tới. 

Lưu ý rằng việc sử dụng mô-đun cộng đồng cho phép bạn tiết kiệm thời gian trong quá trình phát triển ban đầu, nhưng bạn vẫn sẽ phải tính chi phí thử nghiệm, bảo trì, trì hoãn dự án và nâng cấp. Một mô-đun cộng đồng cũng là một món nợ kỹ thuật.

Chiến thuật 3: Mức lợi ích có đủ đáng kể không?

Giả sử bạn có yêu cầu phát triển tùy chỉnh sau:

Khi thực hiện đơn đặt hàng cho một dự án xây dựng, chúng tôi muốn tạo ra một loạt nhiệm vụ dựa trên một bộ quy tắc phụ thuộc vào sản phẩm, khách hàng và địa điểm.

Khi có yêu cầu tùy chỉnh, trước tiên bạn nên đặt câu hỏi về số lượng: “Bạn giành được bao nhiêu dự án xây dựng mỗi tháng?” Giả sử khách hàng giành được 10 dự án này mỗi tháng. Bạn có thể mất 10 phút để tạo và cập nhật các tác vụ bằng cách sao chép và cập nhật các mẫu dự án.

Có đáng để khởi chạy một phát triển phức tạp để tiết kiệm dưới 2 giờ làm việc mỗi tháng không? Chắc chắn là không, tính năng này sẽ tốn khoảng 10 ngày phát triển, cộng với 25% số tiền này mỗi năm.

Chiến thuật 4: Chúng ta có thể phục vụ cùng một mục tiêu với cách tiếp cận khác không?

Giả sử bạn có yêu cầu của khách hàng như sau: 

Tôi muốn đồng bộ hóa lịch Outlook của chúng tôi với Quản lý quan hệ khách hàng của Odoo (Odoo CRM).

Odoo có trình kết nối với Lịch Google theo tiêu chuẩn, nhưng không có trình kết nối với Outlook. Việc phát triển và duy trì một trình kết nối có thể rất tốn kém. Tuy nhiên, có rất nhiều dịch vụ đồng bộ hóa Lịch Google với Outlook (chẳng hạn như IFTTT). Vì vậy, một giải pháp ở đây sẽ là đăng ký và thiết lập một dịch vụ như vậy cho mọi nhân viên.

Giải pháp này không hoàn hảo vì bạn sẽ phải sửa đổi thiết lập của mình mỗi khi tuyển nhân viên mới. Nhưng giải pháp sẽ sẵn sàng sau 2 giờ và chỉ mất 10 phút cho mỗi nhân viên mới, vẫn ít hơn nhiều so với một phát triển mới, nếu công ty có ít hơn 100 nhân viên.

Vài năm trước, tôi đã triển khai cho Bioulvax, một nhà sản xuất rượu của Bỉ. SPoC cho dự án rất nhiệt tình, nhưng anh ấy tin rằng cách làm việc của mình là hiệu quả nhất và mọi người trong công ty cũng nên làm việc như anh ấy.

Chúng tôi đã không làm tốt công việc vì chúng tôi đã thỏa hiệp và chấp nhận một số yêu cầu của anh ấy. Chúng tôi có các ô ngày tháng gần như không bao giờ được sử dụng, ô lựa chọn lấp kín màn hình mà chẳng vì lý do hợp lý nào, các mục menu không thân thiện với người dùng... Sau một vài tháng làm việc với hệ thống, chúng tôi nhận thấy rất nhiều nhân viên đã không sử dụng nó, họ đang quay lại phần mềm cũ mà không báo cho ban quản lý.

Khi nhận ra điều đó, chúng tôi đề xuất: “Hãy quay lại cách hệ thống hoạt động theo tiêu chuẩn đầy đủ và trao đổi với nhóm để xem họ muốn gì từ hệ thống.” Nói cách khác, chúng tôi hỏi mọi người xem họ muốn gì, thay vì ép buộc họ phải làm theo một cách cụ thể. Chúng tôi đã tổ chức các bản demo hoàn toàn dựa trên tiêu chuẩn với mục tiêu của nhóm.

Họ không thể tin việc sử dụng hệ thống dễ dàng như thế nào và khi bàn giao lại hệ thống, toàn bộ nhóm đã sử dụng Odoo và bỏ thói quen cũ của họ. Tôi đã học cách luôn thách thức các yêu cầu của SPoC và tiếp tục tập trung vào các mục tiêu kinh doanh. Thông thường, khách hàng hiểu doanh nghiệp của họ, nhưng không biết cách triển khai nó.

Tại sao bạn nên tối thiểu hóa phát triển tùy chỉnh?

Đối với khách hàng, một phát triển tùy chỉnh tạo ra thêm chi phí và sự chậm trễ về thời gian, đôi khi đến mức đưa dự án vào tình thế rủi ro. Ngoài ra, việc phát triển tùy chỉnh dẫn đến nợ kỹ thuật mà khách hàng sẽ phải trả trong những năm tới dưới hình thức chi phí bảo trì và nâng cấp. Một khoản nợ kỹ thuật như vậy tốn khoảng 25% chi phí phát triển MỖI NĂM (xấp xỉ 17% khi bảo trì + xấp xỉ 8% khi nâng cấp).

Mỗi phát triển có vẻ đơn giản và giá cả phải chăng. Tuy nhiên, như đã giải thích, độ phức tạp của một dự án tăng lên theo cấp số nhân khi số lượng tùy chỉnh tăng lên, chứ không phải tăng theo tuyến tính. Khách hàng có thể muốn giải quyết những gì họ không thích trong phần mềm trước đây của họ, nhưng có tốt hơn không nếu tiêu chuẩn hóa quy trình kinh doanh của họ và triển khai dự án nhanh hơn gấp hai lần cũng như giảm một nửa giá?

Đối với các công ty dịch vụ triển khai, phát triển tùy chỉnh thường đi kèm với chi phí cao, vì giá trị khách hàng thấp. Đây là tình huống điển hình: bạn ước tính 10 ngày để phát triển một tính năng; khách hàng nghĩ rằng thời gian đó quá dài cho một tính năng cơ bản như vậy nên bạn chỉ tính trong 8 ngày, nhưng cuối cùng, bạn đã dành 12 ngày cho nó. Sau đó, chúng tôi phát hiện ra các vấn đề/thay đổi cần thiết vì bạn phải làm việc đó nhanh chóng và khách hàng sẽ không trả phí thêm ngày vì đó là lỗi của bạn. Dịch vụ ký quỹ đáng lẽ là 35%, giờ đã bị lỗ 6% trên dịch vụ!

Để phát triển, việc tập trung vào các dịch vụ có giá trị với biên lợi nhuận tốt hơn sẽ dễ dàng hơn và giảm rủi ro về số giờ không được thanh toán. Các dịch vụ đó bao gồm: quản lý dự án, phân tích kinh doanh, các tùy chỉnh mà không cần phát triển, quản lý thay đổi và đào tạo.

Dù sớm hay muộn, các công ty dịch vụ xây dựng tư duy về việc giảm phát triển tùy chỉnh sẽ có khả năng cạnh tranh hơn những công ty khác. Các công ty quản lý tốt hơn những kỳ vọng của khách hàng sẽ có chi phí triển khai dự án thấp hơn. Tất nhiên, phát triển tùy chỉnh đôi khi là cần thiết để điều hành một doanh nghiệp. Tuy nhiên, theo kinh nghiệm của chúng tôi, phần lớn các yêu cầu của khách hàng hoặc không đáng với chi phí bỏ ra và không phù hợp khi họ bắt đầu sử dụng Odoo hoặc họ có thể hoàn thành mà không cần đến vì đó không phải là một phần trong cách sử dụng cốt lõi của họ.

Mecatis là một công ty kỹ thuật chuyên về việc hình thành, sản xuất và bảo trì máy móc sản xuất. Họ bắt đầu sử dụng cộng đồng Odoo vào năm 2013 và bị mắc kẹt với một phiên bản rất cũ. Vào năm 2017, họ đã liên hệ với chúng tôi để nâng cấp lên Odoo 11. Chúng tôi đã khám phá ra 4 mô-đun tùy chỉnh và 55 mô-đun cộng đồng trên cơ sở dữ liệu của họ.

Họ đã chi hàng chục nghìn euro để phát triển và bảo trì, một điều không bình thường đối với một công ty có 10 nhân viên. Đó là một khoản nợ kỹ thuật lớn và chi phí để nâng cấp các mô-đun này sẽ rất lớn.

Thay vì nâng cấp các mô-đun này, chúng tôi đã thử thách từng mô-đun: một số mô-đun có thể được thay thế bằng các tính năng hiện có trong Odoo 11, một số tính năng không được sử dụng và với phần còn lại, khách hàng thậm chí không biết tác vụ của những mô-đun này. Vì vậy, thay vì nâng cấp các mô-đun tùy chỉnh của họ, chúng tôi đã đào tạo họ theo tiêu chuẩn và giúp họ thay đổi cách họ làm việc. Chỉ trong 100 giờ phục vụ, chúng tôi đã chuyển họ sang Odoo trực tuyến mà không có bất kỳ phát triển nào. Chi phí hằng tháng của họ đã được giảm đi 10 lần.

Tôi chắc chắn trong quá trình triển khai, Mecatis hoặc đối tác của họ nghĩ họ cần những mô-đun cộng đồng này. Nhưng cuối cùng, hóa ra việc tuân theo những tiêu chuẩn để tránh bị mắc kẹt trong các phiên bản cũ có lợi hơn cho một công ty nhỏ. Sau khi chuyển sang Odoo trực tuyến, khách hàng rất vui vì chúng tôi đã có được nhà tài trợ tốt; họ đã đăng ký làm đối tác để bán lại Odoo trực tuyến cho khách hàng của chính mình, ủy thác dịch vụ cho nhóm của chúng tôi.

Cách đối phó với chính trị nội bộ

Khi có sự cố xảy ra, mọi người cố gắng tìm ai đó phải chịu trách nhiệm và viện lý do để bào chữa cho mình. Điều này thường xảy ra khi một số công ty dịch vụ tham gia vào dự án. Trong trường hợp thất bại, họ sẽ khẳng định mình không có lỗi và nói rằng đó là trách nhiệm của công ty kia.

Chính trị nội bộ là một trò chơi mà mọi người đều thua. Cách tốt nhất để đối phó với điều này là tránh chơi trò chơi. Khi một dự án thất bại, đó thường là lỗi của tất cả mọi người. Vì vậy, khi điều tồi tệ xảy ra, đừng lãng phí thời gian tranh cãi xem ai là người chịu trách nhiệm. Đừng lãng phí thời gian xây dựng một hàng phòng thủ cho bản thân.

Thay vào đó, hãy tập trung vào việc tiếp tục và giải quyết vấn đề (cho dù vấn đề có phải là của bạn hay không; chúng tôi không quan tâm ai chịu trách nhiệm, chúng tôi chỉ quan tâm đến sự thành công của dự án).

Minerex là một công ty thu mua các vật liệu xây dựng khác nhau từ Mỹ, sau đó nhập khẩu và phân phối chúng ở Mexico. Các văn phòng của họ đều có trụ sở tại Mexico. Trước năm 2016, họ sử dụng SAP để quản lý hoạt động kinh doanh của mình.

Các chủ sở hữu của Minirex đang sống ở Mỹ (Jacksonville, FL). Họ quyết định triển khai Odoo, nhưng không tham gia vào hoạt động của công ty. Họ không biết về các quy trình khác nhau hoặc những tài liệu kinh doanh được công ty sử dụng... Công ty được các nhân viên ở Mexico vận hành hiệu quả. Và đây là một công thức cho sự thất bại. Tại sao?

Quyết định triển khai Odoo là do các chủ sở hữu đưa ra mà không có sự mua trữ của bất kỳ ai từ văn phòng Mexico. Vì vậy, kể từ cuộc gọi Khởi động dự án, rõ ràng không có nhân viên nào ở Mexico mong muốn triển khai Odoo. Vì không ai hỏi ý kiến của họ về nó, họ coi Odoo như một thứ gì đó đang bị áp đặt lên họ (nghĩa là “chủ sở hữu chỉ đang cố gắng tiết kiệm tiền, ném phần mềm ERP này cho chúng tôi”). Trong suốt quá trình thực hiện, họ có tâm thế chống lại sự thay đổi: mọi thứ diễn ra chậm chạp, việc triển khai có mức độ ưu tiên thấp đối với họ, v.v…

Ban đầu, chúng tôi không nhận thức được tình trạng này. Ngay sau khi phát hiện ra nó, chúng tôi đã có một cuộc trao đổi với các chủ sở hữu. Cả chủ sở hữu và nhà tư vấn đã đi đến Mexico để đạt được mua trữ từ văn phòng Mexico. Chúng tôi đã cho họ thấy khả năng của Odoo và nó xử lý các quy trình của họ hiệu quả hơn so với hệ thống SAP trước đây của họ như thế nào. Cho đến thời điểm đó, việc triển khai bắt đầu thực sự tiến triển.

Tóm lại, hãy đảm bảo những người dùng chính đã tham gia trước khi chuyển sang giai đoạn triển khai. Cuối cùng, chính những người dùng chính này sẽ sử dụng Odoo và cộng tác với bạn trong quá trình triển khai.

Cách ứng phó với động lực của những người khác nhau

Quản lý nhiều dự án cùng lúc không phải là điều dễ dàng và việc phải điều chỉnh bài phát biểu của bạn cho phù hợp với từng người làm việc với bạn là điều không thể. Tuy nhiên, đôi khi nó giúp phát hiện các kiểu tính cách khác nhau:

“Làm ngay bây giờ” đi đúng vào vấn đề.

Nói chung, SPoC của bạn sẽ không đầu tư đủ thời gian cho quá trình học tập của họ và có thể diễn ra quá nhanh để người dùng cuối được giới thiệu chính xác trong Odoo. Hành động của bạn là:

• Đảm bảo SPoC hiểu đúng về Odoo (kiểm tra ba lần).

• Đảm bảo SPoC trao đổi nội bộ đủ về dự án (kiểm tra xem họ có dành thời gian để chuẩn bị bài phát biểu cho những người dùng cuối không).

• Đảm bảo những người chưa đồng tình tham gia vào dự án (tham gia nhiều hơn vào việc lựa chọn những người dùng chính).

• Tham gia vào việc đào tạo những người dùng cuối (đào tạo song song).

“Làm đúng” tôn trọng các quy tắc đến từng chi tiết nhỏ nhất.

SPoC của bạn có thể phản đối bất kỳ thay đổi nào “bởi chúng tôi luôn làm việc như vậy” và đặt câu hỏi về tính hợp pháp của bạn trong việc đề xuất một cách tiếp cận mới. Hành động của bạn là:

• Khéo léo thách thức các yêu cầu của khách hàng (tập trung nhiều vào giá trị gia tăng hơn là tiêu chuẩn).

• Tham gia với các chuyên gia ứng dụng nhanh hơn để tăng cường tính hợp pháp cho các đề xuất của bạn.

“Làm một cách hài hòa” có cái nhìn tổng quan tốt về doanh nghiệp của họ và mong đợi điều tương tự trong dự án của họ. SPoC của bạn có thể muốn có toàn quyền kiểm soát mọi tình huống (từ những chi tiết nhỏ nhất đến bức tranh lớn).

Hành động của bạn là:

• Đảm bảo những người dùng chính tham gia các khóa học trên https://odoo.com/learn.

• Đảm bảo họ hiểu biết về Odoo (đào tạo thêm nếu được yêu cầu).

“Làm cùng nhau” có tính linh hoạt cao, định hướng theo giải pháp. SPoC của bạn sẽ có 1.000 ý tưởng mỗi phút và thường xuyên thay đổi ý kiến của họ. Hành động của bạn là:

• Khiến các quy tắc trở nên rõ ràng: SPoC thể hiện nhu cầu của doanh nghiệp (cái gì và tại sao) và bạn đưa ra quyết định về cách họ nên sử dụng Odoo (như thế nào).

Tại sao những Người lãnh đạo dự án trẻ tuổi nên cảm thấy tự tin?

Chúng tôi đã thấy rất nhiều Người lãnh đạo dự án trẻ tuổi nghĩ rằng họ không “đủ tốt” trước những người có kinh nghiệm và do đó họ không ủng hộ những gì mình nghĩ.

Kinh nghiệm được đánh giá quá cao. Các quyết định kinh doanh phải luôn được hỗ trợ bởi ý thức chung chứ không phải (chỉ) bởi những kinh nghiệm trong quá khứ. Bạn không cần phải có kinh nghiệm để trở nên có lý trí. Đôi khi, kinh nghiệm là nghĩa vụ nhiều hơn là bằng chứng về kiến thức: mọi người làm mọi việc “bằng kinh nghiệm” (thói quen), chứ không phải vì đó là cách tiếp cận hợp lý nhất tùy theo bối cảnh.

Vì lý do đó, những Người lãnh đạo dự án trẻ không nên ngại bảo vệ quan điểm của mình và thách thức những người có kinh nghiệm. Điều này sẽ buộc những người có kinh nghiệm giải thích lý do tại sao họ nghĩ theo một cách nhất định. Nếu họ có lý, kinh nghiệm của họ sẽ thuyết phục bạn. Nếu không, hãy bảo vệ quan điểm của bạn.

Tôi đã thuê hơn 60 Người lãnh đạo dự án trong vài năm qua và phần lớn họ đều là sinh viên mới tốt nghiệp. Họ là những người cởi mở, năng động, tràn đầy năng lượng và muốn chứng tỏ bản thân.

Phương pháp triển khai dự án của chúng tôi kết hợp với sự phát triển không ngừng của sản phẩm khiến đường cong học tập của “những lính mới” của chúng tôi gần như thẳng đứng trong những tháng đầu tiên của họ với tư cách là Người lãnh đạo dự án. Thay vì kinh nghiệm, việc nhập môn tốt mang lại cho họ những công cụ phù hợp khi thuyết phục khách hàng.

Thông điệp quan trọng mà tôi truyền đạt cho những người mới của mình luôn giống nhau: bất kể kiến thức và kinh nghiệm của bạn là gì, kỹ năng quan trọng nhất để thành công với tư cách Người lãnh đạo dự án là có một tư duy vững vàng.

6. Kiểm tra

Trường hợp thực tế 1

Trong quá trình triển khai một dự án kéo dài 9 tháng, một người dùng chính yêu cầu bạn thay đổi một tính năng sẽ giúp họ tiết kiệm 4 giờ làm việc mỗi tuần. Người dùng này cho bạn biết rằng đó là lý do chính khiến họ muốn thay đổi phần mềm của mình. Thật không may, tính năng này không phải là tiêu chuẩn và ước tính sẽ mất 2 tuần để phát triển thêm.

Bạn sẽ làm gì?

A. Nếu khách hàng đã sẵn sàng thanh toán; bạn có thể phát triển những gì họ yêu cầu.

B. Cố gắng thuyết phục khách hàng tránh phát triển tính năng này, nhưng cuối cùng vẫn chấp nhận nếu họ thực sự muốn nó.

C. Thêm tính năng này vào phần danh sách tính năng cần phát triển (backlog) nhằm thực hiện sau khi bàn giao.

Đáp án: C. Vì người dùng này không sử dụng tính năng như vậy trong phần mềm hiện tại của họ, họ có thể làm việc mà thiếu tính năng này thêm vài tháng. Tránh để dự án bị trì hoãn thêm: thêm 2 tuần dường như không nhiều, nhưng bạn không biết được mình sẽ phải đối mặt với bao nhiêu quyết định như thế này trong suốt quá trình của dự án.

Trường hợp thực tế 2

Người quản lý dự án của một công ty có 20 nhân viên muốn thêm một bước xác nhận bổ sung về chi phí của nhân viên: bất kỳ khoản chi phí nào cao hơn 500 euro đều phải có sự chấp thuận thứ hai của giám đốc tài chính. Bạn ước tính cần 2 ngày để phát triển thêm bước này.

Bạn sẽ làm gì?

A. Thêm các bước xác nhận mới để phù hợp với các ràng buộc của công ty.

B. Xác định chính sách nội bộ (hỏi người quản lý và giám đốc tài chính của bạn về chi phí > 500 euro) và yêu cầu nhân viên gửi e-mail cho cả hai.

C. Từ chối xem xét đó là nhu cầu có thể chấp nhận.

Đáp án: B. Các công ty nhỏ thường thay đổi cách thức hoạt động. Do đó, thường thì tốt hơn là xác định chính sách, thay vì phát triển một tính năng tùy chỉnh. Tất cả những gì bạn phải làm là gửi quy trình qua e-mail cho nhân viên: gửi e-mail hỏi người quản lý và giám đốc tài chính của bạn. Trái ngược với phát triển không linh hoạt, các chính sách có thể được điều chỉnh một cách dễ dàng và vẫn thường phù hợp với ý thức chung (ví dụ: nếu người quản lý của bạn đang đi nghỉ dưỡng, bạn chỉ có thể yêu cầu giám đốc tài chính xác nhận).

Trường hợp thực tế 3

Trong phiên xác nhận giao hàng hàng tuần từ xa, bạn đang thử nghiệm phần mềm của mình (cấu hình và các tùy chỉnh tối thiểu) trong chu kỳ thanh toán hóa đơn của khách hàng. Đột nhiên, giám đốc tài chính xuất hiện trước khán giả và chỉ rõ rằng tính năng xác nhận hóa đơn hàng loạt bị thiếu sót và (về tổng thể) bản demo của bạn là một sự thất bại. Người dùng chính cho khía cạnh này im lặng và từ chối phản hồi các câu hỏi của bạn, mặc dù thực tế là người dùng sau đã tích cực tham gia vào tất cả các phiên trước đó. Làm thế nào bạn tháo gỡ được rắc rối này?

A. Bạn xin lỗi, tắt máy tính và về nhà… Mai là một ngày mới.

B. Bạn tiếp tục lặp lại rằng mọi thứ đã được thực hiện theo người dùng chính.

C. Bạn xin lỗi, đồng ý với giám đốc tài chính và hứa sẽ sửa chữa.

D. Bạn nhắc họ về những điều cơ bản bằng cách tham khảo phân tích GAP.

Đáp án: D. Nhắc lại phân tích GAP bằng cách chia sẻ nó trên màn hình của bạn. Bạn xác định rằng thành công của dự án được xác định bởi quyền sở hữu gán trách nhiệm của người dùng chính đối với khía cạnh đó như đã thỏa thuận rõ ràng với tất cả các bên liên quan khi bắt đầu dự án. Bạn sẵn sàng trao đổi với giám đốc tài chính cùng người sử dụng chính để giải quyết những lo lắng của anh ấy trong một phiên họp riêng biệt, lưu ý rằng (nếu được đánh giá phù hợp) nhu cầu sẽ được đưa vào danh sách dự trù của dự án cho các yêu cầu sau bàn giao của mọi người. Việc nâng cấp có thể phù hợp vì một giải pháp thay thế có thể loại bỏ nội dung backlog hiện có để được thay thế bằng các nhu cầu của họ.

Trường hợp thực tế 4

Đối với một cuộc họp về tình trạng dự án, khách hàng đã mời các bên liên quan của từng phòng ban trong số 7 phòng ban. Họ có 10 đại diện trong cuộc họp. Có bao nhiêu nhà lãnh đạo dự án của Odoo nên tham dự cuộc họp này?

A. 1 hoặc 2, nhiều người hơn sẽ gây lãng phí thời gian.

B. 4, để cảm thấy “nghiêm túc” so với 10 do khách hàng đưa ra.

C. 7, một người đại diện cho một bộ phận để tham dự.

D. 10, bằng với số khách hàng.

Đáp án: A. Chúng ta phải tối đa hóa hiệu quả. Nếu bạn có kinh nghiệm quản lý dự án, một người là đủ. Tuy nhiên, nếu bạn mời các nhà phân tích kinh doanh mới đến cuộc họp để họ học hỏi thì sẽ rất tốt. Hoặc, nếu người quản lý dự án không cảm thấy thoải mái về một chủ đề nào đó, anh ta có thể nhờ một chuyên gia giúp đỡ.

Trường hợp thực tế 5

Hãy tưởng tượng tình huống sau:

Trước khi bàn giao, bạn có một cuộc họp với giám đốc điều hành. Bạn đã gặp rất nhiều vấn đề trong suốt dự án, họ không tự tin về giải pháp của bạn nữa và lo lắng về khâu bàn giao. Giám đốc điều hành đang suy nghĩ về việc lùi hạn bàn giao thêm 6 tháng nữa. Họ gặp bạn và nói: “Công ty của tôi không đủ khả năng giải quyết được nhiều vấn đề hơn. Để chấp nhận bàn giao dự án, tôi cần anh cho tôi biết mọi thứ sẽ diễn ra suôn sẻ.”

Câu trả lời của bạn là:

A. Lùi thời hạn thực sự là một ý tưởng tốt để giảm thiểu rủi ro.

B. Đừng lo lắng, mọi thứ đều trong tầm kiểm soát; chúng tôi đã thử nghiệm mọi thứ.

C. Quá trình bàn giao luôn khó khăn, nhưng chúng tôi sẽ nhanh chóng xử lý các vấn đề.

Đáp án: C. Quá trình bàn giao luôn khó khăn: điều tồi tệ sẽ xảy ra, ngay cả khi chúng tôi lùi thời hạn thêm 6 tháng. Đó là điều bình thường. Và tôi cần anh hỗ trợ dự án khi nhóm phàn nàn. Về phía mình, chúng tôi sẽ nhanh chóng xử lý các vấn đề khi chúng tăng lên. Việc lùi thời hạn 6 tháng sẽ làm tăng chi phí của dự án và khiến thành công của dự án gặp rủi ro (rất nhiều thứ có thể thay đổi trong 6 tháng). Bạn nên thành thực và trình bày trước về thử thách phía trước. Nếu giám đốc điều hành thấy bạn biết mình đang làm gì và minh bạch trong cách tiếp cận của bạn, họ sẽ tin tưởng bạn.

7. Đo lường sự tiến bộ của bạn

Dưới đây là những cột mốc mà hầu hết các Người lãnh đạo dự án của Odoo đạt được khi họ thăng tiến trong sự nghiệp của mình. Hãy sử dụng chúng để đánh giá bản thân.
Người mới

Người có kinh nghiệm


Chuyên gia 

Kết quả 

# Điểm/Năm kinh nghiệm @ Odoo

8.  Phương pháp bán hàng 

Tuyển dụng & đào tạo nhân viên bán hàng

Yếu tố thành công quan trọng để bán Odoo là nắm vững bản demo của sản phẩm. Các nhân viên bán hàng mà chúng tôi tuyển dụng có hồ sơ giống với với những người lãnh đạo dự án, ngoại trừ họ sẵn sàng được thúc đẩy bởi các mục tiêu bán hàng.

Đây là lộ trình đào tạo những nhân viên bán hàng mới:

• Tìm hiểu sản phẩm thông qua Giáo dục trực tuyến (eLearning) và Nâng cấp sản phẩm (Scale-Up) (2 tuần)

• Chuẩn bị kiến thức để lấy chứng chỉ

• Huấn luyện hằng tuần để nắm vững bản demo về 3 công việc chung (dịch vụ, sản xuất và một công việc khác)

Bắt đầu với việc nắm vững bản demo chung chung, dần dần họ sẽ có kinh nghiệm. Họ gặp gỡ khách hàng và giới thiệu về bản demo càng nhiều thì họ càng thích nghi với ngành và học được nhiều hơn về các thực hành kinh doanh tốt nhất.

Mục tiêu để phát triển một đội ngũ bán hàng hiệu quả là cung cấp cho họ khả năng thực hành... thật nhiều. Thông thường, những nhân viên bán hàng trực tiếp tại Odoo thực hiện hơn 3 bản demo mỗi tuần. Chúng tôi tin rằng đó là lý do tại sao doanh số của chúng tôi tốt hơn nhiều so với các đối thủ cạnh tranh.

Vì vậy, công ty nên tạo ra bối cảnh để nhân viên bán hàng phát triển mạnh: đảm bảo một lượng lớn các bản demo có triển vọng, tổ chức hội thảo trên web (webinar), sự kiện, v.v…
Kiểm soát việc bán hàng

Trong quá trình mua, thường có nhiều bộ phận trong một tổ chức sẽ quan tâm đến nhiều ứng dụng khác nhau. Điều này có thể trở nên quá tải: các “yêu cầu” kinh doanh sẽ ngày càng chồng chất và khách hàng dễ dàng đánh mất tầm nhìn về những gì họ muốn ngay từ đầu. Nếu điều này xảy ra, bạn đang mất quyền kiểm soát việc bán hàng. Bạn muốn tránh điều này.

Với tư cách là một nhân viên bán hàng, công việc của bạn là:

• Có được bản demo càng sớm càng tốt, ngay cả khi khách hàng không yêu cầu (đây là nơi họ bắt đầu mơ ước: tại sao bạn lại bỏ qua bước này?)

• Hướng dẫn khách hàng tiềm năng của bạn thông qua quá trình mua hàng

• Hiểu những gì khách hàng cần chứ không phải những gì họ muốn: thách thức những gì họ yêu cầu để đơn giản hóa việc bán hàng và giảm ngân sách. Bạn có thể yêu cầu giải thích nếu không hiểu điều gì đó.

• Loại bỏ sự phức tạp không cần thiết và tập trung vào các cơ hội gia tăng giá trị

• Truyền đạt rõ ràng chức năng tiêu chuẩn và đề xuất giá trị

• Quản lý kỳ vọng của khách hàng: đừng hứa quá nhiều

Biến số một có thể gây hại cho việc bán hàng của bạn là sự phức tạp. Bạn phải tránh điều này bằng mọi giá. Bạn sẽ thấy sự phức tạp được thêm vào quá trình mua khi:

• Khách hàng muốn có nhiều hơn thứ bạn có thể cung cấp

• Bạn không hiểu quy trình mua hàng của khách hàng và những ai có liên quan

• Nhân viên bán hàng không đủ điều kiện tất cả các yêu cầu ưu tiên

• Có các yêu cầu phát triển và mong muốn xây dựng các tính năng mới

• Có quá nhiều người kiểm soát việc ra quyết định của khách hàng

Hãy nhớ rằng những người ra quyết định muốn một ngân sách thấp, trong khi những người dùng chính muốn có nhiều tính năng hơn. Mục tiêu của bạn là làm hài lòng những người ra quyết định.

5 điều răn bán hàng

Để đảm bảo có ít tranh cãi nhất có thể, bạn hãy xem xét những điều sau:

• Bán 2 ứng dụng dễ hơn bán 10 ứng dụng. Và việc bán 10 ứng dụng sẽ dễ dàng hơn khi bạn đã bán được 2 ứng dụng. Ý nghĩa ở đây là: khuyến khích khách hàng bắt đầu từ quy mô nhỏ và phát triển lớn lên.

• Kiểm soát quá trình mua: nếu bạn không hiểu cách khách hàng tiềm năng mua phần mềm (ai liên quan, cần cho họ xem gì để thuyết phục họ về giá trị, cách họ nhận thức rủi ro...), thì bạn đang tạo ra điểm mù cho chính mình. Hãy hỏi họ một cách minh bạch.

• Đừng để danh sách yêu cầu “mọc chân và chạy khỏi bạn”. Bạn muốn có thói quen bắt đầu và kết thúc mỗi cuộc gọi bằng một chương trình làm việc; và chương trình đó cần phải liên tục củng cố các yêu cầu chính của khách hàng – hoặc những điều họ cần xem/hiểu để chọn bạn làm giải pháp của họ. Nếu danh sách yêu cầu bị gắn quá nhiều các “yêu cầu” không cần thiết, hãy làm việc với khách hàng để cắt giảm và tập trung lại.

• Luôn cố gắng bán giải pháp vượt trội và làm việc để giảm thiểu các yêu cầu phát triển. Những nhân viên bán hàng thiếu kinh nghiệm ngại thử thách các yêu cầu của khách hàng trong giai đoạn tiền bán hàng. Nhưng khách hàng thường đánh giá cao thực tế là chúng tôi thử thách họ. Càng có nhiều phát triển dễ nhận thấy trong giai đoạn tiền bán hàng của dự án, thì càng về cuối khách hàng càng có nhiều cảm giác không chắc chắn, mà họ sẽ coi đó là rủi ro. Và rủi ro giết chết các giao dịch.

• Cắt giảm số người trong cuộc đánh giá mà bạn trực tiếp thực hiện. Khi có quá nhiều người đưa ra yêu cầu cho bạn và ra lệnh cho chương trình làm việc/yêu cầu, bạn sẽ không thể phân biệt được đâu là ưu tiên và đâu là điều vô nghĩa. Điều này sẽ dẫn đến việc bạn phải nỗ lực rất nhiều nhưng chẳng thấy kết quả gì. Bằng cách cắt giảm số người trong cuộc đánh giá mà bạn trực tiếp thực hiện, bạn sẽ tăng hiệu quả của việc giao tiếp và cuối cùng là khả năng xây dựng một câu chuyện nhất quán về ROI/giá trị.

Khách hàng khác nhau = Cách tiếp cận khác nhau

Dù là dành cho các công ty nhỏ hay tập đoàn, phương pháp của chúng tôi đều giống nhau. Họ chia sẻ cùng tư duy, cùng công cụ, v.v... Nhưng có một số khác biệt.

Khi bán hàng cho các công ty nhỏ, tốt nhất bạn nên khiến khách hàng biết đến sản phẩm càng sớm càng tốt (lý tưởng nhất là trong cuộc gọi đầu tiên). Mục tiêu của bạn là giúp khách hàng hiểu những gì giải pháp tiêu chuẩn cung cấp và cung cấp minh họa về các tính năng chính mà khách hàng đang tìm kiếm. Ngoài ra, nếu khách hàng đang tìm kiếm một số tùy chỉnh nhỏ, đây là cơ hội tuyệt vời để bạn thể hiện sức mạnh của Odoo Studio. Bạn học cách trưng bày giới thiệu sản phẩm và thảo luận về ROI càng sớm thì bạn càng bán được nhiều dự án khởi động nhanh. Đơn giản là như vậy.

Khi tham gia vào các dự án lớn, những ý tưởng đều giống nhau (demo càng sớm càng tốt, giữ mọi thứ đơn giản), nhưng các bước khác nhau:

• Đầu tiên, khách hàng phải muốn Odoo, như một sản phẩm (RFI, demo,...)

• Chỉ tại thời điểm đó, bạn có thể bán phân tích ROI

• Sau đó, bạn bán toàn bộ dự án triển khai

Các dự án lớn yêu cầu nhiều phân tích tiền bán hàng hơn. Khi bán các dự án lớn hơn, đó là việc bán bản thân như một đối tác kinh doanh sẽ mang lại giá trị cho bảng – bạn không còn chỉ bán một sản phẩm hay một chuyên môn đặc biệt nữa. Bạn cũng phải đưa phần mềm đến trước mặt khách hàng càng sớm càng tốt để giúp bối cảnh hóa các cuộc trao đổi (đây là một điểm khác biệt tuyệt vời, không nhiều nhà cung cấp phần mềm khác sẵn sàng đưa ra demo sản phẩm của họ vào ngày đầu tiên đánh giá).

Điểm tạo sự khác biệt cạnh tranh của Odoo

Điều quan trọng là bạn phải tạo ra khác biệt so với đối thủ một cách thành công. Điểm khác biệt số một mà bạn có tại Odoo là tính minh bạch và bằng cách tận dụng điều này, bạn có thể phân biệt mình với đối thủ cạnh tranh. Odoo minh bạch duy nhất về những điều sau:

• Định giá

• Sản phẩm/chức năng (bản demo dùng 14 ngày miễn phí)

• Phương pháp 

• Những thách thức và ràng buộc liên quan đến việc triển khai

• Điều khoản pháp lý

Có bao nhiêu công ty khác có thể nói điều tương tự?

Bạn càng trung thực với khách hàng từ trước thì cơ hội giành được đơn đặt hàng của họ càng lớn. Mặc dù ban đầu điều này có vẻ phản trực giác, nhưng điều quan trọng là bạn phải nhận ra sự minh bạch hoàn toàn sẽ là yếu tố tạo sự khác biệt mạnh mẽ nhất của bạn khi nói đến việc phân biệt mình với đối thủ và chốt đơn hàng mới.

Định giá của Odoo

Việc đăng ký của Odoo tốn chi phí thấp hơn khoảng 7 lần so với mức giá công khai của đối thủ cạnh tranh. Mức giá này vừa tuyệt vời vừa rủi ro: khách hàng có thể nghĩ rằng chúng tôi là một sản phẩm “rẻ tiền”.

Khi thảo luận về giá của Odoo, đừng bao giờ sử dụng từ “rẻ”, hàm ý chất lượng thấp hoặc giá trị thấp. Bạn nên luôn mô tả nó là “không tốn kém”. Không tốn kém ngụ ý rằng chi phí là rất ít so với giá trị bạn nhận được – đó chính xác là những gì chúng ta đang có. 

9.  Tài liệu tham khảo thêm 

Tham khảo thêm

• Bài viết “Stick to standard” (Bám sát tiêu chuẩn) trên Blog Odoo: https://www.odoo.com/r/blog_implementation

• Bài viết “The key to Implementation Projects: Manage Customers Expectations.” (Chìa khóa cho các dự án triển khai: Quản lý kỳ vọng của khách hàng) trên blog Odoo: https://www.odoo.com/r/blog_implementation

Phụ lục

Phụ lục A: ROI – Khởi động dự án

Sử dụng XMind để ghi chú trong cuộc họp ROI – Khởi động dự án với SPoC và những người ra quyết định. Với mẫu này, hãy bắt đầu từ phần “Giới thiệu” nằm trên cùng bên phải và di chuyển theo chiều kim đồng hồ trong cuộc phỏng vấn (các nút bên trái dành cho ghi chú được viết trong các cuộc thảo luận).

Mẫu ROI – Khởi động dự án

Phụ lục B: ROI – Phỏng vấn những người dùng chính

Sử dụng XMind để ghi chú trong các cuộc họp với những người dùng chính. Với mẫu này, hãy bắt đầu từ phần “Mọi người” nằm trên cùng bên phải và di chuyển theo chiều kim đồng hồ trong cuộc phỏng vấn (các nút bên trái dành cho ghi chú được viết trong các cuộc thảo luận).

Tải xuống mẫu: ROI – Phỏng vấn những người dùng chính:

https://www.odoo.com/r/roi_key_user_intw

Mẫu ROI – Phỏng vấn những người dùng chính

Phân tích ROI – Doanh thu của bộ phận

Mẫu Phân tích ROI – Mục đầu tư

Phụ lục D: ROI – Bản thuyết trình kết thúc

Sử dụng Google Presentation (hiện được đổi tên thành Google Slides) để ghi lại phân tích ROI của bạn. Liên kết tất cả các biểu đồ và bảng của bạn với Công cụ phân tích GAP để cập nhật thông tin tự động.

Khi gửi kết quả phân tích cho khách hàng, bạn phải cung cấp cái nhìn tổng quan rõ ràng và mạch lạc về dự án sắp tới cho những người ra quyết định.

Tải xuống mẫu: Bản thuyết trình kết thúc GAP:

https://www.odoo.com/r/gap_closing 

Phụ lục E: Ví dụ về Báo cáo tiến độ

Một ví dụ điển hình về báo cáo tiến độ:

https://www.odoo.com/r/progress_report

Phụ lục F: Quản lý thay đổi Odoo

Nhận thêm thông tin chi tiết về cách tiếp cận của chúng tôi:

https://www.odoo.com/r/change_management

Phụ lục G: Ví dụ về thông số kỹ thuật

Cách viết một thông số kỹ thuật tốt:

https://www.odoo.com/r/Spec_example