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.
