Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Bảy sai lầm hay gặp của BA ERP mới vào nghề, kể theo dấu hiệu nhận ra sớm và việc phải làm ngay lúc phát hiện, thay vì kể theo lý thuyết.
Có một cách hiểu rất phổ biến về chuyện BA mới vào nghề hay mắc lỗi trong dự án ERP, rằng đó là do thiếu kiến thức và học thêm chút nữa là hết.
Thử hình dung một buổi khảo sát phòng mua hàng ở một doanh nghiệp cơ khí khoảng một trăm năm mươi nhân sự. Buổi đó kết thúc lúc bốn giờ chiều, và bạn rời đi với cảm giác khá tốt: một bản ghi âm chín mươi phút, một biên bản bốn trang gõ gần như kịp từng câu người ta nói. Không có kiến thức nào bạn thiếu ở đây cả, bạn biết cách khảo sát và bạn ghi chép cẩn thận hơn phần lớn người mới khác.
Sáng hôm sau, người quản lý dự án hỏi đúng một câu, rằng quy trình mua hàng của họ rẽ nhánh ở chỗ nào và ai là người quyết ở mỗi nhánh. Bạn mở lại bốn trang biên bản và không tìm ra câu trả lời, dù từng chữ trong đó đều là chữ khách đã nói.
Đó là hình dạng thật của sai lầm đầu tiên trong bài này, và nó có chung một đặc điểm với sáu sai lầm còn lại: lúc đang xảy ra, nó trông y hệt như đang làm việc chăm chỉ. Vì vậy tôi không giải thích lại khái niệm mà kể mỗi sai lầm bằng ba thứ dùng được ngay, gồm:
Cần nói trước một giới hạn: tôi không có số liệu về tần suất của từng sai lầm, nên đừng đọc thứ tự trong bài như thứ tự phổ biến.
Dấu hiệu nằm ngay trong biên bản của bạn.
Hãy đọc lại và đếm xem có bao nhiêu dòng mô tả một sự việc đã thật sự xảy ra, kiểu như tháng trước có hai đơn bị giao nhầm địa chỉ vì hai người cùng sửa một phiếu, và bao nhiêu dòng chỉ là mong muốn mở đầu bằng cụm bên em muốn. Nếu nhóm thứ nhất bằng không thì bạn mới chỉ chép chứ chưa khảo sát.
Dấu hiệu thứ hai tinh vi hơn, đó là cảm giác yên tâm vì đã có bản ghi âm, trong khi bản ghi âm chỉ là tư liệu để tra lại; nó không tự thành yêu cầu, và cũng không chỉ ra chỗ nào người ta đang mô tả thói quen chứ không phải quy định của doanh nghiệp.
Sai lầm này lộ ra ở bước sơ đồ hóa quy trình, khi bạn ngồi vẽ mà không vẽ nổi nhánh rẽ, hoặc muộn hơn là lúc đội phát triển hỏi điều kiện nào thì đi nhánh nào. Việc phải làm ngay là đặt lịch hỏi lại trong vòng hai ngày, lúc người tham gia còn nhớ buổi họp, và mang theo đúng những dòng bạn không đếm được. Vì sao câu hỏi tại sao lại đáng giá tới vậy thì tôi đã viết thành một bài riêng.
Sai lầm này có hai dấu hiệu dễ nhận.
Dấu hiệu thứ nhất là buổi khảo sát tràn sang phần nghiệp vụ mà cả hai bên đều biết sẽ không đưa lên hệ thống, chẳng hạn cách nhân viên thương lượng với nhà cung cấp qua điện thoại. Dấu hiệu thứ hai là lịch khảo sát trượt sang tuần sau trong khi danh sách quy trình còn lại không ngắn đi.
Người mới mắc lỗi này vì sợ thiếu hơn sợ thừa, mà hỏi thêm thì chẳng ai trách, nên chi phí của việc hỏi thừa bị giấu đi và chỉ hiện ra ở chỗ khác.
Một quản lý dự án lâu năm ở công ty triển khai mà tôi có dịp học hỏi nói thẳng rằng khảo sát rộng quá chính là nguyên nhân số một khiến giai đoạn khảo sát kéo dài, và phần kéo dài đó ăn thẳng vào thời gian của bước phân tích phía sau.
Việc phải làm ngay là gắn một câu hỏi lọc vào mỗi đoạn nghiệp vụ đang nghe, rằng thông tin này sẽ hiện ra ở màn hình nào, do ai nhập và ai đọc lại nó; nếu không ai trả lời được thì bạn chỉ lấy đầu ra của đoạn đó rồi đi tiếp.
Trong trường hợp nội bộ khách tranh luận để chốt một quy tắc ngay giữa buổi, cách tôi vẫn làm là đề nghị họ họp riêng rồi chốt sau, đồng thời nhắc thư ký ghi lại để không sót. Cũng người quản lý dự án đó còn nhắc rằng kiểu gì user cũng thay đổi, nên với dự án nội bộ không có phạm vi rõ ràng thì làm nhanh rồi điều chỉnh còn hơn cố hoàn hảo từ đầu.
Dấu hiệu ở đây nằm trong tốc độ.
Bạn điền cột kết luận của bảng đối chiếu rất nhanh, và trong đầu bạn xuất hiện chữ chắc là, mà nguồn của cái chắc là đó thường chỉ là một video hướng dẫn, một buổi đào tạo, hoặc một dự án trước có cấu hình khác hẳn. Dấu hiệu thứ hai là bạn kết luận đáp ứng dựa trên việc nhìn thấy tên một menu, chứ chưa từng tạo một chứng từ thật để xem hệ thống chặn hay không chặn.
Sai lầm này lộ ra muộn và đắt, thường là ở buổi demo giải pháp, hoặc tệ hơn là ở buổi nghiệm thu khi khối lượng đã chốt vào báo giá. Việc phải làm ngay là dựng một database sạch, tạo đúng chứng từ trong tình huống bạn vừa kết luận, rồi chụp màn hình dán vào tài liệu kèm một dòng ghi rõ phiên bản.
Cũng phải nói thẳng rằng ghi chép của tôi, kể cả những gì tôi viết trong loạt bài này trên Odoo 19, đều có thể lệch so với phiên bản khách đang chạy, nên hệ thống thật của dự án luôn là nguồn cuối cùng.
Dấu hiệu xuất hiện ngay trong lúc bạn đang nói, và nó nghe rất bình thường.
Bạn nghe chính mình trả lời rằng cái này hệ thống có sẵn, cho một thứ mà bạn mới chỉ nhìn thấy tên menu. Một biến thể khác là khách hỏi lại kiểu vậy là làm được đúng không em, và bạn gật đầu cho buổi họp trôi đi.
Người mới hay mắc vì cả phòng đang chờ một câu khẳng định. Cần nhớ rằng lời hứa trong buổi demo không dừng lại ở buổi demo: nó được thư ký của khách ghi vào biên bản, được đội sale dùng làm căn cứ chốt phạm vi, và tới lúc bạn phát hiện mình sai thì việc rút lại đã không còn là chuyện chuyên môn nữa mà là chuyện thương lượng.
Việc phải làm ngay gồm hai phần. Việc thứ nhất là chuẩn bị sẵn một câu để dùng lại nhiều lần, đại ý rằng chỗ này em ghi nhận, chiều nay em kiểm trên hệ thống rồi trả lời anh bằng mail, bởi một câu trả lời chậm nửa ngày rẻ hơn nhiều so với một cam kết sai.
Việc thứ hai là mô phỏng trọn buổi demo trên chính hệ thống demo vừa dựng, kể cả khi bạn tự tin nhớ hết, vì lỗi tìm ra trong lần chạy thử phần lớn là lỗi cấu hình vụn vặt mà bạn không kịp xử lý khi có khách ngồi bên cạnh. Lý do đầy đủ của bước chạy thử này và cách chốt giải pháp ngay trong buổi demo thì đã có bài riêng.
Dấu hiệu đầu tiên của sai lầm này cũng là dấu hiệu dễ hiểu nhầm nhất.
Bạn gửi tài liệu đi và ba ngày sau không ai hỏi gì; người mới đọc im lặng đó là đồng ý, trong khi phần lớn trường hợp nó nghĩa là không ai đọc nổi.
Dấu hiệu thứ hai chắc chắn hơn: đội phát triển nhắn hỏi lại đúng ba câu mà bạn nghĩ mình đã viết rõ, và khi mở tài liệu ra thì đúng là có viết, chỉ là viết theo cách chỉ người dự buổi khảo sát mới hiểu. Dấu hiệu thứ ba là trong tài liệu có những từ nội bộ của doanh nghiệp, kiểu hàng gửi bán hay phiếu tạm, mà không chỗ nào giải nghĩa.
Việc phải làm ngay là một phép thử rẻ tiền: đưa tài liệu cho một người trong đội không dự buổi khảo sát, nhờ họ đọc rồi kể lại quy trình bằng lời, và chỗ họ vấp chính là chỗ bạn phải viết lại.
Cần lưu ý rằng viết lại không có nghĩa là viết dài thêm, bởi số lượng và độ chi tiết của tài liệu do hợp đồng quyết định, và chuyện đó đã có bài riêng. Nói cho công bằng thì tài liệu vẫn là thứ yếu, cái hệ thống mà khách dùng được mới là chính.
Dấu hiệu này kiểm được trong năm phút.
Mở tài liệu yêu cầu ra, chọn ngẫu nhiên ba dòng, rồi thử tìm với mỗi dòng một cái tên và một ngày xác nhận; nếu không tìm thấy thì bạn đang cầm một tài liệu đầy thông tin mà không ai chịu trách nhiệm. Dấu hiệu thứ hai là mọi buổi khảo sát của bạn đều chỉ có nhân viên tác nghiệp, không lần nào có người đủ thẩm quyền ngồi cùng, kể cả một quãng ngắn cuối buổi.
Sai lầm này lộ ra ở hai chỗ. Chỗ thứ nhất là khi hai phòng trả lời khác nhau về cùng một quy tắc, ví dụ khách đang nợ quá hạn thì có được nhận đơn tiếp hay không, kho nói một kiểu còn kế toán nói một kiểu, và không ai trong hai bên có quyền chốt. Chỗ thứ hai nặng hơn, đó là buổi nghiệm thu, khi người ký nhìn vào một luồng đã dựng xong và nói rằng bên tôi không làm như vậy.
Việc phải làm ngay sau mỗi buổi là ghi rõ trong biên bản đúng những điểm cần người có thẩm quyền xác nhận, chứ không chỉ ghi lại nội dung đã nói. Cách gửi biên bản và cách đặt thời hạn xác nhận thì tôi đã viết trong bài về buổi requirement workshop.
Dấu hiệu rất cụ thể và ai cũng kiểm được.
Mở bảng liệt kê các đối tượng dữ liệu của dự án, nhìn cột người phụ trách phía khách và đếm số dòng còn trống; nếu dự án đã đi nửa chặng mà những dòng như nhà cung cấp hay đơn vị tính vẫn chưa có tên ai thì phần dữ liệu đang trôi. Dấu hiệu thứ hai là câu nói quen thuộc trong họp, rằng cái đó cuối dự án làm cũng được.
Người mới mắc lỗi này vì dữ liệu không chặn ai trong lúc dự án đang chạy. Tuy nhiên, một quản lý dự án lâu năm ở công ty triển khai nhận xét rằng sai dữ liệu đáng sợ hơn sai lỗi phần mềm, bởi lỗi thì sửa rồi thôi, còn dữ liệu sai đã đi vào giao dịch thì kéo theo cả chuỗi chứng từ phía sau.
Trên Odoo 19, một sản phẩm đã nằm trên đơn bán thì không xóa được nữa, kể cả khi đơn đó mới chỉ là đơn nháp chưa ai xác nhận; hệ thống chặn thao tác xóa và gợi ý bạn lưu trữ nó, nên một mã sản phẩm tạo sai từ đầu sẽ ở lại trong hệ thống cùng mọi chứng từ đang giữ nó.
Phần này lộ ra vào khoảng hai tuần trước ngày chạy thật, đúng lúc mọi người bận nhất và thứ bạn cần lại chỉ khách mới có. Việc phải làm ngay trong buổi họp tuần này là mở lại bảng đối tượng dữ liệu, mỗi dòng ghi một tên người bên khách và một ngày cam kết, rồi đưa bảng đó vào biên bản họp thay vì giữ trong máy mình. Cách tổ chức phần chuyển dữ liệu đi theo từng đối tượng đã có bài riêng.
Bảy sai lầm ở trên đều có thể tự phát hiện mà không cần ai review giúp, và bốn thao tác dưới đây phủ được phần lớn trong số đó:
Nếu cả bốn đều cho kết quả xấu thì cái phải sửa là thói quen làm việc chứ chưa phải sản phẩm bàn giao, nên vài ngày là đủ. Đồng thời cũng nên nhớ rằng bảy sai lầm này không đến từ việc thiếu kiến thức, chúng đến từ việc chọn phương án nhanh hơn ở đúng những chỗ sẽ tính lãi về sau.
Còn một sai lầm nữa tôi cố tình không xếp vào danh sách trên, đó là nhận mọi việc được nhờ cho tới lúc không còn thời gian làm việc của mình, bởi nó là hệ quả của việc chưa biết ranh giới trách nhiệm của BA trong dự án nằm ở đâu, và đó là chủ đề của bài tiếp theo.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận