Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
Trong dự án ERP bạn không lấy tính năng mà lấy quy trình và quy tắc. Bốn bước chuẩn bị, cách chạy buổi khảo sát, và bốn lý do khiến khảo sát bị kéo dài.
Vào một buổi khảo sát, và bạn nhận ra mình đang ngồi nghe hai người phía khách tranh luận với nhau về việc đơn hàng của đại lý thì ai được duyệt. Họ tranh luận mười phút, không ai chốt được, và cuối cùng nói để em hỏi lại sếp.
Đây là hình dạng điển hình của một giai đoạn khảo sát ERP bị kéo dài, và nguyên nhân gần như không bao giờ nằm ở chỗ bạn hỏi thiếu. Nó nằm ở chỗ buổi khảo sát đang được chạy theo cách của một dự án phần mềm viết mới, trong khi việc lấy yêu cầu dự án ERP là một công việc khác về bản chất.
Trong dự án viết mới, cái gì bạn không lấy được thì không tồn tại, nên nhiệm vụ của buổi khảo sát là thu thập càng đầy đủ càng tốt. Trong dự án ERP thì hệ thống đã tồn tại, và nhiệm vụ đổi thành đối chiếu.
Cụ thể hơn: bạn không lấy danh sách tính năng, bạn lấy hai thứ.
Hai thứ đó mới là cái bạn đem đi đối chiếu với hệ thống. Tính năng thì bạn tự tra được, còn quy tắc thì chỉ người trong doanh nghiệp mới biết, và họ chỉ nói ra khi bạn hỏi đúng.
Cần lưu ý rằng quy tắc là phần khó lấy nhất, vì nó thường không nằm ở đâu cả. Nó nằm trong đầu vài người, được truyền miệng, và có những ngoại lệ mà chính họ cũng không nhớ hết cho tới khi gặp lại. Do đó khi khách nói một quy tắc, việc tiếp theo của bạn không phải ghi lại mà là hỏi trường hợp nào thì quy tắc đó không áp dụng.
Đây là đòn bẩy lớn nhất để rút ngắn thời gian khảo sát, và nó đơn giản tới mức nhiều người bỏ qua: chỉ khai thác sâu vào phần sẽ được quản lý trên hệ thống.
Ví dụ nghiệp vụ nhân viên kinh doanh tư vấn khách hàng, và nếu hệ thống không quản lý phần tư vấn thì bạn không cần biết họ tư vấn thế nào, nói những gì, thuyết phục ra sao; bạn chỉ cần biết sau khi chốt với khách thì họ ghi nhận thông tin gì lên hệ thống và theo quy tắc nào. Một câu hỏi thay cho hai mươi phút.
Ngược lại, có những chỗ tưởng nhỏ mà phải đào rất sâu, ví dụ quy tắc áp giá, bởi trên giấy nó chỉ là một dòng, nhưng thực tế thường có bảng giá theo nhóm khách, giá theo số lượng, giá theo thời điểm khuyến mãi, giá riêng cho vài khách lớn được duyệt bằng miệng, và thứ tự ưu tiên giữa chúng thì mỗi người trong phòng nói một kiểu.
Nguyên tắc phân biệt: đào sâu vào chỗ nào tạo ra dữ liệu hoặc chi phối dữ liệu, đi lướt qua chỗ nào chỉ là thao tác của con người.
Cụ thể hơn nữa, chỗ đáng đào là chỗ sinh ra bản ghi. Khi khảo sát bán hàng thì câu hỏi đáng tiền không phải nhân viên chốt đơn với khách thế nào, mà là giá được lấy từ đâu khi cùng một sản phẩm có bảng giá theo nhóm khách và bảng giá theo số lượng, ai được sửa giá sau khi đơn đã xác nhận, và hàng giao thiếu thì phần còn lại nằm ở đâu. Ba câu đó ánh xạ thẳng sang bảng giá, sang phân quyền trên đơn bán hàng, và sang phiếu giao hàng, nghĩa là bạn vừa khảo sát vừa biết mình sẽ đối chiếu vào đúng chỗ nào của hệ thống. Đó chính là khác biệt giữa một buổi khảo sát ERP và một buổi thu thập yêu cầu thông thường.
Chất lượng buổi khảo sát được quyết định trước khi buổi đó bắt đầu, và cụ thể là bốn việc dưới đây.
Đầu tiên, nắm sơ đồ tổ chức của doanh nghiệp, có những phòng ban nào, mỗi phòng làm gì, mỗi vị trí phụ trách công việc gì, và công việc đó liên quan tới phân hệ nào. Không có bức tranh này thì bạn book nhầm người, và phát hiện ra khi buổi họp đã đi được nửa tiếng.
Tiếp theo, xin trước quy trình có sẵn của doanh nghiệp nếu họ có, dù nó được vẽ bằng Excel hay bằng bất cứ công cụ gì. Cái này tiết kiệm rất nhiều thời gian, bởi những gì đã có sẵn thì bạn chỉ cần hỏi xác nhận đúng hay sai chứ không phải hỏi lại từ đầu, và bạn cũng hình dung trước được nghiệp vụ để sắp xếp câu hỏi cho hợp lý.
Sau đó, xác định danh sách vị trí và người tham gia theo từng quy trình, dựa trên sơ đồ tổ chức vừa nắm.
Và cuối cùng, chuẩn bị bộ câu hỏi rồi gửi trước cho khách. Đây là việc đổi nhiều thứ nhất trong bốn việc, và lý do thật sự của nó thì tôi đã nói riêng ở bài về bộ câu hỏi khảo sát; ở đây chỉ cần nhớ rằng không gửi trước thì buổi khảo sát biến thành buổi lập danh sách câu hỏi.
Bộ câu hỏi khảo sát chia theo quy trình chứ không theo phân hệ. Cộng thêm ba nhóm mà phần lớn bộ câu hỏi khảo sát không có:
Ba nhóm này hay bị bỏ vì chúng không ánh xạ thẳng vào một module, mà thực tế lại là chỗ sinh ra nhiều GAP nhất.
Trong phần lớn các nhóm nghiệp vụ thì ba câu đầu giống nhau:
Ba câu đó cho bạn quy trình, pain point và actor, đủ để dựng khung trước khi đi vào chi tiết. Nội dung cụ thể của từng nhóm câu hỏi, và những câu mà chỉ cần đổi câu trả lời là đổi luôn khối lượng dự án, là một chủ đề riêng.
Mở đầu bằng việc nêu lại mục tiêu và nội dung chính của buổi, vì đây chính là công cụ bạn dùng về sau khi khách nói lệch chủ đề; cách xử lý các tình huống phát sinh trong phòng họp thì tôi để ở bài riêng về chạy một buổi khảo sát.
Sau đó đi hết bộ câu hỏi, không phải bằng cách đọc lần lượt từ trên xuống mà bằng cách bám theo mạch kể của khách rồi đánh dấu ngược lại vào danh sách để kiểm soát độ phủ. Trong lúc đi, sẽ có những chỗ rẽ nhánh sâu vào một tình huống nào đó, và điều này bình thường nhưng phải nhớ quay lại đúng chỗ vừa rẽ để đi tiếp, vì bỏ sót thường xảy ra ở đây chứ không phải ở chỗ bạn quên hỏi.
Đặc biệt, đừng ngồi chờ khách chốt quy tắc tại chỗ. Khi một quy tắc chưa được xác minh và nội bộ họ bắt đầu bàn với nhau, hãy đề nghị họ thống nhất sau buổi rồi gửi lại, ghi vào danh sách cần cung cấp, và tiếp tục buổi khảo sát. Nếu không thì thời gian của cả buổi bị nuốt bởi một cuộc họp nội bộ mà bạn không tham gia được.
Về nhân sự thì cần tối thiểu hai người phía đội triển khai, và nên xin phép ghi âm buổi họp, vì tới lúc viết tài liệu bạn sẽ cần nghe lại đúng câu khách nói chứ không phải bản tóm tắt. Cách chia vai trong phòng họp và cách xử lý các tình huống phát sinh thì tôi để ở bài riêng về chạy một buổi khảo sát.
Bốn việc, và việc đầu tiên nên làm ngay trước khi mọi người rời phòng.
Review lại nội dung ngay cuối buổi, mà chính xác hơn là review sau mỗi quy trình chứ không phải dồn tới cuối. Bạn đi lại từ đầu tới cuối quy trình vừa khảo sát, đọc ra ai làm bước nào và quy tắc là gì, cho tới khi người tham gia xác nhận đúng thì mới đi tiếp phần sau. Chốt ngay tại chỗ thì chi phí dự án sẽ giảm hơn rất nhiều so với chốt lại qua email ba ngày sau.
Tiếp theo, gửi email nội dung khảo sát cho người tham gia, quản lý cấp trên và ban dự án hai bên, đồng thời đặt thời hạn phản hồi. Không có thời hạn thì biên bản của bạn nằm im trong hộp thư của họ cho tới đúng lúc bạn cần nó làm căn cứ, và lúc đó thì đã quá muộn để hỏi lại.
Sau đó theo dõi và thu thập những biểu mẫu, chứng từ, mẫu báo cáo và quy tắc mà khách đã hứa gửi lại. Danh sách này bạn đã ghi trong buổi, giờ chỉ việc bám.
Cuối cùng là sơ đồ hóa quy trình, và phải vẽ hai bộ: quy trình hiện tại, và quy trình sau khi lên hệ thống. Bộ thứ hai mới là bộ được xây, nhưng không có bộ thứ nhất thì bạn không chứng minh được với khách rằng mình đã hiểu đúng cách họ đang làm.
Trước khi đem yêu cầu đi đối chiếu thì phân loại đã, và ba loại đầu thì giáo trình nào cũng có: yêu cầu ở cấp doanh nghiệp, yêu cầu của các bên liên quan, và yêu cầu giải pháp gồm phần chức năng lẫn phần phi chức năng.
Loại thứ tư mới là loại hay làm hỏng kế hoạch, đó là yêu cầu chuyển đổi. Nó chỉ tồn tại trong lúc chuyển từ hệ thống cũ sang hệ thống mới rồi biến mất — số dư đầu kỳ, danh mục khách hàng và sản phẩm đang nằm trên Excel, tồn kho tại thời điểm cắt — và tất cả phải xong trước ngày go-live.
Danh sách này phải được lập ngay từ buổi khảo sát chứ không phải để tới lúc chuẩn bị go-live, bởi nó quyết định khối lượng của cả một giai đoạn mà không ai nhìn thấy trong tài liệu GAP. Bỏ quên nó thì tới tuần cuối bạn phát hiện có một khối công việc chưa ai lên kế hoạch, và nó rơi đúng vào lúc không còn thời gian để làm.
Câu chuyện điển hình mà tôi hay nghe kể lại là thế này: một dự án nội bộ, họp một phòng ban suốt hai tuần với mỗi ngày hai tiếng, tài liệu ra tới mấy trăm trang, mà vẫn chưa chốt được gì.
Cách chẩn đoán dưới đây tôi học được từ một quản lý dự án lâu năm ở công ty triển khai, và từ đó tới giờ vẫn dùng. Có bốn nguyên nhân, trong đó ba nguyên nhân chữa được.
Nguyên nhân thứ nhất là thiếu giai đoạn tìm hiểu ở tầng trước dự án. Khi làm cho khách bên ngoài, đội sale đã tiếp xúc, đã hiểu doanh nghiệp đang vướng gì, nên tới lúc bạn xuống khảo sát thì đã có sẵn một mớ dữ liệu về khách và bạn đi rất nhanh. Còn dự án nội bộ thì không ai làm phần đó hộ bạn, nên bạn phải tự làm ở đầu — nếu không thì buổi khảo sát vừa phải tìm hiểu vừa phải lấy chi tiết cùng lúc.
Nguyên nhân thứ hai là không gửi bộ câu hỏi trước và không phân tích trước trên file khách đã điền. Việc này đã nói ở phần chuẩn bị, và nó là nguyên nhân dễ chữa nhất.
Nguyên nhân thứ ba là mời quá nhiều người cho cùng một vị trí. Mỗi vai trò chỉ nên mời một người — một nhân viên, một trưởng nhóm, một quản lý — bởi mời nhiều là mỗi người mỗi ý, và buổi khảo sát của bạn biến thành cuộc thảo luận nội bộ của khách về những chuyện họ chưa thống nhất được với nhau.
Nguyên nhân thứ tư thì không chữa được bằng phương pháp: cả đội đều mới với sản phẩm và mới với lĩnh vực của khách. Trường hợp này phải chấp nhận là sẽ chậm hơn, và cách duy nhất là làm nhiều rồi có kinh nghiệm.
Đi kèm bốn nguyên nhân đó là một lời khuyên mà tôi nghĩ quan trọng hơn cả bốn: đừng cầu toàn.
Kiểu gì user cũng thay đổi. Với dự án không có phạm vi rõ ràng, đặc biệt là dự án nội bộ, cứ làm nhanh nhất có thể rồi điều chỉnh sau, còn nếu bạn cố khảo sát cho hết mọi thứ thì bạn sẽ ở mãi trong giai đoạn này.
Bảy việc này mất chừng một hai ngày cho một dự án cỡ vừa, và nó là khoản đầu tư có tỷ suất cao nhất trong toàn bộ giai đoạn phân tích.
Còn một kỹ năng nữa quyết định chất lượng của mọi buổi khảo sát, và nó không nằm trong bộ câu hỏi nào: biết lúc nào phải dừng lại và hỏi tại sao.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận