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à:
Giai đoạn | Thời gian | Mục tiêu |
Phân tích ROI | 10% | Phân tích ROI, phân giai đoạn và xác định ngân sách. |
Khởi động dự án | 5% | Thỏa thuận với các bên liên quan về phương pháp + đào tạo tiêu chuẩn. |
Triển khai | 80% | Chuỗi các chu kỳ: phân tích, phát triển, đánh giá, đào tạo người dùng chính. |
Bàn giao | 5% | Đào tạo người dùng cuối, sửa lỗi. |
Lượt triển khai thứ hai | Chưa xác định | Mở rộng phạm vi hoặc thêm các tính năng tùy chỉnh. |
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
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.
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.
