Bạn vẫn xem được các bài đã đăng mà không cần đăng nhập.
BA phần mềm định nghĩa cái sẽ được xây. BA ERP đối chiếu cái khách cần với cái hệ thống đã có. Khác biệt đó đổi gần như mọi thứ trong công việc.
Có một tình huống mà gần như ai chuyển từ BA domain khác sang BA ERP cũng đi qua.
Bạn đã làm BA được vài năm, quen với việc ngồi xuống cùng khách hàng, hỏi họ muốn hệ thống làm được gì, ghi lại, về viết thành tài liệu rồi chuyển cho đội phát triển; quy trình đó bạn chạy thuần thục tới mức không cần nghĩ. Rồi bạn nhận dự án Odoo ERP đầu tiên, ngồi buổi khảo sát đầu tiên, và hỏi đúng câu hỏi quen thuộc đó: anh chị muốn hệ thống làm được những gì.
Khách hàng trả lời, bạn ghi được một danh sách dài, về nhà viết thành tài liệu, mô tả cẩn thận từng chức năng, từng màn hình, từng trường thông tin, mất khoảng một tuần. Sau đó bạn mở hệ thống lên và phát hiện phần lớn những thứ vừa viết đã nằm sẵn ở đó rồi.
Đó là lúc bạn nhận ra nghề này khác. Không khác ở kỹ năng, mà khác ở hướng của công việc.
Nói cho gọn thì thế này: BA domain khác định nghĩa cái sẽ được xây, còn BA ERP đối chiếu cái khách cần với cái hệ thống đã có sẵn.
Trong một dự án phần mềm viết mới, cái gì bạn không mô tả thì không tồn tại, do đó bạn là người quyết định hệ thống có màn hình nào, có trường nào, bấm nút này thì chuyện gì xảy ra; tài liệu của bạn là bản thiết kế và đội phát triển sẽ xây theo đúng bản thiết kế đó. Vì vậy kỹ năng quan trọng nhất là mô tả đầy đủ và không mâu thuẫn.
Trong một dự án ERP thì hệ thống đã tồn tại trước khi bạn tới. Odoo ERP đã có sẵn quy trình bán hàng, quy trình mua hàng, quy trình kho,... đó là bản chuẩn hóa mà phần lớn doanh nghiệp vận hành, chứ không phải bản thiết kế riêng cho khách của bạn, GAP sinh ra từ đó. Cho nên khi khách hàng nói họ muốn quản lý đơn hàng, câu hỏi không còn là màn hình đơn hàng nên có gì, vì màn hình đó đã có rồi; câu hỏi là cái đã có có chạy được nghiệp vụ của họ không, và nếu không thì lệch ở chỗ nào.
Nghe thì có vẻ nhẹ hơn, nhưng thực tế nó nặng hơn, vì bạn phải biết cả hai đầu: nghiệp vụ của khách, và hệ thống bạn đang cầm trong tay.
Công việc chiếm nhiều thời gian nhất của BA ERP không phải viết requirement, mà là fit-gap, tách yêu cầu lớn của khách thành những yêu cầu nhỏ, rồi với mỗi yêu cầu nhỏ trả lời một câu duy nhất: hệ thống đáp ứng hoàn toàn, đáp ứng một phần, hay hoàn toàn không có.
Ba câu trả lời đó dẫn tới ba loại việc hoàn toàn khác nhau. Đáp ứng hoàn toàn thì chỉ cần cấu hình rồi hướng dẫn user dùng. Đáp ứng một phần thì phải xác định bổ sung cái gì, và bổ sung bằng cấu hình hay bằng code. Không đáp ứng thì phải thiết kế giải pháp mới từ đầu.
Tuy nhiên, cần lưu ý rằng ba mức đó không phải lúc nào cũng gọn gàng như vậy. Trong trường hợp tính năng đáp ứng được yêu cầu nhưng lại chỉ có ở bản Enterprise trong khi khách đang cân nhắc bản Community, thì "đáp ứng hoàn toàn" của bạn thực chất là một khoản license mà đội sale chưa báo giá, và bạn phải quay lại đánh giá từ đầu với ràng buộc mới. Đây là loại tình huống mà kinh nghiệm viết requirement không giúp được gì.
Đặc biệt, đây cũng là chỗ dễ sai nhất và tốn tiền nhất. Đánh "đáp ứng" cho một thứ thực ra không dùng được thì tới lúc triển khai bạn phải làm thêm mà không có ngân sách; ngược lại, đánh "không đáp ứng" cho một thứ thực ra chỉ cần cấu hình thì bạn đã đội giá báo cho khách lên vô lý và có thể mất dự án ngay từ vòng báo giá.
Để trả lời được ba mức đó, bạn buộc phải đọc được hệ thống từ bên trong bằng chế độ nhà phát triển của Odoo — nơi lấy ra tên kỹ thuật của trường, model đứng sau màn hình và kiểu dữ liệu, bằng cách rê chuột lên dấu chấm hỏi nhỏ nằm sau nhãn trường chứ không phải lên chính dòng chữ nhãn — và cách dùng nó cho từng việc cụ thể của BA là chủ đề của một bài riêng.
Đây là điều trái ngược với trực giác của phần lớn người mới: tài liệu của BA ERP ngắn hơn chứ không dài hơn.
Vì hệ thống đã có sẵn hành vi mặc định nên bạn không cần mô tả lại hành vi đó. Cách làm là ghi một dòng ở đầu tài liệu, đại ý hệ thống ưu tiên kế thừa các luồng chuẩn và mặc định của Odoo ERP, rồi từ đó trở đi chỉ mô tả những gì khác với mặc định.
Một dòng đó thay thế được hàng chục trang. Bạn không cần viết rằng người dùng bấm nút tạo mới thì hệ thống mở form trống, và nếu thiếu trường bắt buộc thì hệ thống báo lỗi — chuyện đó hệ thống nào cũng vậy và ai cũng biết; bạn chỉ cần viết phần trường mới bạn thêm vào, ràng buộc mới bạn đặt ra, và luồng mới bạn thiết kế.
Người mới thường làm ngược lại: họ viết tài liệu dày, mô tả từ đầu tới cuối mọi thao tác, mất hai tuần, và cuối cùng đội phát triển vẫn phải hỏi lại đúng những chỗ chưa được mô tả rõ, vì những chỗ đó bị chìm trong đống mô tả thừa.
Nói vậy không có nghĩa là kinh nghiệm BA cũ của bạn mất giá trị, vì có ba thứ giữ nguyên và chúng vẫn là phần khó nhất của nghề. Bạn vẫn phải hỏi tại sao, bởi người dùng luôn mô tả cái họ đang làm chứ không mô tả cái họ đang vướng, và nếu bạn nhận yêu cầu theo đúng lời họ nói thì bạn đang thiết kế lại phần mềm cũ của họ trên một nền tảng mới - chuyện này ở dự án ERP còn nguy hiểm hơn, vì hệ thống thường đã có sẵn một cách làm khác tốt hơn và bạn bỏ lỡ nó chỉ vì không hỏi thêm một câu. Bạn vẫn phải quản lý stakeholder, vì yêu cầu từ một nhân viên chưa phải là requirement cho tới khi có người đủ thẩm quyền xác nhận. Và bạn vẫn phải chốt bằng văn bản, bởi phần lớn tranh chấp về sau đều quay về đúng một câu hỏi là cái này đã thống nhất chưa.
Lúc bạn thấy rõ nhất mình đang làm nghề gì không phải lúc viết tài liệu, mà là lúc go-live.
Khi hệ thống lên thật và người dùng bắt đầu vào, issue đổ về rất nhiều và trộn lẫn nhau: hoặc dữ liệu bị nhập sai, hoặc một cấu hình chưa được bật, hoặc bug hệ thống, hoặc hạ tầng chưa đáp ứng, và đặc biệt là rất nhiều issue chỉ đơn giản vì người dùng không biết thao tác ở đâu hoặc thao tác sai. Năm nhóm đó xử lý bằng năm cách khác nhau, mất năm khoảng thời gian khác nhau, và do những người khác nhau xử lý. Phân loại sai thì bạn gửi một yêu cầu sang cho developer và ngồi chờ mấy ngày, trong khi việc đó tự bạn làm mất mươi phút.
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 rất thẳng về chuyện này, rằng người phân loại được nhanh nhất trong đội thường là BA, còn người quản lý dự án nhiều khi không phân loại được, không phải vì họ kém mà vì họ không phải là người phân tích. Lý do đằng sau thì rõ: BA là người duy nhất đã đi qua cả nghiệp vụ, cả cấu hình, lẫn phần làm thêm, nên nhìn một issue là đoán được nó rơi vào nhóm nào.
Đó là giá trị riêng của vai trò này, và nó chỉ hiện ra ở giai đoạn mà không ai muốn nhớ tới.
Bạn sẽ thấy ba chức danh xuất hiện lẫn lộn trong tin tuyển dụng là Business Analyst, Functional Consultant và Implementation Specialist, nhưng ba cái tên đó thường chỉ cùng một phần việc. Cách đọc một tin tuyển dụng để biết vai thật nằm đằng sau cái tên là chủ đề của một bài riêng.
Khác biệt đáng quan tâm hơn nằm ở quy mô công ty. Ở công ty lớn, vai trò được tách rõ với người chuyên khảo sát, người chuyên viết tài liệu và người quản lý dự án riêng; còn ở công ty nhỏ thì một mình bạn kiêm gần hết các vai đó. Trong các dự án tôi đã làm ở quy mô nhỏ, BA gần như luôn phải biết việc của người quản lý dự án: lập roadmap, ước lượng nguồn lực, và nhận biết thứ gì nằm trong phạm vi hợp đồng, thứ gì là yêu cầu phát sinh. Nếu bạn đang chuẩn bị vào nghề thì đây là phần nên học sớm, vì nó không nằm trong bất kỳ giáo trình BA nào, và những nhóm năng lực mà thị trường tuyển dụng thật sự gọi tên cho vị trí này cũng là chủ đề của một bài riêng.
Nếu bạn đang từ BA phần mềm chuyển sang, thứ tự học hiệu quả nhất không phải là học lý thuyết ERP. Hãy làm bốn việc theo đúng thứ tự sau:
Theo ước lượng của tôi, bốn việc này mất khoảng một tuần và cho bạn nhiều hơn hẳn so với một tháng ngồi đọc tài liệu, bởi toàn bộ nghề này xoay quanh việc đối chiếu giữa yêu cầu và hệ thống, mà đối chiếu thì không học được bằng cách đọc.
Sau đó thì câu hỏi tiếp theo sẽ tự đến: một dự án ERP cần những tài liệu gì, và trong số đó cái nào thực sự bắt buộc.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận