# Quân làm BA — Blog về nghề Business Analyst — toàn văn > Blog về nghề Business Analyst: phân tích yêu cầu, làm việc với stakeholder, tài liệu và lộ trình nghề BA. Thỉnh thoảng có thêm bài về ERP và IFS Cloud. Tác giả: Đặng Đức Quân (CBAP® · Business Analysis · ERP · IFS Cloud). Ngôn ngữ: tiếng Việt. Về tác giả: Đặng Đức Quân (Quân làm BA) là Business Analyst (CBAP), viết blog tiếng Việt về nghề BA, thỉnh thoảng có thêm các bài về ERP và IFS Cloud. Không liên quan tới blog chính trị "Quan Làm Báo". Mục lục ngắn: https://quanlamba.com/llms.txt --- # Documentation BA: nói miệng thì nhanh, bắt bug thì mất dấu - URL: https://quanlamba.com/posts/tai-lieu-ba-noi-mieng-la-mat-dau/ - Ngày đăng: 2026-10-30 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, Kinh nghiệm thực chiến, Quân làm BA - Mô tả: Documentation BA không phải giấy tờ cho đẹp. Thiếu meeting note, version và nơi lưu trữ thì lúc bắt bug không ai chứng minh được đã chốt gì. Dev báo bug, hỏi chỗ này hồi đó chốt thế nào anh, và bạn mở máy ra tìm mà không thấy gì, không phải vì tài liệu bị xóa, mà vì nó chưa bao giờ được viết, lúc triển khai mọi thứ toàn nói miệng trong họp hoặc gõ vội qua tin nhắn. Bài này mình viết từ chính mấy lỗi documentation mình đã mắc, chứ không phải từ sách. ## những lỗi documentation mình đã mắc Lỗi đầu tiên nghe rất tầm thường, bận quá nên quên gửi meeting note, theo mình cái giá của nó là người dự họp mỗi người nhớ một kiểu, mà chẳng có văn bản nào để đối chiếu. Lỗi thứ hai là tài liệu không ghi version, không có lịch sử sửa, một file bị sửa nhiều lần như vậy thì nhìn vào chẳng biết bản nào mới nhất, ai sửa, sửa vì lý do gì. Lỗi thứ ba là không lưu trữ tài liệu dự án cho đàng hoàng, không có chỗ lưu tập trung thì truy vết lại một quyết định khó vô cùng. Hậu quả của cả ba dồn vào đúng một thời điểm, lúc dev bắt bug, mình cần tài liệu để đối chiếu mà không tìm được, vì hồi triển khai mọi thứ chỉ nói miệng hoặc nhắn tin, không có bằng chứng nào cho thấy yêu cầu đã được chốt ra sao. Buồn cười là môi trường làm việc khá hiền hòa, không ai cãi nhau, nhưng không cãi nhau đâu có nghĩa là không mất thời gian, thiếu tài liệu thì người ta vẫn phải nhớ lại, đoán lại rồi mới fix được. Hiền hòa chỉ làm cái giá đó bớt ồn ào thôi. ## vì sao nói miệng cho nhanh lại thành chậm Theo mình nói miệng với nhắn tin chẳng có lỗi gì, chúng nhanh, tự nhiên, nhiều quyết định nhỏ đúng là nên chốt như vậy, vấn đề nằm ở chỗ quyết định đó không được đưa về một nơi chính thức sau khi chốt. Tin nhắn trôi rất nhanh, một tuần sau nó nằm dưới hàng trăm tin khác, vài tháng sau người trong cuộc có khi đã chuyển team hoặc nghỉ việc, lúc đó câu đã chốt gì không còn ai trả lời chắc được, bên nào cũng giữ một phiên bản trí nhớ của riêng mình. Trong BABOK Guide v3, mảng này nằm trong phần quản lý vòng đời yêu cầu (requirements life cycle management), trong đó có traceability, tức là khả năng lần ngược từ một chức năng về yêu cầu gốc và quyết định đã sinh ra nó. Mình không dẫn nguyên văn ở đây, nhưng ý thì đơn giản, không lần ngược được thì bạn không biết một hành vi của hệ thống là bug hay là đúng như đã chốt. ## viết tài liệu nhiều thì chậm, Agile mà Đây là lý do phổ biến để không viết, và nó đúng một nửa. [Agile Manifesto](https://agilemanifesto.org/) đặt phần mềm chạy được lên trên tài liệu đầy đủ, nhưng ưu tiên hơn không có nghĩa là bỏ hẳn, chỗ hiểu sai là đánh đồng documentation với việc viết một bộ tài liệu dày cho đẹp. Thứ cần giữ thật ra không nhiều, quyết định nào được chốt, ai chốt, khi nào, vì sao, vài dòng là đủ, còn thứ tốn thời gian thật không phải viết vài dòng đó, mà là lúc bắt bug phải ngồi tái dựng chúng từ trí nhớ của nhiều người. Một kiểu hiểu sai khác là nghĩ tin nhắn cũng là bằng chứng rồi, về lý thuyết thì có, nhưng không ai tìm lại được thì cũng như không, bằng chứng phải nằm ở chỗ người khác biết mà tìm. ## theo mình nên làm thế nào Từ mấy lỗi trên, đây là những thói quen mình nghĩ BA nên giữ, quan điểm của mình thôi, bạn chỉnh theo dự án. Đầu tiên là gửi meeting note trong ngày, kể cả khi chỉ có ba dòng, một meeting note ngắn gửi ngay có giá trị hơn một biên bản đầy đủ không bao giờ được gửi, chỉ cần ghi đã chốt gì, ai làm gì tiếp, còn câu hỏi nào mở, bận quá thì gửi bản nháp ghi rõ sẽ bổ sung, vẫn hơn im lặng. Thứ hai là đưa quyết định từ tin nhắn về tài liệu chính thức. Giả sử key user nhắn bỏ bước duyệt thứ hai cho đơn dưới một mức tiền nào đó cũng được, việc của BA lúc đó là cập nhật vào tài liệu yêu cầu, ghi ngày và người đồng ý, rồi nhắn lại một câu xác nhận, tin nhắn vẫn là nơi trao đổi, còn tài liệu là nơi lưu kết luận. Thứ ba là tài liệu nào cũng có version và lịch sử sửa, không cần công cụ xịn, một bảng nhỏ đầu file gồm số version, ngày, người sửa, nội dung thay đổi là đủ trả lời câu bản này khác bản trước ở đâu, cũng là tinh thần của configuration management, biết chính xác đang dùng bản nào. Thứ tư là một chỗ lưu trữ duy nhất cả team đều biết, chứ không phải mỗi người một thư mục trên máy, dev hỏi tài liệu ở đâu thì câu trả lời nên là một đường dẫn, không phải để anh tìm lại đã. Giả sử bạn làm đủ bốn việc này rồi dev báo bug, bạn mở tài liệu ra là thấy version nào chốt yêu cầu đó, ai đồng ý, ngày nào, cuộc nói chuyện chuyển từ hồi đó hình như sang đây là cái đã chốt, giờ mình xem có cần đổi không. Nhanh hơn, mà cũng nhẹ người hơn cho cả hai bên. ## documentation đi cùng tài liệu nào Còn rối giữa các loại tài liệu yêu cầu thì bài [BRD, SRS, FS khác nhau thế nào](/posts/brd-srs-fs-khac-nhau-the-nao/) giúp phân biệt nên ghi quyết định vào đâu, đội bạn làm theo user story thì đọc thêm [use case và user story](/posts/use-case-vs-user-story/) để thấy phần để làm gì cũng là một dạng bằng chứng, và tới giai đoạn kiểm thử thì [kịch bản UAT trong dự án ERP](/posts/uat-kich-ban-uat-du-an-erp/) là nơi tài liệu đã chốt được đem ra đối chiếu thật. Documentation không phải giấy tờ cho sếp xem, nó là bằng chứng để sau này bạn, dev và khách khỏi phải đoán lại những gì đã chốt, bắt đầu từ việc nhỏ nhất là cuộc họp tiếp theo, gửi meeting note ngay trong ngày. Bạn đã bao giờ mất dấu một quyết định chỉ vì nó nằm trong tin nhắn chưa? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # BA có bị AI thay không? Việc gì giao được cho AI, việc gì không - URL: https://quanlamba.com/posts/ba-co-bi-ai-thay-khong/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, AI, Góc nhìn - Mô tả: BA có bị AI thay không? AI làm tốt phần nháp như biên bản, user story, test case. Phần hỏi, quan sát và chịu trách nhiệm vẫn là của BA. Giả sử bạn ngồi thử một lần, mở ChatGPT gõ viết giúp mình 5 user story cho tính năng đăng ký tài khoản, vài giây sau nó trả về đủ 5 câu kèm luôn acceptance criteria, bạn nhìn màn hình rồi tự hỏi vậy mình còn việc gì để làm. Theo mình câu trả lời nằm ở chỗ tách nghề BA ra làm hai phần, phần thao tác và phần trách nhiệm, AI đang thay được phần đầu, còn phần sau thì chưa. ## AI thay thao tác, chưa thay trách nhiệm Thao tác là những việc lặp lại, có mẫu, như viết nháp user story, tóm tắt biên bản, gợi ý test case, viết câu SQL kiểm dữ liệu, mấy việc này AI làm nhanh và thường không tệ. Trách nhiệm là những việc chẳng ai dám giao cho máy, ai đứng ra nói không với khách khi phạm vi phình ra, ai chịu trách nhiệm khi tài liệu sai làm kế toán ghi nhầm công nợ, ai ngồi xưởng nhìn công nhân làm thật để thấy quy trình trên giấy lệch thực tế thế nào. Thế nên thay vì lo có bị thay không, câu hữu ích hơn là mình giao việc gì cho AI để rảnh tay làm phần không giao được. ## việc giao được cho AI Tóm tắt biên bản họp là việc đầu tiên, sau một buổi workshop hai tiếng, thay vì ngồi gõ lại từng ý, bạn đưa ghi chú thô cho AI và hỏi "Tóm tắt biên bản họp này, liệt kê quyết định, action item kèm người phụ trách, và những câu hỏi còn mở." Chỗ phải tự kiểm là AI có thể nhầm ai nói gì, hoặc bỏ sót một quyết định bị nói lửng lơ. Nháp user story là việc thứ hai, có danh sách yêu cầu rồi thì hỏi "Viết 3 user story cho tính năng đặt lại mật khẩu, theo mẫu As a / I want / So that, kèm acceptance criteria." AI làm nháp rất nhanh, còn rule nghiệp vụ có đúng không, có sót luồng ngoại lệ không, giọng có khớp cách team bạn viết không thì bạn phải tự soi, cách viết cho chuẩn mình đã bàn trong bài [User story và acceptance criteria](/posts/user-story-acceptance-criteria/). Gợi ý test case và câu SQL là việc thứ ba, kiểu "Liệt kê 5 trường hợp test biên cho màn hình nhập ngày giao hàng" hay "Viết câu SQL đếm số đơn mua chưa thanh toán theo nhà cung cấp", chỗ phải kiểm là câu SQL có chạy đúng schema thật của hệ thống không. Điểm chung của cả ba là AI cho ra bản nháp, còn người chịu trách nhiệm vẫn là bạn, đừng copy-paste thẳng. ## việc không giao được Ngồi xưởng hoặc phòng kế toán xem người ta làm thật là việc đầu tiên máy chịu thua. Quy trình viết trên giấy với quy trình người ta thực sự chạy thường khác nhau, kế toán có thật sự đối chiếu ba lần như quy trình ghi không, hay họ có một file Excel để ngoài mà ai cũng ngầm dùng, cái lệch đó chỉ thấy được khi ngồi xem tận mắt, mà AI thì không ngồi xưởng được. Thương lượng phạm vi và nói không là việc thứ hai. Stakeholder đòi thêm tính năng sát go-live, việc của BA là đứng ra giải thích cái giá phải trả, đề xuất phương án thay thế, đôi khi từ chối thẳng, đây là thương lượng giữa người với người dựa trên niềm tin bạn đã gây dựng, máy không thay được. Ra quyết định khi quy trình rời rạc là việc thứ ba. Nhiều doanh nghiệp có quy trình chồng chéo, không ai sở hữu rõ ràng, AI liệt kê được lựa chọn, nhưng đi hướng nào lại phụ thuộc chính trị nội bộ và con người cụ thể, góc này mình đã viết trong bài [AI không cứu nổi quy trình rời rạc](/posts/ai-khong-cuu-noi-quy-trinh-roi-rac/). ## thị trường nói gì Đọc vài tin tuyển BA ở Hà Nội đang đăng hoặc vừa hết hạn trong năm 2026 thì tín hiệu khá rõ, AI đã vào JD, nhưng ở vai trò công cụ. Tin Senior BA Platform của MISA trên Devwork ghi trong nhóm yêu cầu bắt buộc "Sử dụng các công cụ AI để tối ưu công việc" ([xem tin](https://www.devwork.vn/viec-lam/14255/senior-ba-platform), đã hết hạn 08/10/2026). Tin Senior BA của Edufy trên 123job để ở mức lợi thế, "Có kinh nghiệm áp dụng AI để tối ưu hiệu suất công việc là một lợi thế" ([xem tin](https://www.123job.vn/viec-lam/phan-tich-nghiep-vu-ba-senior-business-analyst-thu-nhap-upto-40000000-tai-ha-noi-PDbov84J9R), đã hết hạn). Ở mức fresher, tin BA của Huvisoft trên Joboko tự giới thiệu là "Team AI-first", cấp tài khoản Claude cho BA dùng trong công việc ([xem tin](https://vn.joboko.com/viec-lam-business-analyst-fresher-junior-luong-8-12-trieu-xvi6765195)). Để ý là không tin nào bỏ yêu cầu khảo sát, phân tích nghiệp vụ hay làm việc với khách, AI chỉ được thêm vào cạnh những việc đó. Ba tin là mẫu nhỏ, không đại diện cả thị trường, nhưng đủ thấy ở vài chỗ biết dùng AI đã từ điểm cộng thành yêu cầu, nhất là ở vị trí senior. Với fresher thì đây là cơ hội hơn là mối đe dọa, dùng AI khéo thì làm nháp nhanh hơn, thời gian dư dồn vào phần phải hỏi, phải xem tận mắt. ## rủi ro khi dùng AI Rủi ro lớn nhất là dữ liệu khách hàng, đưa số liệu thật, danh sách khách hay chi tiết dự án vào một công cụ AI công khai mà công ty không cho phép là vi phạm bảo mật, quy tắc đơn giản là ẩn dữ liệu trước khi hỏi, hoặc chỉ dùng công cụ công ty đã chấp thuận. Rủi ro thứ hai là AI bịa rule nghiệp vụ, nó có thói quen trả lời trơn tru kể cả khi không chắc, hỏi quy trình chuẩn ghi nhận công nợ là gì thì nó có thể bịa ra một quy trình nghe rất hợp lý mà sai với thực tế công ty bạn, và tài liệu trơn tru mà sai còn nguy hiểm hơn tài liệu sai chính tả. AI là trợ lý, không phải người ký duyệt, thứ gì nó sinh ra cũng phải qua mắt bạn. ## fresher nên làm gì từ tuần này Trước hết là học dùng AI vào đúng chỗ, bắt đầu từ việc đơn giản nhất như tóm tắt biên bản và nháp user story, làm quen tới mức thành phản xạ, nhưng lúc nào cũng kiểm lại. Song song là rèn phần AI không làm được, học đặt câu hỏi với stakeholder, học quan sát quy trình thực tế, học viết cho rõ và nói không cho đúng, mấy kỹ năng này không lỗi thời. Và quan trọng nhất là đừng để AI làm mình lười nghĩ, theo mình rủi ro thật với người mới là quen dựa dẫm tới mức không còn tự phân tích được vấn đề, AI đưa đáp án nhanh, nhưng đặt được câu hỏi đúng mới làm nên một BA giỏi. ## máy làm nháp, người ký tên AI sẽ làm phần thao tác của nghề BA ngày càng tốt, nhưng nghề này chưa bao giờ chỉ là thao tác, nó là hiểu nghiệp vụ, nói chuyện được với con người, và dám chịu trách nhiệm. Ba thứ đó máy chưa làm được. Muốn xem các tin tuyển trên còn đòi gì ngoài AI và trả bao nhiêu thì đọc [Lương BA Việt Nam 2026](/posts/luong-ba-viet-nam-2026/). Bạn đang dùng AI vào việc gì trong nghề BA, và việc gì bạn thấy AI làm tệ nhất? Chia sẻ với mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # BA, PO, PM khác nhau thế nào? Chọn hướng nào sau 2 năm - URL: https://quanlamba.com/posts/ba-po-pm-khac-nhau-chon-huong-nao/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Hướng nghiệp, Lộ trình sự nghiệp - Mô tả: BA, PO, PM khác nhau ở câu hỏi mỗi vai trả lời và quyết định họ chịu. So sánh theo loại công ty, 4 hướng đi sau 2 năm làm BA và 5 câu hỏi tự chọn. Một tin tuyển BA fresher ở Hà Nội đang mở (hạn nộp 09/11/2026) ghi thẳng trong phần quyền lợi "Định hướng phát triển lên Product Owner (PO)" ([tin của Huvisoft trên Joboko](https://vn.joboko.com/viec-lam-business-analyst-fresher-junior-luong-8-12-trieu-xvi6765195)), tức là câu hỏi làm BA rồi đi đâu đã được đặt ra ngay từ lúc nộp CV. Khoảng hai năm sau, khi việc đã quen tay, nhìn người cùng lứa người lên PO, người sang PM, bạn sẽ phải tự trả lời nó, phần dưới so ba vai để bạn tự chọn. ## ba vai, ba câu hỏi Ba vai này khác nhau ở một điểm cốt lõi là mỗi người trả lời một câu hỏi khác nhau. BA trả lời vấn đề và yêu cầu là gì, đi tìm hiểu nghiệp vụ, phân tích, viết yêu cầu, làm cầu nối giữa người dùng và đội làm sản phẩm. PO (Product Owner) trả lời làm gì trước và đem lại giá trị gì, sở hữu backlog, quyết thứ tự ưu tiên, chịu trách nhiệm về giá trị sản phẩm. PM (Project Manager) trả lời làm sao xong đúng hạn, đúng ngân sách, quản tiến độ, rủi ro, nguồn lực, đưa dự án về đích. | Tiêu chí | BA | PO | PM | | --- | --- | --- | --- | | Trả lời câu hỏi | Vấn đề và yêu cầu là gì | Làm gì trước, giá trị gì | Xong đúng hạn, đúng ngân sách thế nào | | Quyết định chính | Yêu cầu đúng, tài liệu đúng | Ưu tiên backlog | Tiến độ, nguồn lực | | Đo bằng gì | Yêu cầu rõ, ít làm lại | Giá trị sản phẩm | Đúng hạn, đúng ngân sách | | Làm việc với ai | Người dùng, dev, designer | Người dùng, stakeholder, dev | Cả team, sponsor | Hiểu lầm hay gặp là BA chỉ là người viết tài liệu, PO mới là người hiểu sản phẩm. BABOK Guide v3 định nghĩa business analysis rộng hơn nhiều, là xác định nhu cầu và đề xuất giải pháp tạo giá trị cho stakeholder, ai làm việc đó là đang làm business analysis bất kể chức danh, khác nhau giữa ba vai nằm ở quyết định mỗi người phải chịu. ## ngoài đời thì chồng lấn theo loại công ty Trên giấy thì rõ, ra đời thì chồng lấn, ranh giới mờ nhiều hay ít tùy loại công ty. Ở công ty outsource, BA thường kiêm luôn phần PM, vừa phân tích yêu cầu vừa đốc tiến độ vừa làm đầu mối với khách, còn vai PO nếu có thì thường nằm phía khách, vì sản phẩm là của họ. Ở công ty product, PO là vai rõ ràng, BA đôi khi bị gộp vào PO hoặc làm dưới PO, BA lo chi tiết yêu cầu, PO lo ưu tiên. Còn dự án ERP thì có thêm một hướng nữa là solution architect hoặc consultant, đi sâu vào nghiệp vụ và sản phẩm ERP, không nhất thiết lên PO hay PM. ## bốn hướng sau hai năm Hướng thứ nhất là ở lại đi sâu thành senior hay lead BA, xử lý bài toán khó hơn, dẫn dắt BA khác, review tài liệu, cần thêm chiều sâu nghiệp vụ và kỹ năng mentor. Hướng thứ hai là sang PO, sở hữu sản phẩm và quyết ưu tiên, cần thêm tư duy đo giá trị, khả năng nói chuyện với stakeholder, và cái gan dám quyết. Hướng thứ ba là sang PM, quản dự án, cần thêm quản tiến độ, rủi ro, nguồn lực, và sức chịu áp lực deadline. Hướng thứ tư là sang consultant, nhất là mảng ERP, đi sâu vào một sản phẩm và một miền nghiệp vụ, cần hiểu kỹ sản phẩm và quy trình end-to-end, hướng này mình đã nói kỹ trong bài [Từ BA sang tư vấn ERP](/posts/tu-ba-sang-tu-van-erp/). ## năm câu hỏi để tự chọn Bạn thích quyết định làm gì trước, hay thích ngồi yên đào sâu phân tích yêu cầu, thích quyết ưu tiên thì PO, thích đào sâu thì senior BA. Bạn có chịu được áp lực deadline và việc chạy theo kế hoạch không, chịu được thì nghĩ tới PM. Bạn có thích nói chuyện với khách hàng và stakeholder nhiều không, thích thì PO hoặc PM, ngại thì đi sâu chuyên môn. Bạn có hứng thú với một miền nghiệp vụ cụ thể như kế toán, sản xuất, chuỗi cung ứng không, có thì hướng consultant ERP rất hợp. Và cuối cùng, bạn giỏi làm cho rõ hay giỏi đẩy cho xong, làm cho rõ là BA, đẩy cho xong là PM. ## JD đang nói gì Tin fresher của Huvisoft ở đầu bài coi lộ trình lên PO là quyền lợi, còn tin Senior BA BHXH của MISA trên Devwork ghi quyền lợi "Được trực tiếp tham gia xây dựng Product Roadmap", việc mà sách vở hay xếp cho PO ([xem tin](https://www.devwork.vn/viec-lam/14253/senior-ba-bhxh), đã hết hạn). Hai tin không đại diện cả thị trường, nhưng cho thấy ở công ty product ranh giới BA với PO khá mờ, nghĩa là bạn không cần chọn cứng ngay từ đầu, nhiều người đi BA, dần nhận thêm việc ưu tiên backlog, rồi tự nhiên thành PO lúc nào không hay. ## chứng chỉ để sau Có người hỏi có cần thi PSPO, PMP không, mình nghĩ để sau khi đã chọn hướng. PSPO (Professional Scrum Product Owner) hữu ích nếu đi hướng PO, PMP hữu ích nếu đi hướng PM, còn chứng chỉ BA như CBAP dành cho hướng đi sâu BA, chọn hướng trước rồi chứng chỉ theo sau, đừng làm ngược. Cách chọn chứng chỉ BA thì đọc [CBAP, CCBA, ECBA: chọn cái nào](/posts/chung-chi-ba-cbap-vs-ccba-vs-ecba-chon-cai-nao/). ## hướng nào cũng cần chọn có chủ đích Không có hướng nào cao hơn hướng nào, PO, PM, senior BA hay consultant đều là đường riêng, mỗi đường trả giá bằng một thứ khác nhau, quan trọng là biết mình thích làm gì mỗi sáng thức dậy. Còn phân vân giữa làm người ra quyết định với làm người chấp hành cho giỏi thì đọc [Bạn là phi công hay thợ máy](/posts/ban-la-phi-cong-hay-la-tho-may/), bài đó mình bàn về hai kiểu người làm nghề. Bạn đang đứng đâu trên con đường này, và định rẽ hướng nào? Chia sẻ với mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # BPMN cho người mới: vẽ as-is/to-be từ ghi chú workshop - URL: https://quanlamba.com/posts/bpmn-cho-nguoi-moi-as-is-to-be/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, Quy trình, Fresher - Mô tả: BPMN cho người mới: 10 ký hiệu đủ dùng và 5 bước biến ghi chú workshop thành sơ đồ as-is/to-be. Kèm ví dụ đề nghị mua hàng và 5 lỗi hay gặp. Giả sử bạn vừa bước ra khỏi buổi workshop hai tiếng với phòng mua hàng, cầm về tờ giấy chi chít chữ, ai gửi yêu cầu, ai duyệt, mức nào phải lên giám đốc, lúc nào thì chạy Excel ngoài, giờ phải vẽ lại thành một sơ đồ cho cả team nhìn chung một bức tranh, mở công cụ lên rồi đứng hình. Bài này đi từ đúng tờ giấy đó ra một sơ đồ BPMN dùng được, kèm mấy lỗi hay biến sơ đồ thành tranh treo tường. ## BPMN trong một đoạn BPMN (Business Process Model and Notation) là chuẩn ký hiệu để vẽ quy trình nghiệp vụ, khác flowchart ở chỗ có quy ước rõ ràng, ai làm thì đặt vào lane, rẽ nhánh dùng gateway, sự kiện dùng hình tròn, nhờ vậy hai người cùng nhìn một sơ đồ sẽ hiểu giống nhau mà không phải đoán. Trong BABOK Guide v3 việc này thuộc kỹ thuật Process Modelling (10.35), còn BPMN là một ký pháp phổ biến để làm kỹ thuật đó. Bạn không cần thuộc cả trăm ký hiệu, với phần lớn sơ đồ chừng này là đủ: - Pool: ranh giới một quy trình hoặc một tổ chức, thường cả sơ đồ nằm trong một pool lớn. - Lane: một vai trò hoặc phòng ban bên trong pool, ví dụ "Phòng mua hàng", "Kế toán". - Start event: hình tròn rỗng, điểm bắt đầu. - End event: hình tròn viền dày, điểm kết thúc. - Task: hình chữ nhật bo góc, một bước công việc cụ thể. - Gateway độc quyền: hình thoi có dấu X, chỉ một nhánh được đi tiếp tùy điều kiện. - Gateway song song: hình thoi có dấu cộng, nhiều nhánh chạy cùng lúc. - Sequence flow: mũi tên liền, thứ tự thực hiện giữa các task. - Message flow: mũi tên đứt, trao đổi thông tin giữa các pool. - Intermediate event: hình tròn viền đôi, sự kiện xảy ra giữa luồng như nhận tin nhắn hay hẹn giờ. Theo mình nắm mười ký hiệu này là vẽ được phần lớn quy trình nghiệp vụ thường gặp. ## as-is trước, to-be sau As-is là quy trình đang chạy, to-be là quy trình mong muốn sau khi cải tiến hoặc lên hệ thống mới, và luôn vẽ as-is trước, vì chưa hiểu hiện trạng thì to-be chỉ là mơ ước. Bạn rất dễ vẽ ra một quy trình sạch đẹp trên giấy mà bỏ qua cái Excel ngoài luồng cả phòng đang ngầm dùng, tới lúc triển khai cái Excel đó lại hiện ra và phá mọi thứ. Vẽ as-is còn là cách phát hiện điểm đau, chỗ nào đang chờ tay, chỗ nào nhập trùng dữ liệu, chỗ nào một người duyệt mà chẳng ai biết tiêu chí là gì. ## từ workshop ra sơ đồ trong năm bước Bước một là chuẩn bị câu hỏi trước khi vào họp, bạn cần biết ai bắt đầu quy trình, quy trình đi qua những bước nào, ai duyệt ở mỗi bước, và ngoại lệ là gì, riêng câu "khi nào thì quy trình này không chạy như bình thường" thường khai thác được nhiều nhất. Bước hai là ghi theo lane ngay trên giấy hoặc sticky, chia cột theo vai trò, bước nào dán vào cột người làm bước đó, nhìn vào là thấy ngay ai đang ôm quá nhiều việc. Bước ba là vẽ happy path trước, nối các bước chính thành một luồng từ start tới end, chưa lo ngoại lệ, xong luồng chính rồi mới thêm gateway cho các nhánh rẽ. Bước bốn là đánh dấu điểm đau bằng một ký hiệu riêng, màu khác hay icon gì cũng được, cho chỗ chờ tay, chỗ nhập tay, chỗ dùng Excel trung gian, đây là nguyên liệu cho bước to-be. Bước năm là review lại với người làm thật, đưa sơ đồ cho chính người vận hành xem và hỏi có đúng không, có chỗ nào em vẽ sai không, đừng chỉ duyệt với trưởng phòng, người bấm nút mỗi ngày mới là người bắt được chỗ sai. ## ví dụ đề nghị mua hàng trong nhà máy Đây là ví dụ giả định để bạn dễ hình dung, không phải quy trình của công ty cụ thể nào. Ở as-is, công nhân phát hiện thiếu vật tư, viết yêu cầu mua ra giấy, đưa tổ trưởng ký, rồi phòng mua nhập lại vào một bảng Excel để theo dõi, đơn trên một mức nào đó thì phải trình giám đốc duyệt. Vấn đề là dữ liệu nằm ở hai nơi, giấy và Excel, nên hay lệch, mà phòng mua cũng chẳng biết đơn nào đang chờ ai duyệt. Ở to-be trên ERP, công nhân tạo yêu cầu mua ngay trên hệ thống, hệ thống tự chuyển cho người duyệt theo mức giá trị, phòng mua chỉ việc xem danh sách đã duyệt để tạo đơn mua, không còn giấy, cũng không còn Excel trung gian. Trên sơ đồ, as-is hiện rõ ba lane (Công nhân, Tổ trưởng, Phòng mua) với hai chỗ gãy là chỗ nhập tay vào Excel và chỗ chờ ký giấy, còn to-be gọn lại, rẽ nhánh bằng gateway độc quyền theo mức tiền. Vẽ cả hai thì mọi người thấy khác biệt bằng mắt thay vì cãi nhau bằng lời, và bản to-be này chính là đầu vào cho bước so với sản phẩm chuẩn, mình viết ở bài [Fit-gap analysis ERP](/posts/fit-gap-analysis-trien-khai-erp/). ## năm lỗi người mới hay mắc Lỗi đầu tiên là chia lane sai, hay gộp hai vai trò vào một lane vì cùng phòng, trong khi hai vai đó làm hai việc khác nhau, tách lane ra mới thấy bàn giao nằm ở đâu. Lỗi thứ hai là gateway không ghi điều kiện, hình thoi rẽ nhánh mà không ghi đi nhánh này khi nào thì người đọc chịu chết. Lỗi thứ ba là vẽ quá chi tiết, tới từng cú click chuột thì sơ đồ thành hướng dẫn sử dụng, chẳng ai đọc nổi, BPMN nên dừng ở mức quy trình chứ không phải thao tác. Lỗi thứ tư là quên start event hoặc end event, người đọc không biết quy trình trôi về đâu. Lỗi thứ năm, cũng là lỗi tốn công nhất, là vẽ to-be trước khi hiểu as-is. ## công cụ nên dùng Không cần phần mềm đắt tiền, draw.io (app.diagrams.net) miễn phí, chạy trên trình duyệt, có sẵn bộ ký hiệu BPMN, đủ cho hầu hết nhu cầu, công ty có Visio thì dùng Visio, Bizagi Modeler cũng miễn phí và chuyên BPMN nhưng hơi nặng nếu bạn chỉ vẽ sơ đồ đơn giản. Công cụ nào cũng được, miễn ký hiệu đúng chuẩn để người khác đọc được, vẽ bằng gì mà sai ký hiệu thì vẫn khó hiểu như thường. ## sơ đồ để cãi nhau đúng chỗ Sơ đồ BPMN là để nói chuyện chứ không phải để nộp cho đẹp, giá trị của nó nằm ở chỗ cả team nhìn vào cùng một bức tranh và cãi nhau trên đúng vấn đề, thay vì mỗi người hiểu một kiểu. Chưa có dự án thật để vẽ thì làm một case simulation trong portfolio, cách làm có trong bài [Portfolio BA khi chưa có dự án](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/), còn muốn lấy yêu cầu cho đúng trước khi vẽ thì đọc [3 nguyên tắc sống còn để lấy yêu cầu hiệu quả](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/). Bạn hay vẽ quy trình bằng công cụ gì, và có mẹo nào khi ngồi workshop không? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # BRD, SRS, FS khác nhau thế nào? Dự án thật dùng cái nào - URL: https://quanlamba.com/posts/brd-srs-fs-khac-nhau-the-nao/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Fresher, Kỹ năng BA - Mô tả: BRD, SRS, FS khác nhau ở câu hỏi mỗi tài liệu trả lời và người đọc nó. Bài gợi khung tối thiểu và câu trả lời phỏng vấn 30 giây cho BA fresher. Lỗi hay gặp của fresher với BRD, SRS, FS là thuộc lòng ba định nghĩa mà vẫn viết sai tài liệu. Giả sử ngày đầu đi làm bạn được giao viết SRS cho module này, trong khi tuần trước có người vừa gửi BRD, cả team thì cứ nói FS, ba cái tên mà câu hỏi thật chỉ có một, tài liệu này ai đọc và để quyết định việc gì. ## ba tài liệu, ba câu hỏi Mỗi tài liệu trả lời một câu hỏi khác nhau, nhớ được câu hỏi thì tên gọi có đổi thế nào bạn cũng nhận ra. BABOK Guide v3 không dùng chữ BRD hay SRS, nó chia yêu cầu thành bốn loại, business requirements (mục tiêu, lý do thay đổi), stakeholder requirements (nhu cầu của từng bên), solution requirements (gồm functional và non-functional) và transition requirements (những thứ chỉ cần cho giai đoạn chuyển đổi như data conversion, đào tạo) ([IIBA, 4.4 Understanding Requirements and Designs](https://www.iiba.org/knowledgehub/the-business-analysis-standard/4-implementing-business-analysis/4-4-understanding-requirements-and-designs/)). Theo mình map gọn nhất là BRD chứa business và stakeholder requirements, còn SRS và FS chứa solution requirements ở hai mức chi tiết khác nhau. ### BRD, doanh nghiệp cần gì và vì sao BRD (Business Requirements Document) trả lời tại sao làm dự án này và doanh nghiệp cần đạt được gì, nói bằng ngôn ngữ nghiệp vụ, mục tiêu, phạm vi, stakeholder, vấn đề hiện tại, yêu cầu nghiệp vụ ở mức cao. Người viết thường là BA hoặc người đại diện nghiệp vụ, người đọc là ban lãnh đạo, sponsor, trưởng các bộ phận, những người quan tâm làm xong thì được lợi gì chứ chẳng quan tâm màn hình có mấy nút. ### SRS, hệ thống phải làm gì SRS (Software Requirements Specification) trả lời hệ thống phải làm được những gì, mô tả yêu cầu chức năng (tính năng, luồng) và yêu cầu phi chức năng (hiệu năng, bảo mật, khả năng mở rộng). Người đọc là dev, tester, kiến trúc sư, những người cần biết chính xác hệ thống phải chạy thế nào, nên SRS giống một bản hợp đồng giữa nghiệp vụ và kỹ thuật. ### FS hoặc FRD, chức năng chạy chi tiết thế nào FS (Functional Specification) hay FRD (Functional Requirements Document) đi sâu thêm một bước, một chức năng cụ thể có những màn hình nào, field nào, rule nào, validation ra sao, luồng xử lý từng bước. SRS nói hệ thống phải quản lý được đơn mua hàng, thì FS nói rõ màn hình tạo đơn mua có các field mã PO, nhà cung cấp, ngày giao, danh sách dòng hàng, nhập mã nhà cung cấp thì hệ thống tự điền thông tin, thiếu ngày giao thì chặn lưu. | Tiêu chí | BRD | SRS | FS/FRD | | --- | --- | --- | --- | | Trả lời câu hỏi | Vì sao làm, cần gì | Hệ thống làm gì | Chức năng chạy chi tiết thế nào | | Người viết | BA, đại diện nghiệp vụ | BA, kiến trúc sư | BA, đôi khi cả dev | | Người đọc | Sponsor, lãnh đạo, trưởng bộ phận | Dev, tester, kiến trúc sư | Dev, tester | | Thời điểm | Đầu dự án | Sau khi chốt phạm vi | Thiết kế chi tiết | | Độ chi tiết | Thấp | Trung bình | Cao | ## ngoài đời tên gọi lộn xộn hơn nhiều Tới đây chắc bạn nghĩ vậy là rõ rồi, cứ ba loại mà viết, nhưng ra đời thì lộn xộn hơn nhiều. Cùng một nội dung, công ty này gọi SRS, công ty kia gọi FS, công ty nữa gọi PRD (Product Requirements Document), ví dụ tin Senior BA BHXH của MISA trên Devwork yêu cầu nắm "PRD, SRS, use case, user story" ([xem tin](https://www.devwork.vn/viec-lam/14253/senior-ba-bhxh)), bốn cái tên mà đều trỏ về việc viết tài liệu yêu cầu, tên gọi đổi theo văn hóa công ty và loại dự án chứ chẳng theo chuẩn cứng nào. Dự án ERP có một nét riêng. Hệ thống đã có sẵn, SAP, Oracle hay IFS Cloud, nên người ta không viết SRS cho cả hệ thống, việc đó nhà sản xuất làm rồi, thay vào đó là viết FSD cho phần gap, chỗ nào quy trình khách khác sản phẩm chuẩn thì mô tả chi tiết phần đó cần cấu hình hay phát triển thêm, nên trong dự án ERP bạn sẽ nghe FSD, gap, fit-gap nhiều hơn SRS. Dự án Agile lại khác nữa, backlog và user story thay phần lớn FS, mỗi user story kèm acceptance criteria là đủ để dev làm, nhưng rule chung, quy ước toàn hệ thống vẫn cần một chỗ để ghi, thường là một tài liệu gọn hoặc wiki. Agile không vứt hết tài liệu, nó chỉ dời trọng tâm đi chỗ khác. ## khung tối thiểu cho từng tài liệu Bạn không cần một mẫu dài mười trang, chỉ cần một checklist tối thiểu để khỏi sót mục quan trọng. BRD tối thiểu có bối cảnh và vấn đề, mục tiêu, phạm vi gồm làm gì và không làm gì, stakeholder, yêu cầu nghiệp vụ chính, rủi ro và giả định. SRS tối thiểu có tổng quan hệ thống, yêu cầu chức năng theo từng module, yêu cầu phi chức năng, ràng buộc và các luồng chính. FS cho một chức năng thì có mục đích, danh sách màn hình và field, rule xử lý, validation, luồng bình thường, luồng ngoại lệ và các trường hợp lỗi. ## trả lời phỏng vấn trong 30 giây Phỏng vấn hỏi phân biệt BRD và SRS thì trả lời gọn kiểu này: "BRD trả lời vì sao làm và doanh nghiệp cần gì, viết cho lãnh đạo đọc. SRS trả lời hệ thống phải làm gì, viết cho dev và tester đọc. Còn FS đi sâu chi tiết từng chức năng, màn hình, rule. Còn dự án ERP thì thường viết FSD cho phần gap, thay vì SRS cho cả hệ thống." Câu trả lời như vậy cho thấy bạn hiểu bản chất chứ không học vẹt định nghĩa, mà đó chính là thứ người phỏng vấn muốn thấy. ## việc đầu tiên khi vào team mới Đừng học thuộc ba cái tên, hãy nhớ ba câu hỏi, vì sao làm, hệ thống làm gì, chức năng chạy thế nào, rồi vào team mới thì việc đầu tiên là hỏi tài liệu của mình ai đọc, vì chính người đọc quyết định nên viết gì và viết dài bao nhiêu. Muốn thấy một chức năng viết thành use case và user story khác nhau ra sao thì đọc [Use case và user story khác nhau thế nào](/posts/use-case-vs-user-story/), phần yêu cầu phi chức năng trong SRS hay bị bỏ quên thì có bài riêng [Non-functional requirement: những yêu cầu BA hay quên](/posts/non-functional-requirement-nhung-yeu-cau-minh-tung-quen/), còn sắp đi phỏng vấn thì xem [Phỏng vấn BA fresher: những câu hỏi thật](/posts/phong-van-ba-fresher-cau-hoi-that/). Chỗ bạn đang làm gọi tài liệu yêu cầu là BRD, SRS hay PRD? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Có nên đi học khóa BA hay tự học? Chọn theo thứ bạn đang thiếu - URL: https://quanlamba.com/posts/co-nen-di-hoc-khoa-ba-hay-tu-hoc/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Hướng nghiệp, Fresher, Học tập - Mô tả: Có nên học khóa BA hay tự học? Xác định bạn thiếu kiến thức, kỷ luật hay feedback. Sau đó dùng checklist để chọn khóa cho đúng. Bạn đang cầm vài triệu, phân vân có nên đăng ký một khóa BA, quảng cáo thì hứa đủ thứ từ ba tháng đi làm ngay tới đảm bảo việc làm, người quen thì bảo tự học được, khỏi tốn tiền. Bài này không bán khóa học cho ai, nên mình nói thẳng. ## phụ thuộc bạn đang thiếu gì Theo mình câu cái nào tốt hơn không có đáp án chung, câu có đáp án là bạn đang thiếu cái gì. Thiếu kiến thức thì cách nào cũng bù được, nhưng thiếu kỷ luật thì tự học dễ chết yểu, còn thiếu feedback thì tự học mãi chẳng biết mình sai ở đâu. Nên trước khi hỏi học khóa hay tự học, hãy hỏi mình đang thiếu kiến thức, kỷ luật, hay feedback. ## tự học cho gì, thiếu gì Tự học cho bạn sự tự do, học theo tốc độ của mình, không tốn tiền, và quan trọng nhất là buộc bạn chủ động tìm hiểu, kỹ năng BA nào cũng cần, lộ trình tự học 6–9 tháng mình đã viết chi tiết trong bài [Tự học BA 6-9 tháng: lịch thật, không lộ trình khóa học](/posts/tu-hoc-ba-6-9-thang-lich-that/). Có điều tự học thiếu ba thứ, không ai bắt deadline nên dễ bỏ giữa chừng, không ai chấm bài nên làm sai mà không biết, và không có mạng lưới, tức người giới thiệu việc, người chia sẻ kinh nghiệm thật. Bạn tự kỷ luật tốt thì tự học hoàn toàn đủ để bắt đầu. ## khóa học cho gì, không cho gì Khóa tốt cho bạn ba thứ tự học khó có, mentor chỉnh sai, deadline ép bạn tiến lên, và một cộng đồng học viên để trao đổi. Nhưng nó không cho bạn cái nhiều quảng cáo hứa, là việc làm, theo mình khóa tử tế không hứa đảm bảo việc làm, thấy hứa thì nên hỏi kỹ, vì đi làm được hay không là ở bạn chứ không ở khóa học. Khóa học cũng không thay được việc bạn phải tự làm bài, tự mày mò, chỉ ngồi nghe giảng thì chẳng khác gì xem video miễn phí trên mạng. ## checklist chọn khóa Quyết học khóa thì hỏi cho rõ mấy điều này trước khi nộp tiền. Giảng viên có đang làm BA thật không, hay chỉ dạy lý thuyết, người đang làm nghề kể dự án khác hẳn người chỉ đọc slide. Có bài tập được chấm và sửa từng bài không, hay xem video rồi tự chấm, bài tập được chấm là phần đáng tiền nhất. Có case thật để làm không, hay chỉ ví dụ mẫu. Học viên cũ giờ làm gì, câu này lật tẩy nhất, trung tâm không nói được học viên cũ đang làm BA ở đâu, hoặc né, thì nên cẩn thận. Còn cam kết đảm bảo việc làm thì hỏi kỹ điều kiện đi kèm, thường là đảm bảo giới thiệu, hoặc hoàn tiền nếu đạt điều kiện này kia, chứ không phải đảm bảo có việc. ## chọn theo hoàn cảnh | Hoàn cảnh | Gợi ý | | --- | --- | | Sinh viên, nhiều thời gian, ít tiền | Tự học + case simulation | | Dev đang đi làm, muốn chuyển | Tự học + xin nhận thêm việc phân tích ở công ty | | Người trái ngành, đi làm full-time, khó tự kỷ luật | Khóa học có mentor, hoặc mentor 1-1 | | Đã có nền, cần feedback để lên trình | Mentor 1-1 hoặc cộng đồng | ## lối ở giữa Không phải chỉ có hai cửa, có một lối ở giữa nhiều người bỏ qua, tự học để có nền, làm portfolio case simulation để chứng minh, rồi tìm một mentor để sửa sai. Cách này rẻ hơn khóa học mà vẫn có người chỉnh feedback, bạn tự học theo lộ trình, làm vài case trong portfolio (cách làm có trong bài [Portfolio BA khi chưa có dự án](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/)), rồi nhờ một BA có kinh nghiệm review, đôi khi một giờ review của người làm nghề thật đáng hơn cả một khóa dài. Có người nghĩ học khóa xong là phải thi ngay chứng chỉ IIBA, mình nghĩ không cần vội, ECBA, CCBA, CBAP có ý nghĩa hơn khi bạn đã có nền hoặc có kinh nghiệm, nó là cách để khẳng định chứ không phải để bắt đầu. ## tiền nên mua thứ bạn không tự tạo được Đừng để quảng cáo hay người quen quyết hộ, tự hỏi mình đang thiếu kiến thức, kỷ luật hay feedback, rồi bù đúng chỗ thiếu đó, tiền bỏ ra nên mua cái bạn không tự tạo được chứ đừng mua thứ có sẵn miễn phí. Có case trong tay rồi thì bước tiếp là đưa nó vào [CV BA cho người mới ra trường](/posts/cv-ba-cho-nguoi-moi-ra-truong/). Bạn đang phân vân tự học hay học khóa? Kể hoàn cảnh của bạn cho mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/), mình gợi ý theo đúng trường hợp của bạn. --- # CV BA cho người mới ra trường: viết gì khi chưa có việc - URL: https://quanlamba.com/posts/cv-ba-cho-nguoi-moi-ra-truong/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Fresher, Hướng nghiệp, Phỏng vấn - Mô tả: CV BA cho người mới ra trường nên dựa vào JD fresher thật. Biến case simulation thành mục dự án và viết lại kinh nghiệm cũ bằng ngôn ngữ BA. Phần kinh nghiệm trong CV đang trống thì bạn lấp nó bằng gì, nhiều người lấp bằng một đoạn mục tiêu nghề nghiệp dài với danh sách mười kỹ năng, và theo mình đó là cách nhanh nhất để CV bị lướt qua. Tin vui là ở vị trí fresher, nhà tuyển dụng không chờ bạn có chức danh BA, họ chờ bằng chứng bạn làm được việc của BA. ## nhà tuyển dụng fresher đang đòi gì Trước khi viết thì xem người ta đòi gì, mình lấy hai tin tuyển đang đăng làm ví dụ. Tin Fresher Business Analyst của SmartOSC nhận "Fresh graduates or final year student", yêu cầu kỹ năng phân tích, giao tiếp và "Excellent English" để đọc viết tài liệu, trao đổi với khách nước ngoài ([tin trên trang tuyển dụng SmartOSC](https://careers.smartosc.com/job/fresher-business-analyst/), hạn 31/10/2026). Tin BA fresher/junior của Huvisoft nhận 0–2 năm kinh nghiệm và liệt kê tài liệu sẽ phải làm, gồm user story, use case, business rule, acceptance criteria, wireframe ([tin trên Joboko](https://vn.joboko.com/viec-lam-business-analyst-fresher-junior-luong-8-12-trieu-xvi6765195)). Hai tin cho thấy ở mức fresher thứ được đòi là nền tảng, phân tích, giao tiếp, tiếng Anh, và biết các loại tài liệu BA, đó là thứ CV của bạn phải chứng minh. Còn công cụ như Jira hay draw.io thì biết cứ ghi, nhưng ghi kèm bạn đã dùng nó vào việc gì. ## cấu trúc CV một trang Fresher thì một trang là đủ, thứ tự gọn là tóm tắt, dự án hoặc case, kinh nghiệm liên quan, kỹ năng, học vấn và chứng chỉ. Tóm tắt chỉ cần hai ba câu, bạn là ai, đang nhắm vị trí BA, thế mạnh là gì, đừng viết người năng động cầu tiến, ai cũng viết thế nên chẳng ai tin. Phần quan trọng nhất với fresher là dự án, vì đó là chỗ bạn chứng minh mình làm được việc dù chưa có kinh nghiệm. ## biến case simulation thành dự án Chưa có dự án thật nhưng bạn có thể có case simulation, và case đó hoàn toàn ghi vào CV như một dự án được, miễn là ghi trung thực, nêu bối cảnh ngắn, việc bạn đã làm, sản phẩm cụ thể kèm link, ví dụ: "Case simulation: quy trình mua hàng của một nhà máy giả định. Đã vẽ sơ đồ as-is/to-be bằng BPMN, viết user story và acceptance criteria, làm một bản wireframe. Xem tại [link portfolio]." Cách ghi này cho nhà tuyển dụng thấy bạn biết làm gì, hơn là bạn đã từng ngồi ở đâu, chưa biết vẽ phần as-is/to-be thì bắt đầu từ [BPMN cho người mới](/posts/bpmn-cho-nguoi-moi-as-is-to-be/). Chỗ hay làm sai là ghi case simulation như dự án thật cho một công ty có tên, hoặc ghi khách hàng khi chẳng có khách nào, người phỏng vấn hỏi hai câu là lộ, trong khi ghi rõ case giả định lại là điểm cộng vì cho thấy bạn trung thực và biết mình đang làm gì. Cách làm case chi tiết thì đọc [Portfolio BA khi chưa có dự án](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/). ## viết lại kinh nghiệm cũ bằng ngôn ngữ BA Từng làm dev, tester, kế toán hay chăm sóc khách hàng thì đừng vứt kinh nghiệm đó đi, viết lại bằng ngôn ngữ BA. Tester có thể viết là phân tích yêu cầu để viết test case, làm việc với khách hàng để làm rõ luồng nghiệp vụ, còn chăm sóc khách hàng thì là lắng nghe và phân tích vấn đề của khách, ghi nhận yêu cầu và phối hợp giải quyết. Mấu chốt là nhấn vào phần phân tích và giao tiếp, hai kỹ năng lõi của BA, thay vì phần kỹ thuật hay thao tác. ## kỹ năng chỉ ghi cái chứng minh được Đừng ghi một danh sách dài kiểu SQL, Python, Figma, Jira, BPMN, BABOK, nhà tuyển dụng hỏi ngay, không biết là lộ. Chỉ ghi cái bạn thật sự làm được, tốt hơn nữa là kèm bằng chứng, như "SQL: viết được SELECT, JOIN, GROUP BY (xem case X)", một kỹ năng có bằng chứng đáng hơn mười kỹ năng ghi suông. ## bảy lỗi hay gặp CV dài hai ba trang với đủ thứ không liên quan, trong khi fresher một trang là đủ. Mở đầu bằng mục tiêu sáo rỗng kiểu mong muốn phát triển trong môi trường năng động, bỏ đi. Liệt kê kỹ năng không chứng minh được. Không có link portfolio hay sản phẩm, trong khi đó chính là thứ phân biệt bạn với hàng chồng CV fresher khác. Viết sai ngôn ngữ, ứng tuyển công ty làm với khách nước ngoài thì nên có CV tiếng Anh, ít nhất là khớp ngôn ngữ JD. Sai chính tả và trình bày lộn xộn, CV là tài liệu đầu tiên thể hiện độ cẩn thận của bạn, BA mà CV sai chính tả là trừ điểm nặng. Và không chỉnh CV theo từng tin, gửi một bản cho mọi nơi thì tỷ lệ lọt thấp, ít nhất hãy chỉnh phần tóm tắt và kỹ năng theo từng JD. ## gửi kèm gì Cùng với CV, chuẩn bị link portfolio, nơi để case simulation của bạn, và chuẩn bị luôn cho vòng phỏng vấn, vì CV chỉ là vé vào cửa, phỏng vấn BA fresher hay hỏi gì thì đọc [Phỏng vấn BA fresher: những câu hỏi thật](/posts/phong-van-ba-fresher-cau-hoi-that/). ## ghi ít, ghi đúng, có link CV fresher không cần ghi nhiều mà cần ghi đúng, đúng thứ nhà tuyển dụng tìm và đúng thứ bạn chứng minh được, một case simulation có link còn giá trị hơn cả trang kinh nghiệm giả. Bạn đang viết CV BA đầu tiên và kẹt ở đâu? Gửi câu hỏi cho mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # ERD cho BA: đọc được sơ đồ dữ liệu mà không cần là dev - URL: https://quanlamba.com/posts/erd-cho-ba/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, SQL, Fresher - Mô tả: ERD cho BA: đọc sơ đồ dữ liệu theo 4 bước, hiểu quan hệ 1-n, n-n qua ví dụ đơn hàng. Từ đó viết yêu cầu đúng dữ liệu và nói chuyện được với dev. Lỗi hay gặp của BA mới với ERD là lướt qua luôn, coi đó là việc của dev, mà hậu quả thì tới muộn, viết yêu cầu xem lịch sử mua hàng của khách mà không biết dữ liệu nằm ở bảng nào, nên chẳng hỏi được mấy câu quan trọng kiểu một khách có thể có mấy địa chỉ giao hàng. Đọc ERD ở mức BA không cần biết code, chỉ cần bốn bước và một ví dụ. ## ERD trong ba câu ERD (Entity Relationship Diagram) là sơ đồ mô tả dữ liệu được lưu thế nào, có những thực thể nào (entity), mỗi thực thể có thuộc tính gì (attribute), và chúng quan hệ với nhau ra sao, trong BABOK Guide v3 việc này thuộc kỹ thuật Data Modelling (10.15). Với BA, ERD giúp trả lời mấy câu dữ liệu stakeholder hay hỏi, một khách có thể có bao nhiêu đơn, một đơn chứa bao nhiêu sản phẩm, số điện thoại khách lấy ở đâu, hiểu được dữ liệu thì viết yêu cầu không bị sai về bản chất. ## đọc ERD theo bốn bước Bước một là tìm entity chính, thường là một danh từ nghiệp vụ như Khách hàng, Đơn hàng, Sản phẩm, xem sơ đồ xoay quanh cái gì, hay là thực thể có nhiều đường nối tới nhất. Bước hai là tìm khóa, khóa chính (primary key) là trường định danh duy nhất một bản ghi, ví dụ mã khách hàng, còn khóa ngoại (foreign key) là trường trỏ sang khóa chính của bảng khác để nối hai bảng lại. Bước ba là đọc quan hệ, 1-n nghĩa là một bên có thể có nhiều bên kia, như một khách có nhiều đơn hàng, còn n-n là nhiều-nhiều, một đơn có nhiều sản phẩm và một sản phẩm nằm trong nhiều đơn. Bước bốn là đặt câu hỏi nghiệp vụ, mỗi quan hệ đọc được thì thử biến thành câu hỏi, vậy muốn biết khách này mua gì thì phải đi qua những bảng nào, tới lúc này ERD mới bắt đầu có ích thật. ## ví dụ đơn hàng và dòng đơn Lấy ví dụ kinh điển gồm Khách hàng, Đơn hàng, Dòng đơn, Sản phẩm. Một khách có nhiều đơn, đó là quan hệ 1-n giữa Khách hàng và Đơn hàng, mỗi đơn lại chứa nhiều dòng, mỗi dòng là một sản phẩm kèm số lượng, đơn giá. Vì sao cần bảng Dòng đơn ở giữa, vì giữa Đơn hàng và Sản phẩm là quan hệ n-n, mà muốn lưu n-n thì người ta tách ra một bảng trung gian, mỗi dòng ghi đơn này chứa sản phẩm này, số lượng bao nhiêu. Hiểu chuyện này rồi thì bạn sẽ hiểu vì sao khi viết yêu cầu hiển thị danh sách sản phẩm trong đơn, dữ liệu thật ra nằm ở bảng Dòng đơn chứ không phải bảng Đơn hàng hay Sản phẩm. ## từ ERD sang câu SQL JOIN Mỗi đường nối giữa hai bảng trên ERD là một chỗ bạn có thể cần JOIN trong SQL, muốn lấy tên khách và tổng số đơn của họ thì JOIN Khách hàng với Đơn hàng qua khóa ngoại, muốn lấy danh sách sản phẩm trong đơn X thì JOIN ba bảng Đơn hàng, Dòng đơn, Sản phẩm. Nắm ERD thì hiểu vì sao cần JOIN và JOIN cái gì với cái gì, cách viết SQL cho BA thì đọc [SQL cho BA: SELECT, JOIN, GROUP BY là đủ sống](/posts/sql-cho-ba-select-join-group-by-la-du-song/). ## góc ERP, vì sao migration hay vỡ ở khóa ngoại Trong ERP, sau một màn hình trông đơn giản có thể là hàng chục bảng liên kết, một đơn mua kéo theo bảng đơn mua, dòng đơn mua, nhà cung cấp, vật tư, đơn vị tính, kho, cộng thêm một đống bảng cấu hình. Chính mạng khóa ngoại dày đặc này làm data migration hay vỡ, chuyển dữ liệu từ hệ cũ sang mà chỉ một khóa ngoại trỏ sai, mã vật tư không tồn tại hay mã kho bị trùng chẳng hạn, là cả bảng không nạp được. Hiểu ERD giúp bạn thấy trước mấy chỗ dễ vỡ này, bài [Data migration: những cái bẫy không ai nói trước](/posts/data-migration-nhung-cai-bay-khong-ai-noi-truoc/) nói kỹ hơn. ## BA vẽ ERD tới mức nào Bạn không cần vẽ chi tiết như kiến trúc sư dữ liệu, có ba mức và BA thường dừng ở hai mức đầu. Mức khái niệm (conceptual) chỉ vẽ entity và quan hệ, chưa quan tâm kiểu dữ liệu, mức logic (logical) thêm thuộc tính và khóa cho từng entity, còn mức vật lý (physical) gắn kiểu dữ liệu, tên bảng, chỉ mục thì để dev. Vẽ được ở mức logic là đủ trao đổi với cả nghiệp vụ lẫn dev, công cụ thì dbdiagram.io hoặc draw.io là đủ dùng. Có một hiểu lầm theo chiều ngược lại, đọc được ERD rồi thì tự thiết kế database cho dev, theo mình đừng, BA dùng ERD để hỏi đúng câu nghiệp vụ, còn chuẩn hóa bảng, đặt chỉ mục là việc của người thiết kế dữ liệu. ## đủ để hỏi đúng câu về dữ liệu Bạn không cần thành chuyên gia database, chỉ cần đọc được ERD để hiểu dữ liệu nằm đâu, quan hệ ra sao, vậy là đủ viết yêu cầu chính xác và nói chuyện được với dev. Đọc được dữ liệu rồi thì bước tiếp là ghi field và rule vào tài liệu yêu cầu, bài [BRD, SRS, FS khác nhau thế nào](/posts/brd-srs-fs-khac-nhau-the-nao/) chỉ chỗ đặt chúng. Bạn gặp ERD lần đầu có bị ngợp không? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Fit-gap analysis ERP: làm thế nào để mỗi gap ra quyết định - URL: https://quanlamba.com/posts/fit-gap-analysis-trien-khai-erp/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, ERP, Kỹ năng BA, Quyết định - Mô tả: Fit-gap analysis ERP chỉ có ích khi mỗi gap có quyết định. Quy trình 5 bước, mẫu bảng và 5 cách xử lý gap từ rẻ tới đắt. Có lần mình làm một hệ thống chia lệnh sản xuất tự động, hệ thống đã tự tính hết rồi, vậy mà khách vẫn muốn giữ file Excel cũ, tự nhập tự điền như trước, vì quen và vì tiện lưu trữ. Nói thẳng thì việc đó không còn cần nữa, nhưng gốc của nó không phải lười đổi thói quen, họ sợ hệ thống tính nhầm, một nỗi lo rất tự nhiên. Từ vụ đó mình hiểu ra một điều về fit-gap, nhiều yêu cầu sửa cho giống cách cũ thật ra là nỗi lo chưa được giải tỏa chứ không phải gap, fit-gap chỉ có ích khi mỗi dòng trong danh sách đi tới một quyết định kèm tên người quyết, còn dòng nào sinh ra từ nỗi lo thì phải xử lý nỗi lo trước. ## fit-gap trong một đoạn Fit-gap analysis là việc so quy trình to-be của khách với tính năng chuẩn của sản phẩm để phân từng yêu cầu vào ba nhóm, fit là sản phẩm đáp ứng đúng, dùng luôn, gap là không đáp ứng, phải xử lý, còn partial fit là đáp ứng một phần, cần cấu hình thêm hoặc đổi quy trình nhỏ. Nó thường làm sau khi có quy trình to-be và trước khi chốt thiết kế hay cấu hình, là cầu nối giữa khách muốn gì và sản phẩm làm được gì. BABOK Guide v3 không có mục riêng tên fit-gap, theo mình gần nhất là nhóm task Strategy Analysis (phân tích hiện trạng, xác định trạng thái tương lai, chọn change strategy) và task 8.3 Assess Solution Limitations khi đánh giá một sản phẩm có sẵn. ## quy trình làm Fit-gap thường kéo dài nhiều buổi, đi theo năm bước. Đầu tiên là lập danh sách yêu cầu theo quy trình, từ to-be liệt kê từng yêu cầu cụ thể kiểu khi đơn mua vượt mức X thì cần giám đốc duyệt. Sau đó demo chuẩn sản phẩm, cho khách xem sản phẩm chạy quy trình đó thế nào từng bước một. Rồi phân từng yêu cầu thành fit, gap hay partial fit, với mỗi gap thì đưa phương án xử lý kèm đánh đổi, cuối cùng là để người quyết định chọn và ghi lại quyết định đó. ## mẫu bảng fit-gap Một bảng gọn nên có các cột ID, quy trình, yêu cầu, mức fit, phương án đề xuất, công sức (S/M/L), rủi ro, người quyết, trạng thái. Mức fit ghi fit, gap hay partial fit, phương án ghi cách xử lý, công sức ghi tương đối nhỏ vừa lớn, không cần con số chính xác, chỉ để mọi người có cảm giác về chi phí. Cột người quyết là quan trọng nhất mà người mới hay bỏ, gap nào cũng phải có một người chịu trách nhiệm chốt, không thì nó nằm đó mãi. ## năm cách xử lý gap, từ rẻ tới đắt Rẻ nhất là đổi quy trình, chấp nhận làm theo cách chuẩn của sản phẩm, có điều cần khách đồng ý bỏ thói quen cũ. Tiếp theo là cấu hình, dùng cấu hình có sẵn để đáp ứng mà không cần code, lựa chọn tốt nhất cho partial fit. Thứ ba là báo cáo hoặc workaround, dùng báo cáo, xuất Excel, hay một quy trình phụ bên ngoài để bù chỗ thiếu. Thứ tư là tùy biến nhỏ, thêm một field hay một luồng riêng. Đắt nhất là tùy biến lớn, phát triển một module gần như mới, kèm theo gánh nặng mỗi lần nâng cấp. ## khi nào nói không với tùy biến Tùy biến không phải lúc nào cũng xấu, nhưng hay bị lạm dụng, theo mình nó chỉ nên làm khi gap đụng tới tuân thủ pháp lý hoặc là lợi thế cạnh tranh thật của doanh nghiệp, còn vì quen làm thế này thì chưa đủ lý do. Tùy biến nào cũng có cái giá ngầm, mỗi lần nâng cấp sản phẩm phần tùy biến phải kiểm lại, có khi phải sửa, càng nhiều tùy biến càng khó nâng cấp, người quyết cần hiểu rõ cái giá này trước khi gật đầu. Mong muốn làm giống Excel cũ là nguồn của khá nhiều tùy biến không đáng làm, và gap nào đã chọn phương án rồi thì phải kiểm lại bằng kịch bản thật ở [UAT cho dự án ERP](/posts/uat-kich-ban-uat-du-an-erp/). ## khi khách muốn giữ Excel vì sợ hệ thống tính sai Quay lại vụ chia lệnh sản xuất, việc đầu tiên mình làm là họp riêng với khách, giải thích kỹ công thức hệ thống đang tính, để họ thấy con số không phải từ trên trời rơi xuống. Họp xong mà họ vẫn chưa yên tâm thì mình đồng ý cho chạy song song Excel một thời gian để so kết quả, theo mình khoảng một đến hai tuần là đủ, số trên Excel khớp với số hệ thống suốt khoảng đó thì khách tự yên tâm, hệ thống ổn định rồi thì mình đề xuất bỏ Excel, vì giữ cả hai là làm trùng việc. Còn nếu hai bên lệch số trong lúc chạy song song thì đừng vội kết luận ai sai, việc đầu tiên là xác định root cause, lệch ở đâu, do nhập tay trên Excel hay do nhập liệu trên hệ thống, xác định được gốc rồi mới đào nguyên nhân sâu hơn. Anh em có thể phản biện rằng chạy song song là tốn công gấp đôi, sao không bắt bỏ Excel luôn cho nhanh. Đúng là tốn công thật, nhưng bỏ Excel khi khách chưa tin hệ thống thì niềm tin vẫn chưa có, còn một hai tuần chạy song song có mốc kết thúc rõ ràng và có số liệu để khách tự kiểm. ## sai lầm hay gặp Sai lầm lớn nhất là biến fit-gap thành danh sách tùy biến, ghi mọi gap rồi gap nào cũng sẽ tùy biến, thế là fit-gap mất luôn ý nghĩa là công cụ ra quyết định. Sai lầm thứ hai là không có người quyết, gap liệt kê xong rồi nằm im vì chẳng ai chịu chốt. Sai lầm thứ ba là đánh giá fit sai vì chưa hiểu sản phẩm đủ sâu, yêu cầu tưởng là gap hóa ra cấu hình được, chỉ là mình chưa biết, nên trước khi kết luận gap hãy hỏi người hiểu sản phẩm. ## mỗi dòng một quyết định, một cái tên Bảng fit-gap tốt là bảng mà dòng nào cũng có một quyết định và một cái tên, dùng chuẩn, cấu hình hay tùy biến, và ai chốt. Tuần này thử mở bảng của bạn ra đếm xem bao nhiêu dòng còn trống cột người quyết, gap không ai quyết sẽ thành [nợ quyết định](/posts/no-quyet-dinh-decision-debt/), còn nếu bạn đang cân nhắc làm cái nghề ngồi fit-gap mỗi tuần thì đọc [Từ BA sang tư vấn ERP](/posts/tu-ba-sang-tu-van-erp/). Anh em đã gặp khách nào xin giữ Excel cho chắc chưa, và anh em xử lý thế nào? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # IFS Cloud là gì, và BA làm gì trong dự án IFS Cloud? - URL: https://quanlamba.com/posts/ifs-cloud-la-gi-ba-lam-gi/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: IFS Cloud, ERP, Business Analyst, Cloud ERP - Mô tả: IFS Cloud là gì? Nền tảng của IFS gộp ERP, EAM, SCM và FSM cho doanh nghiệp công nghiệp. Bài này giải thích BA làm gì trong dự án IFS Cloud. **Trả lời ngắn:** Theo trang chính thức của IFS, IFS Cloud là nền tảng gộp ERP, quản lý tài sản (EAM), chuỗi cung ứng (SCM) và dịch vụ hiện trường (FSM) cho doanh nghiệp công nghiệp. BA trong dự án IFS Cloud khảo sát quy trình, làm fit-gap, chuyển yêu cầu thành đặc tả cấu hình rõ ràng, rồi hỗ trợ UAT và đào tạo người dùng. Giả sử bạn là BA vừa bị điều vào một dự án IFS Cloud, tuần đầu tài liệu toàn thuật ngữ lạ, họp buổi nào cũng nghe release, lobby, configuration, và câu đầu tiên trong đầu là mình phải biết gì về IFS Cloud, việc của mình bắt đầu từ đâu. Thông tin sản phẩm trong bài lấy từ các trang chính thức của IFS mình đọc ngày 30/10/2026, gồm [IFS Cloud](https://www.ifs.com/en/ifs-cloud), [IFS Cloud ERP](https://www.ifs.com/en/products/erp) và [IFS Cloud Releases](https://www.ifs.com/en/ifs-cloud/releases), còn phần BA làm gì là góc nhìn nghề của mình. ## IFS Cloud là gì, nói đơn giản Trang [IFS Cloud](https://www.ifs.com/en/ifs-cloud) mô tả đây là một nền tảng trải trên bốn mảng, Enterprise Resource Planning (ERP), Enterprise Asset Management (EAM), Supply Chain Management (SCM) và Field Service Management (FSM), nói nôm na là tài chính, mua hàng, sản xuất, kho, bảo trì thiết bị và đội kỹ thuật đi hiện trường đều nằm trên một hệ thống. Đối tượng chính là doanh nghiệp công nghiệp, menu ngành trên ifs.com liệt kê hàng không và quốc phòng, năng lượng và tiện ích, xây dựng và kỹ thuật, sản xuất, vận tải, viễn thông, còn trang [IFS Cloud ERP](https://www.ifs.com/en/products/erp) nhấn vào các ngành nhiều tài sản và vận hành phức tạp, với các phần như Manufacturing Execution System, Supply Chain Management, Procurement và Finance. Có hai đặc điểm BA nên để ý. IFS gọi kiến trúc của mình là composable và giao theo mô hình evergreen, tức cập nhật liên tục thay vì triển khai lại, và theo [trang Releases](https://www.ifs.com/en/ifs-cloud/releases) thì IFS Cloud ra bản mới hai lần một năm, bản 26R1 phát hành tháng 5/2026. Với BA, nhịp release này nghĩa là tùy biến nào bạn đề xuất hôm nay cũng sẽ phải sống qua nhiều lần nâng cấp. ## BA làm gì trong dự án IFS Cloud Nhiều người nghĩ BA trong dự án ERP là người bấm cấu hình, theo mình bấm cấu hình là việc của consultant chức năng hoặc kỹ thuật, còn BA (nhiều dự án gộp hai vai này) chịu trách nhiệm phần trước và sau cú bấm đó. Việc đầu tiên là khảo sát as-is, ngồi với phòng mua hàng, kế toán, xưởng sản xuất, vẽ lại quy trình đang chạy, một đề nghị mua đi qua những bước nào, ai duyệt, duyệt theo tiêu chí gì, chứng từ nào in ra giấy. Đây là nền móng, mà cũng là phần dễ bị làm qua loa nhất vì tốn thời gian. Việc thứ hai là fit-gap, so quy trình với chức năng chuẩn, chỉ ra chỗ khớp, chỗ cần cấu hình, chỗ phải đổi cách làm, chỗ thật sự cần phát triển thêm, cách làm cho ra quyết định có trong bài [Fit-gap analysis ERP](/posts/fit-gap-analysis-trien-khai-erp/). Việc thứ ba là chuyển yêu cầu thành đặc tả, câu đơn mua lớn thì giám đốc duyệt phải thành câu rõ ràng, trường giá trị nào, ngưỡng bao nhiêu, mấy bước duyệt, ai được thay khi người duyệt vắng, người cấu hình đọc vào là làm được, khỏi phải đoán. Việc thứ tư là UAT và đào tạo. Người dùng cuối không cần biết nền tảng mạnh cỡ nào, họ cần biết mỗi sáng mở màn hình nào, lobby nào để thấy việc của mình, trang ERP của IFS có nhắc tới interactive lobbies, và đây thường là thứ người dùng nhìn thấy đầu tiên. ## cái bẫy hay gặp Bẫy thứ nhất là biến ERP thành bản sao của Excel cũ, người dùng bảo làm cho em màn hình giống file cũ, BA gật, cấu hình y nguyên, kết quả là hệ thống mới chạy đúng quy trình giấy mà chẳng cải thiện gì. Bẫy thứ hai thì ngược lại, cái gì không vừa ý cũng đòi phát triển thêm. Với một nền tảng ra bản mới hai lần một năm, mỗi phần tùy biến là thêm một thứ phải kiểm thử lại sau mỗi lần nâng cấp, nên trước mỗi yêu cầu tùy biến hãy hỏi đây là cách làm tạo lợi thế riêng của doanh nghiệp, hay chỉ là thói quen. Mấy bẫy cụ thể ở mảng mua hàng có trong bài [IFS Cloud Procurement: những cái bẫy cấu hình](/posts/ifs-cloud-procurement-pitfalls/). ## BA cần học gì để làm IFS Cloud Không cần biết code, nhưng nên nắm ba thứ, logic ERP, tức mua hàng, kho, sản xuất, tài chính nối với nhau ra sao, một phiếu nhập kho sinh ra bút toán gì, rồi đọc và vẽ sơ đồ quy trình, tốt nhất là BPMN, và thói quen đọc tài liệu release của IFS, vì chức năng chuẩn đổi theo từng bản, có khi giải đúng cái gap bạn đang định đòi phát triển. Đang làm BA phần mềm mà tính rẽ sang mảng này thì bài [Từ BA sang tư vấn ERP](/posts/tu-ba-sang-tu-van-erp/) nói về khác biệt và điểm bắt đầu. Việc của BA trong dự án IFS Cloud rốt cuộc vẫn là việc quen thuộc, hiểu nghiệp vụ, viết yêu cầu rõ, làm cầu nối giữa người dùng và người cấu hình, chỉ khác là bạn làm nó trên một nền tảng rộng và thay đổi đều đặn, nên quyết định cấu hình hay tùy biến nào cũng có hệ quả dài hạn. Bạn muốn mình đi sâu vào mảng nào trước trong IFS Cloud, mua hàng, sản xuất hay cách khảo sát as-is? Nói mình nghe trên [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Lương BA Việt Nam 2026: con số đọc từ tin tuyển dụng thật - URL: https://quanlamba.com/posts/luong-ba-viet-nam-2026/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Hướng nghiệp, Fresher - Mô tả: Lương BA Việt Nam 2026 đọc từ tin tuyển dụng thật ở Hà Nội, có link từng tin. Fresher 8-12 triệu gross, senior 30-40 triệu ở các tin có ghi lương. Mình không tin mấy con số lương trung bình BA trôi nổi trên mạng, vì chẳng ai ghi rõ nó lấy từ đâu, nên bài này làm cách khác, đọc thẳng tin tuyển dụng, chỉ lấy con số có ghi trong tin, kèm link để bạn tự kiểm. Giới hạn nói rõ từ đầu là mẫu nhỏ, chủ yếu ở Hà Nội, đọc vào tháng 10/2026, đây là một bức ảnh chụp chứ không phải khảo sát thị trường. ## cách mình lấy số Quy tắc đơn giản thôi, tin nào ghi lương thì lấy, tin nào ghi thỏa thuận thì bỏ, con số nào cũng có link gốc, nhiều tin đã hết hạn nộp hồ sơ thì mình vẫn giữ link làm bằng chứng và ghi rõ. Có một điều đáng chú ý ngay là phần lớn tin BA ở Việt Nam không công bố lương, để thỏa thuận, nên mấy con số dưới đây chỉ là phần nhỏ có ghi công khai. ## fresher và junior Huvisoft (Hà Nội) tuyển Business Analyst fresher/junior, tiêu đề tin ghi "Lương 8-12 Triệu", phần quyền lợi ghi rõ "8-12 triệu VNĐ gross/tháng", yêu cầu 0–2 năm kinh nghiệm và nhận fresher ([tin trên Joboko](https://vn.joboko.com/viec-lam-business-analyst-fresher-junior-luong-8-12-trieu-xvi6765195), hạn nộp 09/11/2026). SmartOSC (Hà Nội) tuyển Fresher Business Analyst, không ghi lương chính thức mà ghi trợ cấp theo hiệu suất "up to 6.000.000 VND during the training period", kèm 3 tháng đào tạo tại chỗ ([tin trên trang tuyển dụng SmartOSC](https://careers.smartosc.com/job/fresher-business-analyst/), hạn 31/10/2026). Hai tin cho hai mốc khác nhau, lương chính thức 8–12 triệu gross, và trợ cấp tối đa 6 triệu trong giai đoạn đào tạo, chừng đó chưa đủ để nói fresher Hà Nội được bao nhiêu, chỉ đủ để bạn biết hỏi đúng lúc phỏng vấn, đây là lương hay trợ cấp đào tạo, gross hay net, bao lâu thì xét lại. ## senior MISA đăng tin Senior BA Platform và Senior BA BHXH trên Devwork, cùng mức 30–35 triệu, yêu cầu tối thiểu 4 năm kinh nghiệm BA và có kinh nghiệm BA Lead hoặc mentor ([tin Platform](https://www.devwork.vn/viec-lam/14255/senior-ba-platform), [tin BHXH](https://www.devwork.vn/viec-lam/14253/senior-ba-bhxh), hạn nộp 08/10/2026, đã hết hạn). Edufy tuyển Senior BA, tiêu đề ghi thu nhập "upto 40.000.000", yêu cầu tối thiểu 3 năm kinh nghiệm BA ([tin trên 123job](https://www.123job.vn/viec-lam/phan-tich-nghiep-vu-ba-senior-business-analyst-thu-nhap-upto-40000000-tai-ha-noi-PDbov84J9R), hạn nộp 23/05/2026, đã hết hạn). Gộp lại thì các tin senior có ghi lương mà mình mở được nằm trong khoảng 30–40 triệu, yêu cầu 3–4 năm kinh nghiệm trở lên, kèm vai trò dẫn dắt. ## middle Mức middle, khoảng 2–5 năm, nằm giữa fresher và senior, thì trong lần đọc này mình chưa tìm được tin nào công bố lương, nên ghi thẳng là chưa đủ dữ liệu. Bạn cũng đừng ngoại suy kiểu middle thì chắc nằm giữa rồi tự đặt một con số, nghe thì hợp lý nhưng chẳng có căn cứ gì. ## BA ERP và ERP consultant Mảng ERP consultant thì mình cũng chưa chốt được con số nào từ một tin còn sống có ghi lương trong lần đọc này, đây là mảng mình muốn bổ sung sau khi tìm được tin ghi lương rõ ràng. Có một tín hiệu nhỏ là tin Senior BA BHXH của MISA ưu tiên ứng viên có kinh nghiệm phần mềm ERP, HRM, nhưng ưu tiên thì chưa phải con số, mảng ERP được trả khác BA phần mềm thế nào phải chờ có tin ghi lương rõ, mình không đoán. ## đọc tin lương sao cho đúng Gross hay net là chỗ đầu tiên cần để ý, tin Huvisoft ghi rõ gross, tức lương trước khi trừ bảo hiểm và thuế, còn net là số bạn thực nhận, thấp hơn, tin nào không ghi thì hỏi cho rõ lúc phỏng vấn. Upto 40 triệu cũng không có nghĩa ai cũng được 40, đó là trần, mức thực tế tùy năng lực và thương lượng, đừng kỳ vọng vào con số trần. Còn thỏa thuận nghĩa là công ty không công khai chứ không phải trả bao nhiêu cũng được, bạn vẫn nên có một con số kỳ vọng của riêng mình trước khi ngồi xuống bàn. ## điều gì đẩy lương lên Đọc lại mấy JD trên thì thấy vài yếu tố lặp lại ở các vị trí lương cao. Lead và mentor là cái đầu tiên, tin MISA yêu cầu kinh nghiệm BA Lead hoặc mentor, tin Edufy giao cả quản lý, review và đào tạo thành viên, lương cao đi kèm trách nhiệm chứ không chỉ số năm kinh nghiệm. Tiếng Anh là cái thứ hai, tin fresher của SmartOSC yêu cầu "Excellent English" để đọc viết tài liệu và trao đổi với khách nước ngoài, theo mình tiếng Anh mở ra nhóm khách hàng khác, nhưng mấy tin này không đủ để nói nó cộng thêm bao nhiêu vào lương. Cái thứ ba là dùng AI, tin Edufy coi kinh nghiệm áp dụng AI là lợi thế, còn tin MISA đưa "Sử dụng các công cụ AI để tối ưu công việc" vào nhóm bắt buộc, phần này mình phân tích kỹ hơn trong bài [BA có bị AI thay không](/posts/ba-co-bi-ai-thay-khong/). ## dùng số này thế nào Nhắc lại lần nữa, mấy con số trên là ảnh chụp tháng 10/2026, ở Hà Nội, từ một mẫu nhỏ tin tuyển có công khai lương, đủ để bạn có một mốc tham khảo, không đủ để kết luận về cả thị trường. Muốn biết cách thương lượng khi đã có offer thì đọc [Vài kinh nghiệm deal lương cho BA tay ngang](/posts/vai-kinh-nghiem-ve-chuyen-deal-luong-cho-ba-tay-ngang/), còn đang chuẩn bị hồ sơ fresher thì đọc [CV BA cho người mới ra trường](/posts/cv-ba-cho-nguoi-moi-ra-truong/). Bạn đang ở mức nào, và mấy con số trên có khớp với thực tế chỗ bạn không? Chia sẻ với mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Non-functional requirement: những yêu cầu BA hay quên - URL: https://quanlamba.com/posts/non-functional-requirement-nhung-yeu-cau-minh-tung-quen/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, Fresher - Mô tả: Non-functional requirement là thứ BA hay quên vì demo không thấy. Cách viết NFR đo được, checklist câu hỏi và các NFR dự án ERP hay sót. Giả sử bạn viết xong mọi yêu cầu chức năng cho màn hình báo cáo tồn kho, chạy test ngon lành, ai cũng khen, rồi tới ngày go-live dữ liệu thật đổ vào mấy chục nghìn dòng, báo cáo mất hơn một phút mới load xong, khách đứng bên cạnh nhìn bạn. Đó là lúc bạn nhận ra mình đã quên một thứ tên là non-functional requirement, yêu cầu phi chức năng. ## NFR là gì Yêu cầu chức năng trả lời hệ thống làm gì, tạo được đơn hàng, duyệt được đề nghị mua, xuất được báo cáo, còn yêu cầu phi chức năng trả lời hệ thống chạy tốt tới mức nào, nhanh bao nhiêu, bảo mật ra sao, ai được xem gì, ghi log thế nào. BABOK Guide v3 xếp NFR vào nhóm solution requirements, gọi là non-functional hay quality of service requirements, tức những điều kiện hoặc phẩm chất giải pháp phải có ([IIBA, 4.4](https://www.iiba.org/knowledgehub/the-business-analysis-standard/4-implementing-business-analysis/4-4-understanding-requirements-and-designs/)), kỹ thuật tương ứng là Non-Functional Requirements Analysis (10.30). Ví dụ cho dễ nhớ, yêu cầu chức năng là hệ thống xuất báo cáo tồn kho, còn yêu cầu phi chức năng là báo cáo tồn kho trả kết quả trong vòng X giây với Y bản ghi, X và Y là con số bạn phải điền theo từng dự án. NFR hay bị quên vì một lý do đơn giản, nó không hiện ra lúc demo chức năng, màn hình chạy đúng, bấm nút ra kết quả là tưởng xong, trong khi chạy đúng với chạy tốt khi có, ví dụ, 50.000 dòng và 200 người dùng cùng lúc là hai chuyện khác hẳn nhau. ## viết sao cho đo được Lỗi phổ biến nhất là dùng từ mơ hồ, hệ thống phải nhanh thì nhanh là bao nhiêu, giao diện thân thiện thì đo bằng gì, bảo mật tốt thì tốt theo chuẩn nào. NFR tốt phải gắn được con số, điều kiện và cách kiểm, ví dụ với số minh họa, "Báo cáo tồn kho trả kết quả trong 5 giây với 100.000 bản ghi, đo trên máy chủ theo cấu hình chuẩn", câu này test được, tester biết phải tạo bao nhiêu dữ liệu, bấm nút rồi bấm đồng hồ. Khách chưa xác định được con số thì đừng bỏ trống, ghi một con số tạm để mọi người có chỗ bàn, rồi đánh dấu cần khách xác nhận. ## checklist NFR theo nhóm Đi khảo sát thì hỏi theo từng nhóm này để khỏi sót. Hiệu năng là báo cáo nào hay dùng cuối tháng mà dữ liệu lớn, bao nhiêu người dùng cùng lúc vào giờ cao điểm, và một câu mở rất đáng hỏi là thao tác nào anh chị thấy chậm nhất hiện tại. Bảo mật và phân quyền là ai được xem gì, ai được sửa gì, có dữ liệu nào chỉ một phòng được xem không, có cần phân quyền theo chi nhánh hay nhà máy không. Audit trail là thao tác nào cần lưu vết, ai làm, làm lúc nào, giá trị trước và sau, với ERP thì chuyện ai đổi giá, ai duyệt đơn thường là yêu cầu bắt buộc của kiểm toán. Khả năng dùng là người dùng ở đâu, dùng thiết bị gì, công nhân dưới xưởng có dùng máy tính bảng hay máy quét mã vạch không, cần tiếng Việt, tiếng Anh hay thêm ngôn ngữ khác. Lưu trữ là dữ liệu giữ bao lâu, có cần lưu để đối chiếu nhiều năm không, khối lượng tăng thế nào theo năm. Tích hợp là hệ thống phải nói chuyện với phần mềm nào khác, qua API hay nhập xuất file, tần suất ra sao. ## góc ERP, những NFR hay bị quên nhất Phân quyền theo vai trò và site là cái đầu tiên, một hệ thống ERP phục vụ nhiều nhà máy, nhiều chi nhánh, kế toán nhà máy A không được nhìn số nhà máy B, chuyện này không chốt từ đầu thì lúc chạy là một mớ bòng bong, bài [Quản trị truy cập Cloud ERP: bài toán IAM](/posts/quan-tri-truy-cap-cloud-erp-bai-toan-iam/) mổ kỹ vấn đề này. Đóng kỳ kế toán là cái thứ hai, cuối tháng phải đóng kỳ, không ai được sửa chứng từ kỳ đã đóng, ai được mở lại kỳ, quy trình mở lại thế nào, NFR này mà quên thì kế toán trưởng sẽ tìm bạn đầu tiên. Batch đêm là cái thứ ba, nhiều tác vụ nặng của ERP chạy ban đêm như tính giá thành, chốt tồn kho, đồng bộ dữ liệu, cần chốt rõ tác vụ nào chạy lúc nào, chạy bao lâu, fail thì cảnh báo cho ai. Khối lượng dữ liệu sau migration là cái cuối, chuyển dữ liệu từ hệ cũ sang xong thì bảng có thể phình to, báo cáo chạy nhanh với vài nghìn dòng chưa chắc còn nhanh với vài trăm nghìn dòng. Lưu ý là bản thân việc chuyển dữ liệu là transition requirement theo BABOK, còn NFR ở đây là hiệu năng sau khi dữ liệu đã vào. ## đưa NFR vào đâu NFR không phải thứ để cuối cùng mới nghĩ tới. Trong tài liệu truyền thống nó nằm trong SRS, có mục riêng cho yêu cầu phi chức năng, còn trong Agile thì rải rác, trong acceptance criteria của từng story, trong Definition of Done của team, hoặc trong một trang yêu cầu chung mà story nào cũng phải tôn trọng. Hiểu lầm hay gặp là NFR là việc của kiến trúc sư hay dev, BA chỉ lo chức năng. Kiến trúc sư quyết cách đáp ứng, nhưng con số bao nhiêu là đủ phải tới từ nghiệp vụ, kế toán chờ báo cáo cuối tháng được bao lâu, xưởng mất mạng thì có quét mã vạch tiếp được không, và người hỏi được mấy câu đó là BA. Đặt ở đâu cũng được, miễn là nó được ghi ở chỗ có người chịu trách nhiệm, chứ đừng để ai cũng nghĩ người khác lo. ## hỏi NFR từ buổi khảo sát đầu tiên Phát hiện thiếu NFR muộn nhất là lúc go-live, khi dữ liệu thật đổ vào và người dùng thật bấm vào, lúc đó sửa là tốn nhất, nên ngay từ buổi khảo sát đầu hãy dành một phần câu hỏi cho hiệu năng, phân quyền và audit, đừng chỉ hỏi màn hình cần những gì. Muốn biết NFR nằm ở đâu trong bộ tài liệu thì đọc [BRD, SRS, FS khác nhau thế nào](/posts/brd-srs-fs-khac-nhau-the-nao/), còn kiểm NFR bằng dữ liệu thật trước go-live thì có bài [UAT cho dự án ERP](/posts/uat-kich-ban-uat-du-an-erp/). NFR nào từng làm bạn bị vả lúc go-live? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Từ BA sang tư vấn ERP: khác gì, chọn mảng nào, bắt đầu từ đâu - URL: https://quanlamba.com/posts/tu-ba-sang-tu-van-erp/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, ERP, Chuyển ngành BA, Hướng nghiệp - Mô tả: Tư vấn ERP khác BA phần mềm ở chỗ map quy trình vào sản phẩm có sẵn. Bài so hai nghề, cách chọn mảng nghiệp vụ đầu tiên và ba cửa vào nghề. Nếu ngày mai bạn thôi viết user story mà bắt đầu ngồi cãi với kế toán trưởng về cách ghi nhận công nợ, bạn có chịu nổi một tháng không, theo mình câu đó quan trọng hơn con số lương trên tin tuyển ERP Functional Consultant. BA phần mềm với tư vấn ERP dùng chung nhiều kỹ năng, nhưng một ngày làm việc thì khác nhau khá xa. ## ERP functional consultant làm gì mỗi ngày ERP functional consultant giúp doanh nghiệp triển khai một hệ thống ERP có sẵn như SAP, Oracle hay IFS Cloud sao cho khớp cách công ty vận hành, bạn không xây phần mềm mới mà map quy trình nghiệp vụ vào sản phẩm, rồi cấu hình sản phẩm cho đúng. Một chu kỳ triển khai thường đi qua workshop khảo sát với mua hàng, kế toán, kho, xưởng, rồi fit-gap xem chỗ nào sản phẩm đáp ứng sẵn, cấu hình tham số, luồng duyệt, danh mục, viết FSD (functional specification document) cho phần cần phát triển thêm, chạy SIT (system integration test) và hỗ trợ UAT (user acceptance test), sau cùng là đào tạo người dùng, trực go-live và hỗ trợ sau đó. Nghe giống việc BA, và đúng là elicitation, viết tài liệu, test đều dùng lại được, cái khác nằm ở chỗ bạn đứng và thứ bạn phải giỏi. ## khác BA phần mềm ở đâu BA phần mềm thường đứng giữa người dùng và đội dev để thiết kế thứ chưa có, còn ERP consultant đứng giữa người dùng và một sản phẩm đã có, việc chính là quyết ai phải đổi, quy trình của khách hay sản phẩm. Kiểu khách yêu cầu gì build nấy hiếm khi chạy được, vì mỗi tùy biến là một khoản nợ khi nâng cấp phiên bản, cách ra quyết định này mình viết riêng trong bài [Fit-gap analysis ERP](/posts/fit-gap-analysis-trien-khai-erp/). Khác biệt thứ hai là nghiệp vụ nặng hơn giao diện. Bạn phải hiểu vì sao kế toán cần đối chiếu đơn mua, phiếu nhập kho và hóa đơn trước khi thanh toán, vì sao thủ kho không chịu nhập lô khi chưa có kết quả QC, giao diện đẹp xấu ít ai bàn, nhưng sai một tài khoản hạch toán thì cả phòng kế toán đi tìm bạn. | Tiêu chí | BA phần mềm | ERP functional consultant | | --- | --- | --- | | Sản phẩm | Xây mới theo yêu cầu | Có sẵn, cần cấu hình | | Việc chính | User story, mockup, làm việc với dev | Workshop, fit-gap, cấu hình, FSD, UAT | | Kiến thức nặng | Logic sản phẩm, trải nghiệm người dùng | Kế toán, kho, mua hàng, sản xuất | | Stakeholder chính | PO, dev, designer | Kế toán trưởng, thủ kho, trưởng bộ phận, key user | | Cao trào | Release, sprint review | Data migration, UAT, go-live | ## functional hay technical Mảng ERP hay chia hai nhánh, functional lo nghiệp vụ, cấu hình, tài liệu, đào tạo, còn technical lo SQL, PL/SQL hoặc ngôn ngữ riêng của sản phẩm, tích hợp, báo cáo, script migration. Từ dev sang thì technical là đường thuận, nhưng đừng coi functional là phần dễ, nó khó ở chỗ bạn phải hiểu nghiệp vụ đủ để nói không với kế toán trưởng mà vẫn được nghe. Theo mình hướng chắc nhất cho người mới là functional cộng thêm SQL đủ để tự kiểm dữ liệu, khỏi phải chờ team technical mỗi lần nghi số sai. ## chọn mảng nghiệp vụ đầu tiên Chẳng ai giỏi toàn bộ ERP ngay, chọn một mảng đi sâu trước dựa vào nền của bạn, nền kế toán thì Finance (công nợ phải trả, phải thu, tài sản), từng làm kho, vận tải thì Supply chain và Procurement, nền kỹ thuật, sản xuất thì Manufacturing hoặc Maintenance. Không có nền nào liên quan thì chọn mảng có quy trình dễ hình dung, procure-to-pay, từ yêu cầu mua tới thanh toán nhà cung cấp, là ứng viên tốt, vì ai cũng hiểu cần mua thì tạo yêu cầu, duyệt, đặt hàng, nhận hàng, trả tiền. Học kỹ một luồng như vậy, biết dữ liệu đi qua màn hình nào và ai duyệt ở đâu, là bạn có khung để học tiếp các luồng khác như order-to-cash. ## ba cửa vào nghề Cửa thứ nhất là vào một đối tác triển khai ERP, được đào tạo sản phẩm và đưa vào dự án sớm, đổi lại là onsite và deadline dày. Cửa thứ hai là vào team ERP nội bộ của một doanh nghiệp đang dùng hệ thống, nhịp chậm hơn, hiểu sâu một mảng. Cửa thứ ba là làm key user ngay ở công ty bạn đang làm nếu công ty có dự án ERP, ngồi UAT, viết hướng dẫn cho phòng mình, và có thứ cụ thể để kể khi đi phỏng vấn. Chứng chỉ thì để sau, các hãng lớn như SAP có chương trình chứng chỉ chính thức, nhưng theo mình chứng chỉ chỉ có trọng lượng khi bạn đã chạm vào hệ thống, học chứng chỉ trước giống học bơi trên cạn, thuộc động tác mà xuống nước vẫn đuối. ## chỗ người ta hay hiểu sai Nhiều người nghĩ ERP là nghề cũ, nhàm, BA phần mềm mới hiện đại, mình thấy nói vậy đúng một nửa. ERP ít hào nhoáng thật, không ship tính năng mỗi hai tuần, không demo giao diện bóng bẩy, nhưng một cấu hình sai có thể làm công nợ lệch cả tháng, và áp lực đó không nhẹ hơn một bản release lỗi. Hiểu sai thứ hai là chuyển sang ERP thì bắt đầu lại từ số 0, không đúng, kỹ năng hỏi, ghi, kiểm tra yêu cầu vẫn nguyên, phần phải học mới là nghiệp vụ và sản phẩm, mà phần này chỉ học nhanh khi bạn ngồi họp và chịu hỏi mấy câu nghe có vẻ ngớ ngẩn như vì sao phải duyệt hai lần. Cái giá thì nên biết trước, onsite tại nhà máy là chuyện thường, mấy tuần quanh data migration và go-live rất dài, và khách hay muốn hệ thống mới chạy y như file Excel cũ. Kỳ UAT là lúc mọi thứ lộ ra, bài [UAT cho dự án ERP](/posts/uat-kich-ban-uat-du-an-erp/) nói cách chuẩn bị cho đỡ vỡ. ## trước khi nộp đơn Tự trả lời ba câu, bạn có chịu được việc ít vẽ màn hình, nhiều đọc bút toán không, có tò mò về kế toán, kho, mua hàng không, có chấp nhận onsite và mấy tuần cao trào quanh go-live không. Cả ba đều có thì ERP đáng thử, còn nếu chỉ vì thấy lương ổn thì theo mình bạn sẽ nản khá nhanh. Đang phân vân giữa nhiều hướng sau vài năm làm BA thì bài [BA, PO, PM khác nhau thế nào](/posts/ba-po-pm-khac-nhau-chon-huong-nao/) đặt ERP consultant cạnh các lựa chọn khác. Bạn đang nghiêng về functional hay technical, và mảng nghiệp vụ nào làm bạn tò mò nhất? Trả lời mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # UAT cho dự án ERP: BA chuẩn bị kịch bản thế nào để không vỡ - URL: https://quanlamba.com/posts/uat-kich-ban-uat-du-an-erp/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, ERP, Go-live, Kỹ năng BA - Mô tả: UAT dự án ERP hay hỏng ở khâu chuẩn bị. Cách BA viết kịch bản end-to-end, chuẩn bị dữ liệu, phân loại lỗi và chốt tiêu chí sign-off. Nhiều đợt UAT trong dự án ERP hỏng từ trước khi ai bấm nút đầu tiên, kịch bản viết theo màn hình, dữ liệu test toàn abc, chẳng ai thống nhất thế nào là đạt, tới tuần test thì key user bận, lỗi nào cũng bị ném vào một sheet chung, và buổi sign-off thành buổi cãi nhau. Nếu bạn là BA được giao chuẩn bị UAT, phần lớn việc của bạn nằm ở trước tuần test. ## UAT đứng ở đâu UAT (User Acceptance Test) là đợt kiểm tra cuối cùng, do người dùng nghiệp vụ làm, để xác nhận hệ thống đáp ứng đúng công việc thật của họ, nó đứng cuối chuỗi kiểm thử, unit test (dev test từng hàm) → SIT (team dự án test tích hợp) → UAT (người dùng test) → go-live. Điểm khác quan trọng là UAT để người dùng trả lời câu hệ thống này có giúp mình làm xong việc hằng ngày không, còn bug kỹ thuật lẽ ra phải bị bắt ở SIT rồi. Người test là kế toán, thủ kho, trưởng phòng mua hàng chứ không phải dev, và theo ngôn ngữ BABOK Guide v3, chuẩn bị tiêu chí đạt cho UAT gần với kỹ thuật Acceptance and Evaluation Criteria (10.1). ## vai của BA trong UAT Nhiều BA mới tưởng mình phải test thay người dùng, không phải đâu, việc của BA là chuẩn bị kịch bản, chuẩn bị dữ liệu, hướng dẫn key user cách test và phân loại kết quả, còn người dùng nghiệp vụ là người bấm nút và ký xác nhận. Lý do đơn giản, BA không làm kế toán mỗi ngày nên không biết một kế toán thật sẽ nhìn vào con số nào, đối chiếu cái gì, chỉ người làm việc thật mới phát hiện được kiểu cái này đúng nhưng không dùng được. ## viết kịch bản theo quy trình end-to-end Lỗi phổ biến là viết kịch bản theo màn hình, kiểu màn hình tạo đơn mua có những field nào, test được màn hình nhưng bỏ sót lỗi ở chỗ nối giữa các màn hình. Cách tốt hơn là theo quy trình end-to-end, ví dụ procure-to-pay thì một kịch bản nên chạy trọn tạo đề nghị mua → duyệt → tạo đơn mua (PO) → nhận hàng → nhập hóa đơn → thanh toán, chạy trọn luồng mới thấy chỗ nào dữ liệu bị đứt, chỗ nào số liệu lệch giữa các bước. ## mẫu cột cho một test script Một test script gọn nên có các cột ID, quy trình, bước thực hiện, dữ liệu đầu vào, kết quả mong đợi, kết quả thực tế, pass/fail, người test, ghi chú. Kết quả mong đợi là cột quan trọng nhất vì nó quyết định pass hay fail, ví dụ bước nhận hàng thì mong đợi là số lượng tồn kho tăng đúng bằng số lượng nhận, và đơn mua chuyển trạng thái sang đã nhận một phần hoặc đã nhận đủ, không ghi rõ mong đợi thì người test chẳng biết mình đang kiểm cái gì. ## dữ liệu và môi trường UAT cần dữ liệu giống thật thì test mới có ý nghĩa, dữ liệu kiểu abc, 123 chạy được màn hình nhưng không lòi ra lỗi nghiệp vụ. Tốt nhất là dùng chính dữ liệu đã migration thử, chuyển từ hệ cũ sang rồi để key user test trên đó, vì đó cũng là dữ liệu họ sẽ dùng thật khi go-live, chuẩn bị dữ liệu migration thế nào thì đọc [Data migration: những cái bẫy không ai nói trước](/posts/data-migration-nhung-cai-bay-khong-ai-noi-truoc/). ## quản lý lỗi, ba loại khác nhau UAT phát hiện vấn đề thì đừng ném hết vào một giỏ lỗi, chia ra ba thứ. Bug hệ thống là hệ thống chạy sai so với thiết kế, như báo cáo tồn kho cộng sai số, cái này phải sửa. Change request là yêu cầu mới ngoài phạm vi đã chốt, kiểu em muốn thêm một cột vào màn hình này, không phải bug mà là phạm vi mới, cần đánh giá riêng và có thể tính phí, thấy nó lẽ ra phải xử lý từ trước thì quay lại bảng [fit-gap](/posts/fit-gap-analysis-trien-khai-erp/) xem gap đó đã có người quyết chưa. Vấn đề đào tạo là người dùng chưa biết dùng chứ hệ thống không sai, xử lý bằng đào tạo lại chứ không phải sửa hệ thống. Chia đúng ba loại này thì bạn không bị ngập trong một đống lỗi lẫn lộn. ## sign-off và tiêu chí vào go-live UAT kết thúc bằng sign-off, người dùng nghiệp vụ ký xác nhận hệ thống đạt yêu cầu, nhưng sign-off không nên là test xong rồi ký, phải có tiêu chí rõ từ trước, bao nhiêu phần trăm kịch bản pass, lỗi nào là chặn (blocker) không thể go-live, lỗi nào chấp nhận tạm rồi sửa sau, và tiêu chí đó phải thống nhất trước khi UAT bắt đầu chứ không phải sát go-live mới cãi. ## khi key user bận hoặc không hợp tác Tình huống hay gặp là key user ngập việc thường ngày, không có thời gian test, hoặc coi test là việc của dự án nên đùn đẩy. Cách xử lý nằm ở chỗ xác định đúng trách nhiệm từ đầu, UAT là việc của người dùng chứ không phải giúp dự án, bạn cần cam kết của quản lý phía khách hàng và một lịch test rõ ràng. ## chốt tiêu chí trước ngày test đầu tiên Nếu chỉ làm một việc từ bài này thì hãy chốt tiêu chí sign-off bằng văn bản trước ngày test đầu tiên, UAT là đợt kiểm tra cuối do chính người dùng làm trước go-live, lỗi lọt qua đây sẽ thành lỗi thật, tốn tiền thật. Sau UAT thì go-live chuẩn bị những gì, đọc [Go-live: chuẩn bị gì, sai gì, sửa gì](/posts/go-live-chuan-bi-gi-sai-gi-sua-gi/). Bạn đã từng làm UAT chưa, có gặp key user nào mất tích đúng lúc cần test không? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Use case vs user story: khác nhau ở đâu, khi nào dùng cái nào - URL: https://quanlamba.com/posts/use-case-vs-user-story/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, User Story, Fresher, Agile - Mô tả: Use case vs user story: viết cùng chức năng hoàn tiền đơn trả hàng theo hai cách để thấy khác biệt. Kèm cách chọn cho dự án Agile, ERP và lỗi hay gặp. Phỏng vấn hỏi use case và user story khác nhau thế nào thì bạn trả lời bằng định nghĩa hay bằng một ví dụ, nhiều ứng viên chọn định nghĩa, và câu trả lời của ai nghe cũng giống hệt nhau. Cách thuyết phục hơn là viết cùng một chức năng theo cả hai kiểu, rồi chỉ ra lúc nào kiểu nào giúp dự án đỡ cãi nhau. ## hai định nghĩa trong hai câu User story là một câu mô tả ngắn nhu cầu của một vai trò, theo mẫu quen thuộc As a [vai trò], I want [điều gì], so that [lợi ích], nó thiên về câu hỏi tại sao. Use case là một đặc tả chi tiết cách một actor tương tác với hệ thống để đạt một mục tiêu, nó thiên về câu hỏi chạy thế nào. Nói gọn thì user story trả lời cần gì, còn use case trả lời làm sao. BABOK Guide v3 cũng tách chúng thành hai kỹ thuật riêng: Use Cases and Scenarios (10.47) và User Stories (10.48). ## cùng một chức năng, hai cách viết Lấy ví dụ chức năng hoàn tiền cho đơn trả hàng trên một sàn thương mại điện tử, tình huống giả định thôi, tuần sau đợt sale lớn, nhân viên chăm sóc khách hàng ngồi trước vài trăm yêu cầu hoàn tiền, khách thì nhắn liên tục hỏi "bao giờ tiền về". Viết theo user story thì gọn: "As a nhân viên chăm sóc khách hàng, I want duyệt hoàn tiền cho đơn trả hàng đã được kho xác nhận, so that khách nhận lại tiền nhanh mà không phải chờ kế toán xử lý tay." Kèm acceptance criteria: - Hệ thống chỉ hiển thị các đơn trả hàng mà kho đã xác nhận nhận lại hàng. - Nhân viên được duyệt hoặc từ chối hoàn tiền, từ chối thì bắt buộc nhập lý do. - Sau khi duyệt, hệ thống ghi lại người duyệt, thời gian và số tiền hoàn. Viết theo use case thì dài hơn hẳn, và có cấu trúc cố định: - Actor: Nhân viên chăm sóc khách hàng. - Tiền điều kiện: đơn trả hàng đã được kho xác nhận và chưa được hoàn tiền. - Luồng chính: hệ thống hiển thị danh sách đơn chờ hoàn tiền; nhân viên chọn một đơn; hệ thống hiển thị chi tiết đơn và phương thức thanh toán gốc; nhân viên chọn duyệt; hệ thống tạo lệnh hoàn tiền về phương thức gốc và gửi thông báo cho khách. - Luồng thay thế: nếu số tiền hoàn vượt ngưỡng (ví dụ 5 triệu đồng), hệ thống chuyển cho trưởng nhóm duyệt thay vì cho phép duyệt ngay. - Ngoại lệ: nếu cổng thanh toán từ chối lệnh hoàn (thẻ đã hủy, ví đã khóa), hệ thống chuyển đơn sang trạng thái chờ hoàn thủ công và báo cho kế toán. - Ngoại lệ: nếu đơn đã được nhân viên khác hoàn trước đó, hệ thống báo lỗi và không cho hoàn lần hai. - Hậu điều kiện: đơn chuyển sang trạng thái đã hoàn tiền, bị từ chối, hoặc chờ hoàn thủ công. Cùng một việc mà user story chỉ vài dòng, còn use case thì cả chục dòng, đủ các nhánh rẽ và ngoại lệ. | Tiêu chí | User story | Use case | | --- | --- | --- | | Mức chi tiết | Thấp, một câu | Cao, đặc tả đầy đủ luồng | | Người đọc | Team phát triển, PO | Team phát triển, tester, khách hàng | | Thời điểm viết | Liên tục trong sprint | Đầu dự án hoặc khi thiết kế chức năng | | Trả lời | Cần gì, vì sao | Chạy thế nào | ## phần so that hay bị viết bừa Theo mình chỗ user story hay hỏng nhất không phải là ai hay muốn gì, mà là phần để làm gì, người ta viết đủ vai trò, đủ chức năng, rồi tới vế so that thì điền đại một lợi ích nghe hợp lý, đọc thì xuôi mà thường không đúng ý end user, chỉ là giả định với đoán mò. Muốn viết đúng vế đó thì không có đường tắt, phải làm elicitation với end user cho tử tế, interview trực tiếp được thì hỏi thật sâu, tại sao anh chị làm như vậy, việc này có ý nghĩa gì với anh chị, còn không interview được, hoặc họ làm quen tay tới mức không giải thích được, thì chuyển sang observation, ngồi xem quy trình làm việc thực tế của họ. Còn viết sao cho dev đọc cũng hiểu, theo mình vế so that nên nói ra hậu quả cụ thể nếu thiếu chức năng thay vì một lợi ích chung chung. Giả sử một nhân viên kho cần lọc phiếu nhập theo nhà cung cấp, viết "so that làm việc hiệu quả hơn" thì dev đọc xong vẫn không biết nên ưu tiên gì. Viết "so that đối chiếu được phiếu nhập với hóa đơn của từng nhà cung cấp mà không phải dò cả danh sách" thì dev hiểu ngay ai dùng, dùng lúc nào, và tự đoán được bộ lọc cần nhanh tới đâu. Câu "so that" mà đọc xong không trả lời được "thiếu nó thì ai khổ" thì mình coi là chưa xong. ## khi nào dùng cái nào Chẳng có cái nào tốt hơn tuyệt đối, câu hỏi đúng là dự án của bạn thuộc loại nào. Dự án Agile hoặc product thì user story là chủ đạo, backlog chứa user story, dev nhận story kèm acceptance criteria rồi làm, use case chỉ dùng cho mấy luồng phức tạp, nhiều ngoại lệ, chỗ mà vài dòng acceptance criteria không gánh nổi. Dự án ERP hoặc outsource cố định phạm vi thì ngược lại, vì hệ thống đã có sẵn nên người ta viết use case hoặc FS cho phần gap, chỗ cần cấu hình hoặc phát triển thêm (cách xác định gap có trong bài [Fit-gap analysis ERP](/posts/fit-gap-analysis-trien-khai-erp/)). User story vẫn có thể dùng để chia nhỏ việc, nhưng tài liệu chính là đặc tả chi tiết. Hiểu gọn thì user story dùng khi bạn muốn chia việc nhanh và thay đổi linh hoạt, còn use case dùng khi bạn cần chốt chặt luồng để tránh tranh cãi về sau. ## use case diagram, vẽ khi nào là đáng Use case diagram là sơ đồ thể hiện các actor và các use case của hệ thống, cùng quan hệ giữa chúng, nó không mô tả chi tiết từng bước mà cho thấy ai dùng được gì và ranh giới hệ thống nằm đâu. Vẽ nó đáng công trong hai trường hợp, một là lúc thống nhất phạm vi, cho khách hàng thấy hệ thống sẽ phục vụ những actor nào, làm được những gì, hai là khi có nhiều actor và quyền khác nhau, cần một bức tranh tổng để không sót. Còn luồng đơn giản, ít actor thì diagram thường không đáng công vẽ, đừng vẽ cho có. ## lỗi hay gặp Lỗi đầu tiên là story quá to, gói cả một module thì không còn là story nữa, chẳng ai ước lượng được, story nào cần cả tuần mới xong thì nên chẻ nhỏ. Lỗi thứ hai là use case viết như hướng dẫn click UI, đặc tả người dùng bấm nút A rồi bấm nút B thì thành hướng dẫn sử dụng mất rồi, use case nên mô tả mục tiêu và luồng nghiệp vụ, không mô tả từng cú click. Lỗi thứ ba là nhầm mức độ, dùng use case cho mọi thứ trong Agile thì nặng nề, còn chỉ dùng user story duy nhất cho dự án ERP cố định phạm vi thì thiếu chi tiết, đến lúc test lại cãi nhau. Lỗi thứ tư là bỏ sót luồng ngoại lệ, và đây chính là lý do use case vẫn tồn tại, nó bắt bạn nghĩ tới chuyện người dùng nhập sai, mất kết nối, cổng thanh toán từ chối lệnh hoàn, mấy thứ user story hay bỏ qua. ## chọn theo loại dự án Đừng chọn use case hay user story như chọn phe, xem dự án của bạn cần gì, linh hoạt thì user story, chốt chặt thì use case. BA giỏi là người dùng được cả hai đúng chỗ. Muốn viết user story và acceptance criteria cho chuẩn thì đọc [User story và acceptance criteria: viết sao cho dev không hỏi lại](/posts/user-story-acceptance-criteria/), còn muốn biết use case nằm ở đâu giữa BRD, SRS và FS thì xem [BRD, SRS, FS khác nhau thế nào](/posts/brd-srs-fs-khac-nhau-the-nao/). Chỗ bạn đang làm dùng user story hay use case, và có khi nào bị bắt đổi từ cái này sang cái kia không? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Wireframe, mockup, prototype: BA cần làm tới đâu là đủ - URL: https://quanlamba.com/posts/wireframe-mockup-prototype-ba-lam-toi-dau/ - Ngày đăng: 2026-10-29 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, Fresher - Mô tả: Wireframe, mockup, prototype khác nhau ở mục đích và độ chi tiết. BA vẽ wireframe để chốt luồng và dữ liệu, kèm điều JD tuyển BA đang đòi. Giả sử bạn gửi khách một wireframe xám để chốt luồng màn hình đề nghị mua hàng, và phản hồi đầu tiên là giao diện thế này người dùng không chịu đâu, đổi sang màu logo công ty nhé, thế là cả buổi họp sau đó bàn màu, còn câu bạn cần chốt là duyệt xong thì đề nghị đi đâu thì chẳng ai trả lời. Chuyện này dễ xảy ra khi hai bên chưa thống nhất đang xem loại bản vẽ nào, vì wireframe, mockup và prototype trả lời ba câu hỏi khác nhau, mà BA thường chỉ cần sở hữu một. ## bốn mức độ, một bảng Sketch là phác thảo tay, vẽ nhanh trên giấy để mình tự nghĩ, wireframe là khung xương đen trắng thể hiện bố cục, có những khối nào, field nào, nút nào, bấm thì đi đâu, mockup là bản có màu sắc, font chữ, gần giống sản phẩm thật, còn prototype là bản tương tác được, bấm vào là chuyển màn hình. BABOK Guide v3 xếp chung mấy dạng này vào kỹ thuật Prototyping (10.36). | Mức | Mục đích | Độ chi tiết | Ai thường làm | | --- | --- | --- | --- | | Sketch | Nghĩ nhanh | Thô nhất | BA, ai cũng được | | Wireframe | Chốt bố cục, luồng, dữ liệu | Thấp | BA | | Mockup | Chốt giao diện, màu sắc | Cao | Designer | | Prototype | Mô phỏng tương tác | Cao | Designer hoặc BA | ## BA làm tới đâu Ranh giới đơn giản thôi, BA vẽ wireframe để chốt luồng và dữ liệu, không chốt màu. Wireframe trả lời câu hỏi nghiệp vụ, màn hình có những trường nào, người dùng nhập gì, bấm nút nào thì đi đâu, lỗi hiện ở đâu, còn màu xanh hay đỏ, font to hay nhỏ là việc của designer. Thế nên wireframe không cần đẹp mà cần đúng, đúng field, đúng luồng, đúng trạng thái, một wireframe vẽ bằng ô vuông với chữ xám mà đủ thông tin vẫn hơn một mockup bóng bẩy thiếu trường dữ liệu. Khi luồng và dữ liệu đã chốt xong thì giao cho designer, họ nhận wireframe rồi làm đẹp thành mockup. ## JD đang nói gì Đọc vài tin tuyển BA ở Hà Nội năm 2026 thì yêu cầu về vẽ giao diện khác nhau khá rõ giữa các chỗ. Tin Senior BA của Edufy ghi trong mô tả công việc "Xây dựng tài liệu đặc tả yêu cầu phần mềm theo nhiều hình thức: Tài liệu mô tả, tài liệu thiết kế giao diện mẫu (prototype) và các tài liệu liên quan khác", và yêu cầu biết công cụ vẽ mockup như Visio, Axure, Figma ([tin trên 123job](https://www.123job.vn/viec-lam/phan-tich-nghiep-vu-ba-senior-business-analyst-thu-nhap-upto-40000000-tai-ha-noi-PDbov84J9R), đã hết hạn). Tin Senior BA BHXH của MISA yêu cầu dùng thành thạo Jira, Figma, draw.io ([tin trên Devwork](https://www.devwork.vn/viec-lam/14253/senior-ba-bhxh), đã hết hạn). Ở mức fresher, tin của Huvisoft xếp wireframe cạnh user story, use case, acceptance criteria trong nhóm tài liệu BA phải làm ([tin trên Joboko](https://vn.joboko.com/viec-lam-business-analyst-fresher-junior-luong-8-12-trieu-xvi6765195)). Tức là vẽ được wireframe và dùng được một công cụ như Figma đang là yêu cầu thật chứ không chỉ là điểm cộng, nhưng không tin nào trong số này đòi BA làm visual design, thấy chữ Figma thì học đủ để vẽ khung, không cần thành designer. ## khi không có designer Nhiều dự án không có designer, nhất là dự án nội bộ hoặc ERP, lúc đó BA có thể phải làm luôn phần mockup đơn giản. Dự án ERP thì có nét riêng là màn hình đã có sẵn trong sản phẩm, bạn không vẽ lại từ đầu mà chụp màn hình chuẩn của hệ thống rồi chú thích chỗ nào cấu hình gì, thêm bớt field nào, chỉ phần phát triển thêm (custom) mới cần vẽ wireframe cho màn hình mới, khác hẳn dự án phần mềm xây mới nơi màn hình nào cũng phải vẽ từ con số không. ## gắn wireframe vào tài liệu thế nào Wireframe không nên nằm riêng một góc không ai nhìn, nó nên gắn thẳng vào tài liệu yêu cầu, trong FS thì mỗi chức năng kèm một ảnh wireframe, trong user story thì đính kèm để dev nhìn là hiểu. Cách làm đơn giản là đặt mỗi màn hình ngay dưới phần mô tả chức năng tương ứng, kèm chú thích field và rule, người đọc khỏi phải lật qua lật lại. ## đưa wireframe vào portfolio Wireframe là một trong những thứ dễ đưa vào portfolio nhất, vì nó thể hiện tư duy của bạn mà không cần dự án thật, chọn một quy trình quen thuộc, vẽ màn hình as-is và to-be, kèm giải thích vì sao to-be tốt hơn. Cách làm case simulation có trong bài [Portfolio BA khi chưa có dự án](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/), và nhớ là wireframe trong portfolio phải đi kèm lời giải thích, chứ đừng chỉ là một đống ảnh. ## chốt luồng trước, chốt màu sau Đừng nhầm wireframe với thiết kế cuối, việc của BA là chốt luồng và dữ liệu bằng wireframe, chuyện màu mè để designer lo, nắm được ranh giới này thì vừa đỡ tốn thời gian, vừa không bị khách hiểu nhầm. Wireframe gắn vào FS thế nào cho dev đọc được thì xem thêm [BRD, SRS, FS khác nhau thế nào](/posts/brd-srs-fs-khac-nhau-the-nao/), còn viết user story đi kèm wireframe cho khớp thì có bài [User story và acceptance criteria](/posts/user-story-acceptance-criteria/). Bạn đang vẽ wireframe bằng công cụ gì, và đã bao giờ bị khách tưởng wireframe là thiết kế cuối chưa? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Tự học BA từ đâu, mất bao lâu? Lịch 6–9 tháng cho người mới - URL: https://quanlamba.com/posts/tu-hoc-ba-6-9-thang-lich-that/ - Ngày đăng: 2026-10-25 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Học tập, Hướng nghiệp, Fresher - Mô tả: Tự học BA từ đâu và mất bao lâu? Lịch 6–9 tháng chia theo giai đoạn: nền tảng, user story, dữ liệu, rồi portfolio và phỏng vấn thử. **Trả lời ngắn:** Theo mình, người mới tự học BA mất khoảng 6–9 tháng nếu học đều và đúng thứ tự, bắt đầu từ nền tảng (BA làm gì, requirement là gì), rồi tới user story và tài liệu, sau đó là dữ liệu và giao tiếp, cuối cùng là portfolio và phỏng vấn thử. Lời hứa ba tháng thành BA nghe rất ngọt, mà cũng rất dễ làm người mới nản, vì ba tháng đủ để bạn biết BA là gì, thuộc vài thuật ngữ, vẽ được một cái sơ đồ, còn để ngồi phỏng vấn mà trả lời được câu vì sao em viết requirement như vậy thì cần lâu hơn thế. Bài này là cái lịch mình thấy sát thực tế cho người tự học, chia theo giai đoạn, giai đoạn nào cũng có việc cụ thể để làm. ## tháng 1–2 hiểu nghề trước, chưa đụng tool Câu đầu tiên cần trả lời được là BA tạo ra giá trị gì cho tổ chức. Đọc phần đầu BABOK Guide v3 để nắm sáu khái niệm nền mà BABOK gọi là Business Analysis Core Concept Model, gồm change, need, solution, stakeholder, value, context, theo mình đây là phần đáng nắm chắc nhất trước khi học bất kỳ kỹ thuật nào, còn sợ ngủ gật với cuốn sách dày thì xem bài [BABOK đọc sao cho không ngủ gật](/posts/babok-doc-sao-cho-khong-ngu-gat/). Việc cụ thể cuối tháng 2 là tự viết một trang giải thích cho người không làm IT hiểu BA làm gì, dùng một ví dụ đời thường như quy trình đăng ký môn học, viết mà vẫn phải mượn thuật ngữ để che chỗ chưa hiểu thì quay lại đọc tiếp. Chưa mở Jira hay Figma vội, vì cầm tool trước khi hiểu vấn đề thì bạn sẽ nhớ nút bấm mà chẳng biết bấm để làm gì, tool học vài buổi là quen, tư duy thì không. ## tháng 3–4 user story, acceptance criteria và tài liệu Đây là giai đoạn ra sản phẩm đầu tiên để khoe, học viết user story, viết acceptance criteria theo Given-When-Then, phân biệt functional với non-functional requirement, đọc thử cấu trúc BRD và SRS. Bài tập viết user story tại chỗ khá phổ biến trong phỏng vấn BA fresher, nên phần này đáng đầu tư kỹ, bài [User story và acceptance criteria](/posts/user-story-acceptance-criteria/) đi từng bước từ câu story tới tiêu chí nghiệm thu. Việc cụ thể cuối tháng 4 là chọn một app bạn dùng hằng ngày, viết 10 user story cho một tính năng của nó, mỗi story 3–5 acceptance criteria, rồi tự đóng vai tester đọc lại xem tiêu chí có test được không, chỗ nào phải hỏi lại người viết là chỗ còn mơ hồ. ## tháng 5–6 dữ liệu và giao tiếp Tới đây mới học SQL ở mức đủ sống, SELECT, JOIN, GROUP BY, mục tiêu là tự mở dữ liệu ra trả lời câu kiểu mỗi tháng có bao nhiêu đơn bị hủy, chứ không phải viết stored procedure, học kèm cách đọc ERD để hiểu vì sao dữ liệu nằm rải ở nhiều bảng. Song song là phần khó tự học nhất, giao tiếp. Tập đặt câu hỏi mở, tập hỏi để làm gì sau mỗi yêu cầu, tập tóm tắt lại điều người khác vừa nói, không có stakeholder thật thì nhờ bạn bè đóng vai chủ quán cà phê muốn làm app đặt món, bạn phỏng vấn họ 30 phút rồi viết lại thành danh sách requirement. Cuối tháng 6 bạn nên cầm được một bộ 10 câu SQL tự viết trên dữ liệu mẫu, cùng một biên bản phỏng vấn giả lập có danh sách requirement rút ra. ## tháng 7–9 portfolio và phỏng vấn thử Giờ bạn đủ vốn làm một case simulation hoàn chỉnh, có bối cảnh, sơ đồ as-is, pain point, to-be, user story kèm acceptance criteria, một case làm sâu đáng giá hơn nhiều case làm nông, cách dựng từng phần nằm trong bài [Portfolio BA khi chưa có dự án](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/). Rồi đi phỏng vấn thử, kể cả ở những chỗ chưa chắc muốn vào, mục đích là biết mình hổng ở đâu, mỗi buổi xong ghi lại câu nào trả lời lúng túng rồi quay về học đúng chỗ đó. Tháng thứ 9 là khoảng dự phòng cho mấy lỗ hổng này, đừng tiêu nó vào việc học thêm tool mới. ## chỗ người tự học hay sai Lỗi phổ biến nhất là học kiểu sưu tầm, lưu hàng chục khóa miễn phí, đọc mười bài về BPMN mà chưa vẽ nổi một sơ đồ của riêng mình, cảm giác học rất nhiều nhưng tới lúc phỏng vấn thì chẳng có gì để đưa ra. Cách sửa đơn giản là mỗi giai đoạn phải kết thúc bằng một sản phẩm cầm được trên tay, trang giải thích nghề, bộ user story, bộ câu SQL, case portfolio, chưa có sản phẩm thì giai đoạn đó chưa xong, dù bạn đã cày hết bao nhiêu video. Lỗi thứ hai là so tốc độ với người khác, có người đi làm full-time vẫn học được mỗi tối, có người chỉ có cuối tuần. Lịch 6–9 tháng là khung tham khảo theo quan điểm của mình chứ không phải hạn chót, kéo dài lên 12 tháng mà vẫn đều tay vẫn hơn ba tháng nhồi rồi bỏ. ## tự học có hợp với bạn không Nói thẳng là tự học không hợp với tất cả mọi người, nếu bạn cần người nhắc deadline, cần có lớp để giữ nhịp, thì một khóa có cấu trúc giúp bạn đi hết đường hơn, tự học rẻ hơn nhưng đòi kỷ luật cao hơn, mà kỷ luật cũng là một chi phí. Chọn tự học thì dán lịch này lên tường, mỗi tháng tự kiểm tra sản phẩm của giai đoạn đó xong chưa. Bạn đang ở tháng thứ mấy, và đang kẹt ở giai đoạn nào? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Dev muốn chuyển sang BA thì nên làm gì? Hỏi tại sao trước khi code - URL: https://quanlamba.com/posts/tu-dev-chuyen-sang-ba/ - Ngày đăng: 2026-10-18 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Chuyển ngành BA, Lập trình, Hướng nghiệp - Mô tả: Dev muốn chuyển sang BA nên làm gì? Tận dụng lợi thế kỹ thuật, tập hỏi tại sao trước khi code, và rẽ dần ngay trong công việc hiện tại. **Trả lời ngắn:** Dev muốn chuyển sang BA nên tận dụng lợi thế hiểu kỹ thuật, rồi tập thói quen hỏi để làm gì trước khi nghĩ cách làm. Không cần nghỉ việc, cứ rẽ dần bằng cách nhận phần làm rõ requirement, ngồi họp với user và viết tài liệu ngay trong dự án hiện tại. Dev chán code có nên sang BA không, câu hỏi này sai ngay từ đầu, vì chán code là lý do để rời một việc chứ chưa phải lý do để chọn việc tiếp theo. Câu đáng hỏi hơn là bạn có thích cái phần trước khi dòng code đầu tiên được viết không, cái phần mà mọi người cãi nhau xem rốt cuộc cần làm gì. Mình đi lên từ dev, nên bài này viết theo góc nhìn của người từng ngồi cả hai phía, không có công thức chung đâu, nhưng có vài thứ nên biết trước khi rẽ. ## lợi thế là bạn nói được tiếng của dev Dev sang BA có một lợi thế rõ, nghe requirement là hình dung được technical constraint, user muốn một màn hình tự cập nhật liên tục thì bạn biết ngay câu tiếp theo là dữ liệu lấy từ đâu, bao lâu refresh một lần, nghẽn thì sao, còn dev bên kia bàn nói cái này phải chạy batch qua đêm thì bạn hiểu và dịch lại được cho user bằng lời thường. Lợi thế thứ hai là bạn đọc được dữ liệu, biết bảng nào nối bảng nào, biết một field nullable nghĩa là gì, biết vì sao một yêu cầu "đơn giản" lại đụng tới ba hệ thống. Bài [Làm BA có cần biết code không](/posts/lam-ba-co-can-biet-code-khong/) bàn kỹ hơn chuyện kiến thức kỹ thuật giúp BA tới đâu. ## cái khó là bỏ phản xạ nhảy vào giải Dev giỏi là người nhìn vấn đề thấy ngay cách làm, mà với BA phản xạ đó lại hay hại. User nói thêm cho em một nút xuất Excel, con dev trong bạn đã chọn xong thư viện với format, còn BA thì phải hỏi ngược lại, xuất ra để làm gì, ai đọc, đọc xong quyết định gì. Nhiều khi hóa ra họ cần một báo cáo có sẵn, chẳng cần nút nào cả. BABOK Guide v3 xếp việc này vào Elicitation and Collaboration, tức khai thác thông tin từ stakeholder rồi xác nhận lại hiểu biết chung, nghe thì đơn giản, nhưng với người quen giải bài thì ngồi yên hỏi thêm ba câu là cả một bài tập kiềm chế. {{< compare title="Một yêu cầu, hai cách nhìn" >}} | Phản xạ dev | Phản xạ BA | |---|---| | Làm sao để chạy được | Chạy để giải quyết vấn đề gì | | Bug là lỗi cần sửa | Bug có thể là dấu hiệu requirement chưa rõ | | User nói gì làm nấy | User nói một chuyện, cần có thể là chuyện khác | {{< /compare >}} ## không phải dev nào cũng hợp làm BA Đừng nghĩ BA nhẹ hơn vì không phải code, nó mệt theo kiểu khác, dev mệt vì bug khó tìm, còn BA mệt vì stakeholder không nói hết, vì requirement đổi giữa sprint, vì đứng giữa user và dev mà bên nào cũng thấy mình chưa đủ. Cái hay bị đánh giá thấp nhất là cảm giác xong việc. Code thì có lúc test pass, merge xong, nhẹ cả người, còn việc BA hiếm khi có điểm kết rõ như vậy, tài liệu duyệt rồi vẫn có thể phải sửa, họp xong rồi vẫn còn câu hỏi treo. Chuyện dev sang BA một thời gian rồi quay về code không có gì lạ, cũng chẳng có gì sai, biết sớm mình hợp phía nào vẫn hơn. Thử tự hỏi xem một ngày tốt của bạn kết thúc bằng code chạy rồi, hay bằng mọi người cuối cùng cũng thống nhất cần làm gì. Nếu là vế sau thì đọc tiếp. ## rẽ sang BA mà không phải nghỉ việc Cách ít rủi ro nhất là bắt đầu ngay trong vai dev hiện tại, trước mỗi task đọc kỹ requirement và hỏi người viết ít nhất một câu để làm gì, ghi lại những chỗ bạn phải tự đoán, vì đó chính là chỗ requirement còn hổng, và cũng là bằng chứng bạn biết nhìn ra lỗ hổng. Tiếp theo là xin ngồi vào các buổi họp với user hoặc buổi grooming backlog, đừng chỉ ngồi nghe mà xung phong viết biên bản và tóm tắt requirement sau buổi họp, vài lần như vậy là bạn có sản phẩm thật để đưa vào hồ sơ, từ biên bản, user story tới sơ đồ quy trình tự vẽ. Phần kỹ thuật thì giữ lại nhưng đổi cách dùng, SQL giờ là để trả lời câu hỏi nghiệp vụ chứ không phải để viết tính năng, bài [SQL cho BA](/posts/sql-cho-ba-select-join-group-by-la-du-song/) nói rõ mức nào là đủ. Cũng nên chuẩn bị tinh thần cho mấy cú sốc đầu tiên khi sang vai mới, từ chuyện bị hỏi mà không có đáp án đúng tới chuyện viết tài liệu xong không ai đọc, bài [5 cú sốc của BA mới vào nghề](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/) liệt kê khá đủ. Chuyển từ dev sang BA rốt cuộc là đổi câu hỏi trong đầu, từ làm sao sang để làm gì, lợi thế kỹ thuật giúp bạn đi nhanh hơn người khác ở đoạn đầu, còn thói quen hỏi mới quyết định bạn đi được bao xa. Nếu bạn đang là dev, thứ làm bạn muốn đổi là bản thân việc code, hay là việc code những thứ chưa ai hỏi rõ để làm gì? Trả lời mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/) nhé. --- # Chưa có dự án thì portfolio BA viết gì? Làm case simulation - URL: https://quanlamba.com/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/ - Ngày đăng: 2026-10-17 - Cập nhật: 2026-11-05 - Thẻ: Portfolio, Business Analyst, Fresher, BA thực chiến - Mô tả: Chưa có dự án thì portfolio BA viết gì? Làm một case simulation 5 phần: bối cảnh, as-is, pain point, to-be, user story kèm acceptance criteria. **Trả lời ngắn:** Chưa có dự án thì portfolio BA nên là một case simulation, chọn một quy trình bạn quan sát được, vẽ as-is, chỉ ra pain point, đề xuất to-be và viết user story kèm acceptance criteria. Người tuyển fresher muốn thấy cách bạn nghĩ, và một case làm sâu là đủ để họ thấy điều đó. Lỗi phổ biến nhất của portfolio BA fresher là cố làm cho giống dự án thật, tên dự án thật kêu, logo công ty giả, sơ đồ copy trên mạng, mà không có chỗ nào cho thấy người làm đã tự nghĩ, người phỏng vấn hỏi một câu vì sao em chọn cách này là lộ ngay. Chưa có dự án không phải lý do để portfolio trống, nó chỉ có nghĩa là bạn phải tự tạo bài toán, rồi làm bài toán đó đến nơi đến chốn. ## người tuyển fresher nhìn gì trong portfolio Một CV fresher ghi giao tiếp tốt, tư duy logic, chịu được áp lực thì chẳng giúp ai phân biệt bạn với người khác, thứ giúp được là bằng chứng bạn nhìn vào một quy trình mà chỉ ra đúng chỗ đang tắc, chỗ đang thừa, rồi đề xuất cách sửa có lý do. Case simulation làm đúng việc đó, bạn không cần khách hàng, chỉ cần một quy trình có thật, có người làm, và có chỗ đang khó chịu. ## chọn quy trình nào để làm case Chọn thứ bạn từng ở bên trong hoặc quan sát được, như quy trình gọi món ở quán cà phê bạn làm thêm, đăng ký môn học ở trường, nhận trả sách ở thư viện, đặt lịch khám ở một phòng khám nhỏ, còn mấy thứ quá to như ERP cho tập đoàn thì né ra, vì bạn sẽ chỉ vẽ được cái vỏ. Tiêu chí của mình là quy trình có khoảng 4–7 bước, có ít nhất hai vai trò, và có ít nhất một chỗ dữ liệu bị chép tay hoặc gõ lại từ nơi này sang nơi khác, vì những chỗ chuyển giao như vậy thường là nơi lỗi và chậm trễ chui ra, rất đáng để phân tích. ## một case đủ dùng gồm năm phần Phần một là bối cảnh, chừng năm dòng, ai làm, làm ở đâu, quy trình nhắm tới cái gì, chưa phân tích gì ở đây cả. Phần hai là sơ đồ as-is, vẽ quy trình hiện tại bằng swimlane, mỗi vai trò một làn, chưa quen ký hiệu thì bài [BPMN cho người mới: vẽ as-is và to-be](/posts/bpmn-cho-nguoi-moi-as-is-to-be/) đủ để bạn bắt đầu. Phần ba là pain point, phần ăn điểm nhất. Đừng viết quy trình còn thủ công, hãy viết cụ thể và có ước lượng, ví dụ mỗi phiếu đăng ký phải gõ lại vào bảng tính, giả sử mất khoảng 3 phút một phiếu thì cả mùa đăng ký mất bao nhiêu giờ. Con số ước lượng thì được, miễn ghi rõ đó là ước lượng và bạn tính thế nào. Phần bốn là to-be, chỉ cần ba bốn thay đổi chính, mỗi thay đổi gắn với một pain point ở phần ba, đừng vẽ lại cả thế giới. Phần năm là requirement, ba đến năm user story, mỗi story có acceptance criteria theo Given-When-Then, cách viết từng câu có trong bài [User story và acceptance criteria](/posts/user-story-acceptance-criteria/). {{< info label="Mẹo" >}} Giữ cả case trong khoảng 8–10 trang. Ngắn và sắc thì người đọc đọc hết, dài và lan man thì họ lướt qua. {{< /info >}} ## một case sâu hơn năm case nông Nhiều bạn làm năm case, mỗi case một trang, mỗi case một lĩnh vực, nhìn thì đa dạng nhưng chẳng case nào đủ sâu để người đọc thấy bạn hiểu vấn đề tới đâu. Một case có as-is, có ước lượng, có to-be, lại thêm một đoạn tự phản biện kiểu áp dụng thay đổi này thì rủi ro là gì, ai sẽ phản đối, thường đáng giá hơn nhiều. Lúc phỏng vấn câu dễ gặp là vì sao em chọn giải pháp này, trả lời được câu đó là case đã làm xong nhiệm vụ, còn cách trả lời có cấu trúc thì xem bài [Phỏng vấn BA fresher: câu hỏi thật](/posts/phong-van-ba-fresher-cau-hoi-that/). ## đừng biến case giả thành kinh nghiệm thật Ghi case simulation thành "dự án tối ưu quy trình kho cho doanh nghiệp X" là tự đặt bẫy cho mình, người phỏng vấn chỉ cần hỏi vài câu về stakeholder, về ai ký duyệt, về lúc triển khai trục trặc gì, là câu chuyện bắt đầu hở. Ghi đúng thì đơn giản lắm, "case tự phân tích dựa trên quy trình mình quan sát, không phải dự án khách hàng", câu này không làm bạn mất điểm mà còn cho thấy bạn trung thực, một phẩm chất BA rất cần khi đứng giữa các bên. Ghi thêm công cụ bạn đã dùng, draw.io để vẽ, Google Docs hay Notion để viết, Jira bản miễn phí để quản lý backlog, người tuyển thấy bạn quen tool rồi thì bớt lo phần onboarding. Case simulation không biến bạn thành BA có kinh nghiệm, nó chỉ cho thấy bạn đã tập nghĩ như BA trước khi được trả lương để làm việc đó, mà với vị trí fresher thì thế đã là một lợi thế rõ. Nếu phải chọn một quy trình quanh mình để làm case đầu tiên, bạn chọn cái nào, và chỗ nào trong đó đang làm người làm khó chịu nhất? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/). --- # CBAP, CCBA hay ECBA: BA nên thi chứng chỉ nào? - URL: https://quanlamba.com/posts/chung-chi-ba-cbap-vs-ccba-vs-ecba-chon-cai-nao/ - Ngày đăng: 2026-10-11 - Cập nhật: 2026-11-05 - Thẻ: Chứng chỉ, CBAP, CCBA, ECBA, Business Analyst - Mô tả: CBAP, CCBA hay ECBA, BA nên thi cái nào? Chọn theo số giờ kinh nghiệm BA thật: ECBA cho người mới, CCBA 3.750 giờ, CBAP 7.500 giờ. **Trả lời ngắn:** Chọn chứng chỉ IIBA theo kinh nghiệm BA bạn thật sự có, chưa có kinh nghiệm thì thi ECBA, có khoảng 3.750 giờ (2–3 năm) thì thi CCBA, có 7.500 giờ (khoảng 5 năm trở lên) thì thi CBAP. Chọn chứng chỉ cao nhất cho oai là cách tốn tiền nhanh nhất. ECBA, CCBA, CBAP đều của IIBA, đều thi trên nền kiến thức BABOK Guide, nhưng mỗi cái nhắm một giai đoạn sự nghiệp khác nhau, đặt sai bậc thì hoặc bạn không đủ điều kiện nộp hồ sơ, hoặc mất mấy tháng ôn một thứ chưa giúp gì cho việc đang làm. Các con số trong bài lấy từ trang chứng chỉ chính thức của IIBA, mình đọc ngày 30/10/2026, điều kiện và giá có thể đổi nên trước khi đăng ký bạn mở lại mấy trang đó cho chắc. ## ECBA cho người chưa có kinh nghiệm BA Trang [ECBA của IIBA](https://www.iiba.org/business-analysis-certifications/ecba/) ghi rõ không yêu cầu kinh nghiệm, không có bước nộp hồ sơ duyệt, không cần khai giờ học, bài thi làm online có giám sát từ xa. Chỗ này khác với nhiều bài viết cũ trên mạng vẫn bảo ECBA cần giờ học, nên đừng tin mấy bảng so sánh cũ. ECBA hợp với sinh viên, người chuyển ngành và fresher. Theo mình giá trị của nó nằm ở chỗ bạn buộc phải đọc BABOK một lượt có hệ thống và nói chuyện được bằng thuật ngữ chung, còn chuyện nó tự mở cửa việc làm thì đừng kỳ vọng, giữa hai hồ sơ fresher ngang nhau nó là một tín hiệu cho thấy bạn đầu tư nghiêm túc, chỉ vậy thôi. Một chi tiết hữu ích cho người tự học là theo trang ECBA, gói thi đã gồm ECBA Learning Journey và một năm hội viên IIBA, trong đó có quyền đọc BABOK Guide bản online, nghĩa là chưa cần mua thêm tài liệu gì mới bắt đầu được. Cách ôn mình thấy hợp lý là đọc từng knowledge area, xong mỗi phần tự lấy một ví dụ ngoài đời để giải thích lại, rồi mới làm câu hỏi luyện tập, chứ học thuộc định nghĩa mà không gắn với ví dụ thì vào phòng thi rất dễ lẫn. ## CCBA cho người làm BA khoảng 2–3 năm Theo [trang CCBA của IIBA](https://www.iiba.org/business-analysis-certifications/ccba/), bạn cần 3.750 giờ kinh nghiệm BA trong 7 năm gần nhất, 21 giờ professional development trong 4 năm gần nhất và hai người tham chiếu, hồ sơ phải được IIBA duyệt rồi mới mua bài thi, bài thi dài 180 phút với 130 câu trắc nghiệm dạng tình huống. CCBA hay bị bỏ qua vì đứng kẹp giữa hai cái tên kia, nhưng với người làm được 2–3 năm, đang ở giai đoạn làm được việc mà chưa giải thích được vì sao làm vậy, quá trình ôn CCBA giúp đặt tên cho những thứ bạn vẫn làm theo bản năng. Phần nặng nhất trong blueprint CCBA là Requirements Analysis and Design Definition, chiếm 32%, đúng mảng việc hằng ngày của BA ở giai đoạn này. ## CBAP cho người từ khoảng 5 năm trở lên [Trang CBAP của IIBA](https://www.iiba.org/business-analysis-certifications/cbap/) yêu cầu 7.500 giờ kinh nghiệm BA trong 10 năm gần nhất, tính theo công việc BA bạn làm chứ không theo chức danh, bài thi 120 câu, 210 phút, thi online hoặc tại trung tâm khảo thí, và ba năm phải gia hạn một lần. CBAP hợp với người đã dẫn dắt phần việc BA trong dự án, cần một dấu xác nhận khi làm việc với cấp quản lý, với khách hàng, hoặc khi ứng tuyển ra nước ngoài. Có đáng bỏ thời gian và tiền cho CBAP không thì mình viết riêng trong bài [CBAP có đáng thi không](/posts/cbap-co-dang-thi-khong/). {{< compare title="So sánh nhanh (nguồn: iiba.org, đọc 30/10/2026)" >}} | | ECBA | CCBA | CBAP | |---|---|---|---| | Kinh nghiệm BA | Không yêu cầu | 3.750 giờ trong 7 năm | 7.500 giờ trong 10 năm | | Duyệt hồ sơ | Không | Có | Có | | Bài thi | Online có giám sát | 130 câu, 180 phút | 120 câu, 210 phút | {{< /compare >}} ## chỗ hay hiểu sai là lấy chứng chỉ thay kinh nghiệm Lỗi phổ biến là nghĩ có chứng chỉ thì sẽ được giao việc khó hơn, lương cao hơn ngay. Chứng chỉ xác nhận bạn nắm kiến thức theo một chuẩn chung, nó không thay được lúc bạn phải ngồi với một stakeholder không chịu nói thật, hay lúc scope phình ra hai tuần trước go-live. Lỗi thứ hai là cố nhồi giờ cho đủ điều kiện CBAP. Hồ sơ khai giờ phải qua bước IIBA duyệt, mà quan trọng hơn, kinh nghiệm chưa đủ thì đề thi dạng tình huống sẽ rất khó, vì nó hỏi bạn sẽ làm gì trong một hoàn cảnh cụ thể chứ không hỏi định nghĩa. Cách chọn gọn nhất là đếm số giờ BA bạn thật sự đã làm rồi chọn đúng bậc tương ứng. Chưa từng mở BABOK thì đọc bài [BABOK đọc sao cho không ngủ gật](/posts/babok-doc-sao-cho-khong-ngu-gat/) trước khi đặt lịch thi bậc nào, còn đang phân vân chứng chỉ có giúp lên senior nhanh hơn không thì bài [Lộ trình từ fresher BA lên senior](/posts/lo-trinh-tu-fresher-ba-len-senior/) có một góc nhìn khác. Chứng chỉ đúng bậc giúp bạn học có hệ thống và có thêm một tín hiệu trên hồ sơ, chứng chỉ sai bậc thì chỉ tốn thời gian ôn với tiền phí. Bạn đang có bao nhiêu giờ kinh nghiệm BA thật, và đếm kỹ thì đang đứng ở bậc nào? Chia sẻ với mình qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/). --- # BA có cần biết SQL không? SELECT, JOIN, GROUP BY là đủ sống - URL: https://quanlamba.com/posts/sql-cho-ba-select-join-group-by-la-du-song/ - Ngày đăng: 2026-10-04 - Cập nhật: 2026-11-05 - Thẻ: SQL, Business Analyst, Kỹ năng BA, Fresher - Mô tả: BA có cần biết SQL không, học đến mức nào là đủ? SELECT, JOIN, GROUP BY là đủ để tự trả lời phần lớn câu hỏi dữ liệu và kiểm tra requirement. **Trả lời ngắn:** BA không bắt buộc phải biết SQL, nhưng nên biết ở mức SELECT, JOIN, GROUP BY, mức đó đủ để tự trả lời phần lớn câu hỏi dạng bao nhiêu, mấy cái, theo từng tháng, và đủ để kiểm tra requirement với dữ liệu thật, không cần học tới mức developer. Thử hình dung cuộc họp với phòng kinh doanh, trưởng phòng hỏi tháng trước có bao nhiêu đơn bị khách trả lại, chủ yếu là sản phẩm nào, bạn hứa sẽ gửi số, về chỗ nhắn dev nhờ lấy, dev đang chạy deadline nên ba ngày sau mới có file, mà tới lúc đó câu hỏi đã đổi, cuộc họp tiếp theo cũng đã diễn ra rồi. Tình huống kiểu này là lý do nhiều BA bắt đầu học SQL, và câu hỏi là học tới đâu thì vừa, để khỏi mất cả năm cày khóa database. ## SQL với BA để làm gì Với BA, SQL là cái ống nhòm nhìn vào dữ liệu, vì phần lớn câu hỏi stakeholder đặt ra có dạng bao nhiêu, mấy cái, từ khi nào, theo từng nhóm nào, mấy câu này chỉ cần vài dòng query. Nó giúp hai việc. Việc thứ nhất là tự trả lời câu hỏi nghiệp vụ, đỡ phải xếp hàng chờ dev. Việc thứ hai, ít người nói tới hơn, là kiểm tra requirement, trước khi viết "báo cáo hiển thị lý do trả hàng" thì mở dữ liệu ra xem hệ thống có lưu lý do trả hàng không, lưu dạng chọn từ danh sách hay gõ tự do, vì câu trả lời đổi hẳn cách bạn viết requirement. Bài [Làm BA có cần biết code không](/posts/lam-ba-co-can-biet-code-khong/) bàn rộng hơn về kiến thức kỹ thuật cho BA, bài này chỉ tập trung vào SQL. ## ba câu lệnh là đủ sống SELECT là đọc dữ liệu ra, lấy những cột nào, từ bảng nào, đi kèm là WHERE để lọc, ví dụ đơn tạo trong tháng 9 có trạng thái đã trả, đây là câu bạn dùng nhiều nhất. ```sql SELECT order_no, customer_id, status FROM orders WHERE order_date >= '2026-09-01' AND status = 'RETURNED'; ``` JOIN là ghép hai bảng. Bảng đơn hàng thường chỉ lưu mã khách, còn tên khách nằm ở bảng khách hàng, muốn biết đơn của ai thì JOIN hai bảng qua mã khách, hiểu JOIN là hiểu vì sao dữ liệu không nằm một cục, và đây cũng là chỗ ERD giúp bạn rất nhiều, bài [ERD cho BA](/posts/erd-cho-ba/) có hướng dẫn đọc sơ đồ quan hệ bảng. GROUP BY là gom nhóm rồi đếm hoặc cộng, câu hỏi nào có chữ "mỗi" hoặc "theo từng" thì gần như chắc chắn cần GROUP BY kèm COUNT hoặc SUM. ```sql SELECT p.product_name, COUNT(*) AS so_don_tra FROM orders o JOIN products p ON p.product_id = o.product_id WHERE o.status = 'RETURNED' GROUP BY p.product_name ORDER BY so_don_tra DESC; ``` Hai câu trên trả lời đúng câu hỏi của trưởng phòng ở đầu bài, còn tên bảng và cột chỉ là ví dụ, hệ thống thật sẽ khác. ## chỗ hay sai là đếm sai vì JOIN sai Lỗi phổ biến của người mới không nằm ở cú pháp mà ở chỗ JOIN nhân bản dòng, một đơn hàng có ba dòng sản phẩm, JOIN sang bảng chi tiết rồi COUNT(*) thì một đơn hóa thành ba, con số trông rất hợp lý, chỉ có điều là sai, mà đem số sai vào cuộc họp thì còn tệ hơn không có số. Cách tránh là trước khi đếm tự hỏi một dòng kết quả đang đại diện cho cái gì, một đơn hay một dòng sản phẩm, cần đếm đơn thì dùng COUNT(DISTINCT order_no), và luôn đối chiếu một hai con số với màn hình báo cáo có sẵn trong hệ thống trước khi gửi đi. ## bắt đầu học từ đâu Đừng mở đầu bằng một khóa lý thuyết dài về cơ sở dữ liệu, lấy một bộ dữ liệu mẫu có vài bảng liên quan tới nhau kiểu khách hàng, đơn hàng, sản phẩm, nhiều hệ quản trị cơ sở dữ liệu có sẵn database mẫu như vậy, hoặc bạn tự tạo vài bảng nhỏ trong SQLite. Rồi tự đóng vai stakeholder đặt mười câu hỏi, mỗi tháng có bao nhiêu đơn, khách nào mua nhiều nhất, sản phẩm nào chưa bán được lần nào, mỗi câu viết một query, chạy, rồi tự kiểm tra bằng cách đếm tay trên vài dòng, câu nào không viết được là đúng chỗ bạn cần học tiếp. Cách này chậm hơn xem video, nhưng thứ bạn nhớ được là cách biến câu hỏi nghiệp vụ thành query, đúng cái BA cần. ## đừng đâm đầu làm DBA Học SQL đủ dùng khác với chạy theo database, BA không cần viết stored procedure, tối ưu index hay lo phân quyền với backup, đó là việc của dev và DBA, và nhiều nơi cũng chỉ cho BA quyền đọc trên môi trường test hoặc bản sao dữ liệu, như vậy là hợp lý. Một mẹo nhỏ là khi viết [acceptance criteria](/posts/user-story-acceptance-criteria/) cho báo cáo, chạy thử query để chắc field cần dùng có tồn tại và có dữ liệu, phát hiện thiếu field ở bước viết tài liệu rẻ hơn nhiều so với lúc dev đã code xong. Cứ học lần lượt SELECT, JOIN, GROUP BY, tập trên một bộ dữ liệu mẫu, rồi đem ra trả lời câu hỏi thật trong công việc, đủ dùng là đủ, phần sức còn lại để dành cho phân tích. Có câu hỏi dữ liệu nào bạn đang phải chờ người khác lấy số mà nghĩ lại thì tự viết query được không? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/). --- # Go-live: chuẩn bị gì, sai gì, sửa gì - URL: https://quanlamba.com/posts/go-live-chuan-bi-gi-sai-gi-sua-gi/ - Ngày đăng: 2026-09-27 - Cập nhật: 2026-11-05 - Thẻ: ERP, Go-live, Kinh nghiệm thực chiến, Chuyển đổi số - Mô tả: Go-live ERP không phải ngày hội, là ngày thử lửa. Trước, trong và sau go-live cần chuẩn bị gì, cái gì hay sai và sửa thế nào, kèm một đêm kiểm kê tới 1h sáng. Có lần mình đi công tác xa để hỗ trợ kiểm kê, 4h chiều mới có file kiểm đếm, upload dữ liệu lên hệ thống mất thêm vài tiếng, thế là kế toán, kỹ thuật và mình ở lại tới 1h đêm mới xong, giữa chừng có phát sinh vài vấn đề nhưng rồi cũng xử lý được hết. Go-live nghe thì oách, chứ thật ra nó là lúc mọi thứ mình tin là đã chuẩn bị xong bị đem ra thử thật. Bài này đi qua ba giai đoạn, trước, trong và sau cái ngày đó, phần lớn là quan điểm của mình, để ai sắp dính go-live lần đầu đỡ phải học bằng cách té. ## trước go-live, mấy việc hay bị quên Việc đầu tiên là data chưa chốt cắt ở đâu. Ai cũng biết phải chạy [data migration](/posts/data-migration-nhung-cai-bay-khong-ai-noi-truoc/), nhưng ít người chốt trước tồn kho cắt lúc mấy giờ, cắt từ báo cáo nào, ai ký xác nhận con số đó, đến đêm trước go-live mới đi hỏi thì rất dễ lòi ra mỗi nơi một số. Như đêm kiểm kê ở trên, file kiểm đếm tới muộn, upload mất vài tiếng, nên theo mình phải tính trước thời gian upload dữ liệu vào kế hoạch, đừng để nó thành bất ngờ. Việc thứ hai là quyền truy cập chưa được cấp thật. Giả sử ngày go-live kế toán kho không vào được màn hình xuất hàng vì tài khoản test vẫn nằm ở môi trường dev, nên trước go-live vài ngày hãy test một lượt bằng đúng user thật, đúng phân quyền thật. Việc thứ ba là không có người gác cổng thay đổi. Mấy ngày cuối kiểu gì cũng có người nhắn sửa thêm cái báo cáo này nữa thôi, không ai đứng ra chặn thì scope nở ngay trước giờ G, nên chốt một người duy nhất được duyệt thay đổi, rồi dán tên người đó lên tường. Thêm một việc mình luôn làm là đào tạo key user thật kỹ, vì ngày go-live tuyến đầu là key user chứ không phải BA. ## ngày go-live, cái gì sẽ sai Theo mình thường không phải phần mềm. Phần mềm chạy được vì đã qua UAT, với điều kiện UAT có user thật tham gia, mà mình từng gặp UAT không như kỳ vọng vì user không có thời gian test. Cái sai nằm ở con người và data. Thứ nhất là nhập liệu sai, công nhân quen nhìn cột trong Excel, giờ màn hình xếp khác, thế là nhập lộn trường. Thứ hai là tốc độ, lần đầu ai cũng chậm, hàng ùn lại ở khâu nhập, xưởng đứng hình nửa buổi. Thứ ba, cũng là cái nguy hiểm nhất, là có người bị kẹt mà không dám nói, cứ im rồi tự chế ra một cách chạy tạm. Nên ngày go-live đừng cử mỗi mình bạn đi hỗ trợ, cử nguyên một đội túc trực ở từng chốt, có cả người biết quy trình lẫn người biết hệ thống, và lập ngay một bảng ghi lỗi, ai gặp lỗi gì ghi vào đó, chứ đừng chữa cháy bằng miệng. ## sau go-live, đừng tuyên bố thắng sớm Chiều hôm đó đã hô go-live thành công là hơi sớm, vì go-live chỉ là cái mốc chứ không phải cái đích. Theo mình mấy tuần đầu là lúc lộ ra những lỗi UAT không bắt được, số liệu cuối kỳ, chênh lệch công nợ, hàng ảo. Một cách mình từng thấy hiệu quả là khách chưa tin hệ thống thì cho chạy Excel song song một thời gian. Ở một dự án chạy khoảng 2 tuần, số liệu khớp hoàn toàn thì khách ok bỏ Excel, còn nếu số lệch thì việc đầu tiên là tìm root cause, lệch do nhập tay trên Excel hay do nhập liệu trên hệ thống. ## khi nào mới được thở Thật ra là không bao giờ. Go-live xong không có nghĩa là dự án xong, mà là phần mềm bắt đầu sống thật, và đó cũng là lúc nhiều dự án ERP bắt đầu hỏng, không phải vì hệ thống không chạy, mà vì cả công ty tưởng xong rồi nên ai về chỗ nấy. Chuyện này mình viết kỹ hơn ở bài [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/), nhiều lý do gốc rễ nằm đúng ở cái mốc go-live. Nếu bạn sắp qua go-live lần đầu, mình chỉ khuyên một câu, đừng hỏi khi nào thì xong, hãy hỏi ai đang gác mấy cái lỗi không ai dám khai. Còn go-live gần nhất của bạn kết thúc lúc mấy giờ, và cái gì làm bạn phải ở lại muộn nhất? --- # Phỏng vấn BA fresher: câu hỏi thật, trả lời theo STAR - URL: https://quanlamba.com/posts/phong-van-ba-fresher-cau-hoi-that/ - Ngày đăng: 2026-09-20 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Phỏng vấn, Fresher, BA thực chiến - Mô tả: Phỏng vấn BA fresher không hỏi định nghĩa, hỏi tình huống. Cách trả lời theo STAR để không bị rối khi được hỏi em đã xử lý yêu cầu khó thế nào. Lần đầu đi phỏng vấn BA, mình bị hỏi một câu tưởng dễ, em kể một lần em làm việc với stakeholder khó tính đi, thế là ngồi im mấy giây rồi lắp bắp vài câu chung chung kiểu em luôn lắng nghe, em kiên nhẫn, về nhà mới tiếc, chuyện thật thì đầy mà không biết kể sao cho ra hồn. Đi vài vòng mình mới ngộ ra, nhà tuyển dụng không hỏi định nghĩa để chấm điểm thuộc bài, họ hỏi tình huống để xem em xử lý thật thế nào, mà fresher thì chưa có nhiều dự án để khoe, nên cách kể mới là thứ quyết định. ## vì sao câu hỏi tình huống dễ làm fresher trượt Không phải vì em không biết gì, mà vì em kể lan man, người ta hỏi một câu, em trả lời mười câu chẳng liên quan, rồi tự thấy mình ổn, còn phỏng vấn viên nghe xong không nhớ nổi em đã làm gì cụ thể. Cái thiếu không phải kiến thức mà là cấu trúc, kể có cấu trúc thì chuyện bé xíu cũng lộ ra kỹ năng, kể không cấu trúc thì chuyện to đùng cũng trôi tuột. ## STAR, bốn mốc để khỏi rối STAR là một khung kể chuyện chứ không phải công thức thần thánh, bốn chữ cái là bốn mốc. **Situation** là bối cảnh lúc đó ra sao, một câu là đủ. **Task** là việc của em là gì, trách nhiệm rõ ràng. **Action** là em đã làm gì, phần này chiếm nhiều nhất. **Result** là kết quả ra sao, có con số thì càng tốt. Ví dụ thay vì nói em giỏi giao tiếp, em kể: "Lúc làm đồ án, nhóm em cãi nhau vì hiểu khác nhau về yêu cầu (S). Em là người phụ trách ghi spec (T). Em họp riêng từng người, rồi viết lại user story kèm acceptance criteria cho cả nhóm duyệt (A). Nhờ vậy nhóm không phải làm lại phần nào (R)." Nghe khác hẳn đúng không, chuyện vẫn thế, chỉ là sắp lại cho đủ S-T-A-R. {{< info label="Mẹo" >}} Đừng kể quá một phút cho mỗi câu chuyện. Nếu em nói dài hơn, nghĩa là em đang lan man chứ không phải đang kể. {{< /info >}} ## mấy câu hỏi thật hay gặp **"Em hiểu user story là gì, cho ví dụ đi."** Đừng đọc định nghĩa, kể một user story em từng viết, kèm acceptance criteria, cái này mình viết kỹ trong bài [User story và acceptance criteria](/posts/user-story-acceptance-criteria/). **"Làm sao em lấy được yêu cầu khi stakeholder không nói rõ?"** Kể một lần em phải đặt đúng câu hỏi, ví dụ em hỏi quy trình hiện tại chạy thế nào, thay vì hỏi anh muốn gì. **"Vì sao em muốn làm BA?"** Câu này tưởng xã giao nhưng là để đo động cơ, trả lời bằng một chuyện thật chứ đừng đọc slogan, muốn nhìn xa hơn thì xem bài [Lộ trình từ fresher BA lên senior](/posts/lo-trinh-tu-fresher-ba-len-senior/). ## đừng thuộc lòng kịch bản STAR là khung, không phải văn mẫu để học vẹt, thuộc lòng một câu trả lời hoàn hảo thì lúc bị hỏi vặn một nhát là đứng hình. Dùng đúng là nắm cái khung, rồi kể chuyện thật của mình bằng giọng của mình. Fresher không có nhiều dự án, nhưng ai cũng có chuyện để kể, chỉ là chưa biết kể thôi, học được cách kể có cấu trúc rồi thì mấy câu hỏi tình huống hết đáng sợ. Câu hỏi nào trong phỏng vấn BA từng làm bạn đứng hình nhất? --- # Một ngày của BA dưới xưởng: xỏ giày bảo hộ rồi hẵng nói - URL: https://quanlamba.com/posts/mot-ngay-cua-ba-duoi-xuong/ - Ngày đăng: 2026-09-13 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, BA thực chiến, Elicitation, ERP, Nhà máy - Mô tả: Lần đầu xuống xưởng, mình thấy thực tế khác xa quy trình trên giấy. BA dưới xưởng nên quan sát gì, hỏi gì, và vì sao requirement thật nằm cạnh chuyền máy. Lần đầu xuống xưởng, mình mang theo trong đầu nguyên cái quy trình đã đọc trên giấy, công đoạn nào xong thì cập nhật ngay, rõ ràng, đẹp đẽ, rồi đứng nhìn một lúc mới thấy dưới này người ta làm khác hẳn. Công nhân xử lý một mạch từ đầu tới cuối, cuối ngày mới ngồi viết vào biên bản. Khác xa luôn. Mà nghĩ kỹ thì cũng chẳng ai sai. Quy trình trên giấy được viết cho người ngồi văn phòng đọc, còn công nhân thì làm theo cách nào kịp hàng nhất. Từ hôm đó mình tin là muốn lấy requirement thật cho ERP hay MES thì phải xuống xưởng, chứ ngồi phòng họp nghe người ta kể lại thì chỉ được một nửa câu chuyện. ## Quan sát trước, hỏi sau Interview có giới hạn của nó, và mình dính cả hai kiểu: người ta không nhớ, hoặc người ta kể mà mình hiểu sai. Đứng xem họ làm thật thì rõ hơn hẳn, lại còn thấy được chỗ họ làm khác quy trình, khác luôn cả cách chính họ vừa kể trong phòng họp. Ở một dự án, sếp phía khách mô tả quy trình đúng như trên giấy, xuống xưởng mới thấy công nhân đã làm khác đi từ lâu rồi. Nếu chỉ nghe sếp thì cái spec viết ra sẽ đúng với tờ giấy và sai với cái xưởng, mà người phải dùng hệ thống hằng ngày lại là người dưới xưởng. Nên theo mình, buổi đầu xuống xưởng cứ im lặng nhiều hơn hỏi, ghi lại ai làm gì, ghi vào đâu, vào lúc nào, còn câu hỏi thì để dành cho buổi sau. Hỏi sớm quá dễ thành dắt người ta trả lời theo cái quy trình mình đang cầm trong tay. ## Để ý chỗ người ta ghi tay Chi tiết "cuối ngày mới viết biên bản" nghe thì nhỏ, nhưng theo mình nó nói lên khá nhiều thứ. Dữ liệu trên hệ thống sẽ trễ cả ngày so với thực tế, và nếu bạn thiết kế màn hình bắt công nhân nhập ở từng công đoạn thì rất có thể họ sẽ không nhập, hoặc nhập dồn một lần cho xong. Giả sử bạn thấy công nhân ghi số ra giấy rồi cuối ca mới nhập lại. Đừng vội kết luận là họ lười, mà thử hỏi xem nhập ngay thì vướng ở đâu, máy để xa chỗ đứng, thao tác nhiều bước quá, hay đơn giản là chưa quen. Mỗi câu trả lời dẫn tới một thiết kế khác nhau. ## Người dưới xưởng ngại thiết bị, chuyện đó bình thường Một điều mình thấy rõ là người dùng dưới xưởng ngại nhập liệu, ngại đụng vào máy tính hay tablet, đơn giản vì họ không quen. Ý là cả ngày tay họ làm việc với máy móc, vật tư, chứ có phải với bàn phím đâu. Theo mình, thiết kế cho xưởng nên đi theo hướng càng ít trường càng tốt, nút to, quét mã thay vì gõ, và có người kèm cặp mấy ngày đầu. Cái màn hình trông rất ổn trong phòng họp chưa chắc đã dùng nổi với đôi găng tay dính dầu. ## Học ngôn ngữ của xưởng BA làm MES cần hiểu sản xuất, và thứ dân IT hay thiếu nhất theo mình là BOM. Không hiểu BOM thì lúc tổ trưởng nói chuyện định mức, thay thế vật tư, bán thành phẩm, mình ngồi nghe chẳng khác gì nghe tiếng nước ngoài, gật gù cho phải phép. Mình đi từ DEV sang PO rồi mới sang BA, nên mảng này mình phải tự học thêm rất nhiều. Gợi ý của mình là trước khi xuống xưởng thì đọc BOM của vài sản phẩm chính, hỏi cho ra mỗi công đoạn tạo ra cái gì, để lúc đứng cạnh chuyền ít nhất còn biết mình đang nhìn cái gì. ## Xuống xưởng thôi thì chưa đủ Xuống xưởng nhiều mà không có mục đích thì chỉ tốn giày. Không biết mình cần nghe gì thì xuống cả tuần, chụp ảnh đủ mọi góc, vẫn có thể viết ra cái spec sai như thường. Quan sát xong rồi vẫn phải quay lại thống nhất với mọi người. Khi các bên mỗi người hiểu quy trình một kiểu, cách mình làm là vẽ quy trình ra dạng biểu đồ dễ hiểu, flowchart hoặc swimlane, rồi họp thống nhất lại, vì nhìn chung một cái hình thì cãi nhau nhanh hơn nhiều so với mỗi người cầm một đoạn mô tả bằng chữ. Muốn sống sót dưới xưởng còn cần thêm mấy món phòng thân nữa, mình gom lại trong bài [BA trong nhà máy: 6 "món võ" phòng thân](/posts/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/). Còn cách lấy yêu cầu nói chung thì anh em đọc thêm bài [3 nguyên tắc "sống còn" để lấy yêu cầu hiệu quả](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/). Quy trình trên giấy là cái người ta nghĩ mình đang làm, còn cái xưởng mới là cái người ta làm thật. Lần gần nhất bạn xuống xưởng, bạn thấy chỗ nào khác với tờ giấy? --- # Lộ trình fresher BA lên senior: mất bao lâu? - URL: https://quanlamba.com/posts/lo-trinh-tu-fresher-ba-len-senior/ - Ngày đăng: 2026-09-06 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Lộ trình sự nghiệp, Hướng nghiệp, Fresher - Mô tả: Fresher BA bao lâu lên senior? Theo mình không tính bằng số năm: 3 giai đoạn, kỹ năng quyết định thăng hạng và cái bẫy chạy theo chứng chỉ. Giả sử có bạn nhắn hỏi mình, anh ơi em làm BA được hơn một năm rồi, bao lâu thì lên senior được? Theo mình câu trả lời tốt nhất là hỏi ngược lại, em đã tự chịu trách nhiệm với một requirement nào chưa, hay mới làm theo bàn giao, vì lên senior nằm ở câu đó nhiều hơn là ở số năm. Nên bài này mình không viết kiểu cứ đủ 5 năm là tự động lên senior, số năm tự nó chẳng nói lên điều gì, dưới đây chỉ là cách mình nhìn cái lộ trình này. ## ba giai đoạn, theo mình **Năm 1–2 là sống sót và nắm nghề.** Bạn học viết user story cho ra hồn, học đọc tài liệu, học moi requirement từ những stakeholder không biết mình muốn nói gì, và ngấm dần mấy cú sốc mình viết ở [bài này](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/), nào stakeholder không biết mình muốn gì, requirement đổi mỗi ngày, dev không tin BA. Qua được hai năm đó mà vẫn còn muốn làm thì coi như bạn hợp nghề. **Năm 3–4 là tự chủ và bắt đầu dẫn dắt.** Bạn hết ngồi chờ người ta giao việc, tự nhìn ra vấn đề rồi đi hỏi, bắt đầu chạy workshop, thương lượng scope với khách, nói được cả tiếng sếp lẫn tiếng dev, đây là lúc người ta gọi bạn là senior trong miệng dù title chưa đổi. **Từ năm 5 trở đi là senior thật.** Khác biệt không nằm ở chỗ viết requirement nhanh hơn, mà ở chỗ làm đúng và dạy lại được cho người khác, senior là người đứng trước một vấn đề mơ hồ mà không hoảng, tìm được đường ra, rồi chịu trách nhiệm với quyết định của mình. ## kỹ năng quyết định thăng hạng, không phải chứng chỉ Nhiều bạn nghĩ học thêm chứng chỉ là lên senior. Mình không phủ nhận chứng chỉ có giá, chính mình cũng đã thi CBAP và [viết review ở đây](/posts/cbap-co-dang-thi-khong/), nhưng chứng chỉ chỉ mở cửa phỏng vấn, nó không đi làm thay bạn được. Theo mình có ba thứ quyết định hơn nhiều. Một là chịu được ambiguity, dự án nào cũng mơ hồ, và senior là người biến cái mơ hồ thành rõ ràng. Hai là nói được cả tiếng sếp lẫn tiếng dev, dịch yêu cầu kinh doanh thành thứ dev làm được, và dịch ngược lại. Ba là chịu trách nhiệm, không đổ cho khách, cho dev, hay cho cái câu yêu cầu không rõ. {{< info label="Lưu ý" >}} Thời gian không tạo ra senior. Việc khó mới tạo ra senior. {{< /info >}} ## có người 3 năm đã lên, có người 7 năm vẫn đứng nguyên Khác nhau ở một chỗ, người thứ nhất chủ động nhận việc khó, nhận cái dự án ai cũng né, để mình va vấp rồi lớn, còn người thứ hai cứ làm đúng phận sự, mỗi năm thêm một tuổi, thêm một năm kinh nghiệm trên CV, nhưng thật ra là cùng một năm lặp lại bảy lần. Nên đừng đếm năm, hãy đếm xem mình đã va vào bao nhiêu cái mơ hồ mà vẫn còn sống. Việc khó nhất bạn từng tự nhận trong dự án gần đây là gì? Nếu phải nghĩ lâu mới ra, có khi đó chính là lý do bạn vẫn đang đứng tại chỗ. --- # User story và acceptance criteria: fresher hay sai gì? - URL: https://quanlamba.com/posts/user-story-acceptance-criteria/ - Ngày đăng: 2026-08-30 - Cập nhật: 2026-11-05 - Thẻ: User Story, Acceptance Criteria, Business Analyst, Agile, Fresher - Mô tả: Fresher hay viết user story như một câu requirement khô khan. Dùng INVEST và Given-When-Then để viết story và acceptance criteria chuẩn ngay từ đầu. Giả sử bạn mở một file spec ra, toàn những câu kiểu "Hệ thống cho phép người dùng thêm sản phẩm vào giỏ hàng", đọc lướt thì tưởng đúng, nhưng hỏi lại một câu thêm vào giỏ để làm gì thì chưa chắc người viết trả lời được. Theo mình user story hay bị viết bừa ở đúng phần "để làm gì", viết đủ là ai, muốn chức năng gì, còn mục đích thì chỉ là giả định với đoán mò. ## user story không phải requirement viết thành câu Một user story chuẩn chỉ cần trả lời ba thứ, ai, muốn gì, và để làm gì. Công thức "As a... I want... So that..." nghe sách vở thật, nhưng nó ép bạn nghĩ tới người dùng thật chứ không phải tới "hệ thống". {{< compare title="User story: viết sai vs viết đúng" >}} | Viết sai | Viết đúng | |---|---| | Hệ thống cho phép thêm sản phẩm vào giỏ hàng | As a khách hàng, I want thêm sản phẩm vào giỏ để so sánh giá trước khi mua | {{< /compare >}} Thấy khác chưa, câu đúng trả lời luôn để làm gì, là so sánh giá, và cái "So that" đó chính là lý do để dev khỏi phải đoán. ## acceptance criteria theo Given-When-Then User story nói muốn gì, còn acceptance criteria nói thế nào thì gọi là xong, không có nó thì dev làm xong rồi tester cũng chẳng biết test theo cái gì. {{< info label="Mẹo" >}} Given-When-Then đơn giản: **Given** trạng thái ban đầu, **When** hành động, **Then** kết quả mong đợi. Mỗi cái một dòng, viết xong là có luôn test case. {{< /info >}} Ví dụ cho cái giỏ hàng phía trên: - **Given** giỏ hàng đang có 2 sản phẩm - **When** khách thêm sản phẩm thứ 3 - **Then** giỏ hàng hiển thị 3 sản phẩm, tổng tiền cập nhật ngay Ba dòng thôi mà dev code đúng, tester test đủ, không ai phải chạy sang hỏi lại. ## soi story bằng INVEST trước khi quăng cho dev Viết xong đừng vội giao, lấy sáu chữ INVEST ra soi một lượt: - **I** (Independent): story đứng một mình được không - **N** (Negotiable): còn chỗ để bàn, không phải hợp đồng - **V** (Valuable): có mang giá trị cho user không - **E** (Estimable): dev ước lượng nổi không - **S** (Small): đủ nhỏ để làm gọn trong một sprint - **T** (Testable): có acceptance criteria để test không Trượt chữ nào thì quay lại sửa, đừng đợi dev ngồi soi ra rồi mới chạy. ## đừng máy móc quá Không phải story nào cũng phải viết Given-When-Then dài dòng, bug fix một dòng hay đổi màu cái nút thì viết ngắn gọn là xong, máy móc quá lại thành BA chỉ ngồi viết tài liệu mà quên mất việc chính là hiểu người dùng. Cái khó của user story không nằm ở chỗ viết, mà ở chỗ hỏi đúng người, không hiểu user thì viết bao nhiêu "So that" cũng vẫn là đoán. Nếu bạn mới vào nghề, đọc bài [BA mới vào nghề: 5 cú sốc không ai nói trước](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/) để biết mình sắp gặp gì, rồi đọc bài [khai phá "nhu cầu thật"](/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/) trước khi cầm bút viết story. User story là công cụ chứ không phải biểu mẫu hành chính, viết đúng để cả team khỏi đoán, còn mình thì khỏi bị dev réo giữa đêm hỏi cái này là gì vậy BA. Bạn viết user story đầu tiên thế nào, có bị PM trả lại vì "đây là requirement chứ không phải user story" không? --- # CBAP có đáng thi không? Mình thi xong rồi, kể anh em nghe - URL: https://quanlamba.com/posts/cbap-co-dang-thi-khong/ - Ngày đăng: 2026-08-23 - Cập nhật: 2026-11-04 - Thẻ: CBAP, BABOK, Chứng chỉ, Business Analyst, Học tập, Kinh nghiệm thực chiến - Mô tả: Mình thi CBAP xong rồi: định thi CCBA cho đẹp CV, ôn 2 đến 4 tháng vừa đi làm, tin chắc là trượt rồi màn hình hiện chữ đỗ. Kể thật. Bấm nộp bài xong, mình ngồi nhìn màn hình và nghĩ chắc chắn là trượt rồi, vì còn một đống câu đang cắm cờ flag, mấy câu đề dài như đoạn văn tiếng Anh, và kha khá câu mình chọn theo kiểu loại trừ, cái nào nghe đúng nhất thì bấm. Rồi màn hình hiện chữ: đỗ. Mình ngồi đó chưa kịp phản ứng gì, vì đầu vẫn đang chuẩn bị tinh thần cho điều ngược lại. Bài này mình kể lại cả quãng đường, từ lúc định thi để làm gì, ôn kiểu gì, cho tới cái gì còn đọng lại sau đó. Nói trước là lý do ban đầu của mình khá thực dụng, chẳng cao cả gì đâu. ## Định thi CCBA cho đẹp CV, rồi nhảy cóc lên CBAP Ban đầu mình chỉ tính thi CCBA, bỏ lên CV cho đẹp là xong, nhưng sau khi được một người mentor tư vấn và động viên thì mình đổi ý, thi thẳng CBAP luôn. BABOK thì mình không lạ, đã học từ vài năm trước, biết cơ bản các Knowledge Area và các loại requirement, và phải tới khi hiểu ra chứng chỉ IIBA có giá trị thế nào thì mình mới tính chuyện thi. Mình tách hai việc ra từ đầu: tấm bằng là để làm đẹp CV và chứng minh năng lực, còn BABOK mới là thứ phải đọc cho đàng hoàng để có một cái khung BA chuẩn. Có một điều nên tra trước khi mơ mộng, là theo trang [CBAP của IIBA](https://www.iiba.org/business-analysis-certifications/cbap/), bạn cần 7.500 giờ làm BA trong 10 năm gần nhất, và phải nộp hồ sơ để được duyệt trước khi mua gói thi. ## Ôn 2 đến 4 tháng, vừa đi làm vừa ôn Mình ôn khoảng 2 đến 4 tháng, bằng bộ câu hỏi mẫu và học nhóm với mentor, các buổi học diễn ra online qua Meet vào buổi tối sau giờ làm, mentor giảng rồi cả nhóm cùng đọc và highlight tài liệu trên màn hình. Hai thứ mình thấy đáng giá nhất là mentor giải thích BABOK bằng ví dụ thực tế nên dễ vào đầu hơn hẳn, và cách mentor chỉ làm câu hỏi tình huống, còn lịch học đều đặn thì giúp mình khỏi bỏ cuộc giữa chừng. ![Mình ngồi học online qua Meet cùng mentor, trên màn hình là tài liệu được highlight nhiều màu](/images/posts/cbap-hoc-online-voi-mentor.jpg "Một buổi học nhóm online qua Meet với mentor: cả nhóm cùng đọc và highlight tài liệu.") Khó nhất là thời gian. Đi làm cả ngày xong tối mới ngồi ôn được, mà BABOK thì khô, mở ra một lúc là buồn ngủ (ai cùng cảnh thì có bài [BABOK đọc sao cho không ngủ gật](/posts/babok-doc-sao-cho-khong-ngu-gat/) để tham khảo), đã thế tiếng Anh mình đọc chậm, mà từ BABOK đến đề thi lại toàn tiếng Anh. Mệt phết. Vì đọc bản gốc hơi vất, mình tự làm một website tra cứu nhanh kiến thức BABOK theo dạng matrix bằng tiếng Việt, nhờ AI dịch và dặn nó giữ nguyên thuật ngữ tiếng Anh của BABOK để đối chiếu với đề thi cho dễ, ai cần thì cứ vào xài tại [babok-webnotes](https://babok-webnotes.vercel.app/). Song song đó mình gom note các buổi học thành một quyển tài liệu riêng, AI giúp sắp xếp, mình thêm ý của mentor và phần dịch giải thích bằng tiếng Việt cho dễ nuốt, rồi in ra thành một quyển dày bịch mang đi làm, rảnh là lôi ra đọc, ghi chú tay, highlight lên bản in, đọc đi đọc lại nhiều lượt. ![Quyển tài liệu ôn CBAP mình tự tổng hợp từ note các buổi học, in ra và đóng bìa, có bookmark màu](/images/posts/cbap-tai-lieu-in-tu-note.jpg "Quyển tài liệu mình tự tổng hợp từ note các buổi học, in ra mang đi làm đọc lúc rảnh.") Dù vậy mình ôn khá lan man, ôn mãi vẫn thấy chưa vững nên cứ lơ lửng không biết khi nào thì thi, cho tới lúc nhận ra có ôn thêm nữa thì cảm giác chắc cũng y như vậy, và mình chốt thi sớm luôn. Theo mình thì cái lúc "thấy mình sẵn sàng" nhiều khi không bao giờ tới. ## Hôm thi: tin chắc là trượt, rồi màn hình hiện chữ đỗ Lịch thi của mình là đầu giờ chiều, nhưng mình có mặt từ sáng, ngồi quán cà phê ngay chân tòa nhà để ôn lại, mà giờ nghĩ lại thì mấy tiếng ôn cuối đó chắc cũng chẳng đổi được bao nhiêu. Vào phòng thi thì bị soát người xem có mang thiết bị điện tử không, kiểm tra kính rồi bắt tháo kính đặt lên bàn, cái máy tính bấm tay mang theo cũng không được dùng, câu nào cần tính thì bấm cái máy tính trên màn hình. Rồi tới đề. Mình ôn theo các bộ câu hỏi mẫu, nhưng đề thật có kha khá câu mới, nhiều câu viết dài thòng bằng tiếng Anh, mà tiếng Anh mình đã chậm sẵn nên mỗi câu ngốn thời gian hơn mình tính, thế là mình flag lia lịa để quay lại sau, và làm hết một lượt rồi vẫn còn một mớ câu đang cắm cờ, mấy câu đó mình chọn theo cái thấy đúng nhất hoặc loại trừ dần. Bấm nộp mà tin chắc mình trượt. Kết quả hiện ngay trên màn hình, đỗ. Cảm giác đầu tiên là nhẹ người vì xong một việc dài, còn cảm giác thứ hai là chưa tin nổi. Ra khỏi tòa nhà mình đi ra ngoài đường, tự chụp một tấm selfie, cười toe, nhẹ cả người mà vẫn chưa tin là mình đỗ, nhìn mặt mình trong ảnh chắc bạn cũng đoán được. ![Mình chụp selfie trên đường ngay sau khi thi CBAP xong, cười to, nhẹ cả người](/images/posts/cbap-thi-xong-ra-duong.jpg "Ngay sau khi ra khỏi tòa nhà thi: nhẹ cả người, vẫn chưa tin là mình đỗ.") ## Đỗ rồi thì còn lại gì Cái đọng lại rõ nhất là mình nói về nghề tự tin hơn, và BABOK, trước đó là một đống chương rời rạc, giờ nối lại thành một cái khung liền mạch trong đầu. Knowledge Area gây ấn tượng nhất với mình là Business Analysis Planning and Monitoring, vì nó nói BA phải luôn lập kế hoạch và theo dõi chính quá trình làm BA của mình chứ không phải cứ lao vào làm, nghe thì hiển nhiên, nhưng theo mình đây lại là phần dễ bị bỏ quên nhất khi deadline đè xuống. Nếu được thi lại, mình sẽ ôn có kế hoạch rõ hơn, bớt lan man và thi sớm hơn, chỉ vậy thôi. Mình không dám khuyên bạn làm y chang, vì đây mới chỉ là một lần thi của một người. ## Chứng chỉ không đi hỏi requirement giùm bạn Theo mình, tấm bằng CBAP không tự biến ai thành BA giỏi. Nếu bạn làm trong môi trường nội địa, stakeholder toàn nói tiếng Việt và chẳng ai đòi chuẩn quốc tế thì nó có thể chưa đổi được gì ngay, và nó cũng không đi hỏi giùm bạn cho ra requirement thật. CBAP cho mình một cái khung để đứng, còn đứng vững hay không thì tùy mình làm gì trên đó. Vậy có đáng thi không? Với mình là có, vì mình muốn chứng minh năng lực trên CV và cần một cái cớ để ngồi đọc BABOK cho đàng hoàng, còn nếu bạn chỉ cần tấm bằng để lên level thật nhanh thì tính kỹ nhé, mấy tháng ôn đúng nghĩa không có đường tắt. Bạn đang tính thi vì cái bằng hay vì muốn có cái khung? --- # ERP đắt mà không đẻ ra giá trị: lỗi thường nằm ở AP - URL: https://quanlamba.com/posts/erp-dat-ma-khong-de-ra-gia-tri-loi-nam-o-ap/ - Ngày đăng: 2026-08-19 - Cập nhật: 2026-11-05 - Thẻ: ERP, Accounts Payable, Business Analyst, Tích hợp, Chuyển đổi số - Mô tả: 43% doanh nghiệp vẫn chạy AP ngoài ERP, 81% người dùng mất hơn 3 giờ mỗi tuần cho thanh toán thủ công. Giá trị ERP nằm ở quy trình có chạy xuyên hệ thống. Giả sử bạn ngồi với CFO của một nhà máy ngay sau buổi nghiệm thu phase 1 ERP, anh ấy kể tồn kho giờ real-time, báo cáo tài chính ra nhanh hơn, sếp họp có số để chốt, nghe xuôi lắm, rồi bạn hỏi vậy AP giờ chạy trên hệ thống luôn chưa anh. Rất có thể câu trả lời là AP thì... kế toán vẫn gõ Excel, cuối tháng mới nhập tay lên ERP. ERP đắt tiền, mà dòng tiền ra, thứ ngốn nhiều nhất, vẫn nằm ngoài hệ thống. Theo mình cảnh này không hiếm. Báo cáo 2026 của Priority Commerce khảo sát 150 người dùng ERP ở Mỹ cho ra một con số đáng chú ý, chỉ 57% tổ chức tích hợp hoàn toàn AP vào ERP, tức là 43% còn lại vẫn chạy accounts payable bên ngoài, gần một nửa. ## gần một nửa vẫn sống hai nơi AP là một trong những quy trình ngốn giấy tờ và thời gian nhất của nhà máy, nào duyệt hóa đơn, đối chiếu PO, thanh toán nhà cung cấp, nó nằm ngay cửa ra của tiền, vậy mà thường là thứ cuối cùng được đưa vào ERP, nếu có đưa. Lý do cũng dễ hiểu, AP đụng tới tiền nên kế toán giữ khư khư, phần AP của mấy ERP đời cũ thì cồng kềnh, khó cấu hình, lại không nói chuyện được với ngân hàng, thế là người ta chọn đường vòng, xử lý bên ngoài rồi nhập kết quả vào, hệ thống thì trông sạch, còn quy trình thật chạy bằng Excel với email. Kết quả là cái bẫy kinh điển, ERP có dữ liệu, nhưng dữ liệu đó đến từ một quy trình song song không ai kiểm soát, bạn có số, nhưng số ấy đã qua vài lượt gõ tay và đối chiếu ngoài. ## cái giá của việc chạy ngoài Con số trong báo cáo làm mình giật mình, 81% người dùng vẫn dành ít nhất 3 giờ mỗi tuần cho thao tác thanh toán thủ công, ba giờ một tuần nhân lên một năm là mấy chục giờ lao động lương cao ngồi gõ lại số liệu vốn đã có sẵn ở đâu đó. Chưa hết, tổ chức tích hợp AP đầy đủ có khả năng AP hỗ trợ scalability cao gấp đôi, 71% so với 35%, nghĩa là công ty lớn lên, hóa đơn tăng, cái nền AP nằm trong ERP chịu được, còn cái nền Excel thì vỡ trận. Đáng nói nhất là một chi tiết tưởng vô thưởng vô phạt, 100% tổ chức chưa tích hợp đều đồng ý ERP sẽ có giá trị hơn nếu AP được tích hợp sâu hơn. Không ai phủ nhận, ai cũng biết nó đúng, nhưng vẫn để đó. Giả sử AP vẫn nằm trên Excel, cuối tháng kế toán phải ngồi đối soát giữa sổ phụ ngân hàng, file Excel AP và số trên ERP, lệch một khoản là truy ngược từng hóa đơn xem nhập nhầm ở đâu. Tiền thì vẫn phải trả đúng hạn, chỉ có người làm là mệt. ## giải pháp không phải mua thêm phần mềm Điều mình thích ở báo cáo này là nó không xúi bạn mua thêm một tool AP riêng, nó ghim đúng một cụm, embedded payments, tức là thanh toán nằm ngay trong ERP, cùng một luồng dữ liệu, cùng một chỗ đối chiếu, chứ không phải một hệ thống AP đứng riêng rồi đồng bộ lên. Case study Syspro với Pierce Pacific là ví dụ, thời gian chạy một batch thanh toán giảm từ 1-2 giờ xuống dưới 15 phút, không nhờ AI thần thánh gì, chỉ nhờ thanh toán chạy trong luồng ERP và tự lấy dữ liệu hóa đơn đã duyệt thay vì người gõ lại. Đúng cái mình viết trong bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/), giá trị không nằm ở chỗ có phần mềm, mà ở chỗ dữ liệu có chạy xuyên suốt không, AP chạy ngoài nghĩa là dòng tiền của bạn đang đứt quãng ngay chỗ quan trọng nhất. Với dân BA thì bài học rõ lắm, đừng tin cái bảng đã triển khai xong, muốn biết ERP có thật sự chạy không thì đi hỏi kế toán xem cuối tháng còn gõ Excel không. Chỗ nào còn Excel, chỗ đó ERP chưa xong. ## không phải cái gì cũng nên nhét vào ERP Đến đây phải tự vấn một câu, kẻo lại đẩy bạn vào một cái sai khác, có nên đưa tất tần tật vào ERP không? Không. Có những thứ để ngoài là hợp lý, vài edge case hiếm, vài báo cáo ad-hoc, vài việc đặc thù của một phòng nhỏ, nhét ép vào ERP còn tệ hơn để ngoài mà có kiểm soát. Nhưng AP không thuộc nhóm đó, nó là quy trình tài chính lõi, ngày nào cũng chạy, đụng tiền thật, sai là hậu quả lớn, nên phải nằm trong hệ thống, cùng một luồng dữ liệu với mua hàng và tồn kho. Ranh giới nằm ở chỗ quy trình đó có phải core hay không, core thì phải tích hợp, ngoại vi thì tùy, vậy mà mình thấy nhiều nhà máy làm ngược, giữ core chạy ngoài, còn ngoại vi thì cấu hình đủ kiểu trong ERP. Cũng là chuyện mình nhắc trong bài [AI không cứu nổi quy trình rời rạc](/posts/ai-khong-cuu-noi-quy-trinh-roi-rac/), công nghệ không sửa được nền, nó chỉ phóng to cái đã hỏng sẵn. ERP không tự đẻ ra giá trị, nó chỉ là cái khung, giá trị nằm ở chỗ bạn đưa được bao nhiêu quy trình thật vào khung đó, chạy trên cùng một dữ liệu, cùng một chỗ đối chiếu. Nhà máy đã chạy ERP mà cuối tháng kế toán vẫn cặm cụi gõ Excel thì chưa hẳn là ERP thất bại, chỉ là mới xây xong cái khung, còn quy trình vẫn đứng ngoài cửa. Lần cuối bạn đi gemba xem còn quy trình nào chạy ngoài ERP mà sổ sách vẫn ghi đã tích hợp là khi nào? --- # Khi stakeholder không chịu nói chuyện, BA làm gì? - URL: https://quanlamba.com/posts/stakeholder-khong-hop-tac-lam-gi-khi-khong-ai-muon-noi-chuyen/ - Ngày đăng: 2026-08-16 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Stakeholder, Elicitation, Kinh nghiệm thực chiến - Mô tả: Stakeholder né tránh, hẹn rồi lại hủy là chuyện cơm bữa của BA. Đừng coi đó là chuyện cá nhân: hãy nhìn ra nỗi sợ của họ và tìm đường đi vòng. Bạn hẹn họp, họ báo bận, hẹn lại, lại bận, đến lần thứ ba thì bắt đầu tự hỏi họ bận thật hay là không muốn dính vào. Mình gặp kiểu stakeholder này rồi, cứ báo bận, tìm đủ cách để không tham gia dự án, và lý do sâu xa không phải họ ghét ai, mà là họ không thích phải thay đổi. Nó cũng giống mấy cú sốc mình kể trong bài [BA mới vào nghề: 5 cú sốc không ai nói trước](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/), stakeholder không hợp tác chẳng phải chuyện hy hữu gì, nó là chuyện thường ngày của nghề. ## họ không ghét bạn, họ ngại thay đổi Rất dễ nghĩ là người ta ghét mình, chắc tại mình hỏi nhiều quá, hay tại mình là thằng tư vấn phiền phức. Theo mình gốc thường nằm ở thay đổi, hệ thống mới nghĩa là cách làm quen tay bị đảo lộn, đằng sau đó có thể là nỗi sợ mất quyền, sợ bị soi ra lỗi, sợ phần mềm làm mình thành thừa. Giả sử một quản đốc đã quen ghi sổ tay, giờ có BA tới hỏi quy trình anh chạy thế nào, rất có thể anh ấy nghe thành người này tới để thay mình. Đổi câu hỏi từ "sao họ ghét mình" sang "họ đang bảo vệ cái gì" thì theo mình mọi chuyện dễ thở hơn nhiều. ## nói bằng cái đau của họ Lỗi dễ mắc nhất là mở miệng ra là timeline, requirement, KPI của dự án, theo mình stakeholder nghe xong chỉ muốn đứng dậy về chỗ. Người ta chỉ chịu ngồi nói chuyện khi thấy mình được gì, hoặc đỡ mệt đi, bạn cho ảnh thấy cái màn hình mới giúp ảnh khỏi gõ lại báo cáo mỗi sáng thì ảnh nghe, còn bạn bảo em cần requirement để làm tài liệu thì ảnh trốn. ## cửa chính đóng thì đi đường vòng Có người đóng cửa vĩnh viễn, đừng đập cửa, đi cửa sau. Tìm người thật sự nắm quy trình, thường là nhân viên dưới quyền chứ không phải sếp, rồi đi Gemba, đứng cạnh chỗ họ làm việc mà quan sát thay vì hỏi dồn. Với mình observation nhiều khi còn tốt hơn interview, phỏng vấn thì họ có thể không nhớ, hoặc họ kể mà mình hiểu sai, còn đứng xem họ làm thật thì mình hiểu rõ hơn, và còn thấy họ làm khác quy trình, khác cả cách họ nói. ## mở màn nhỏ thôi Hẹn một stakeholder đang né mình bằng buổi workshop ba tiếng là cách chắc chắn nhất để ảnh bận đột xuất. Bắt đầu bằng mười lăm phút cà phê, một câu hỏi thôi, không agenda dài dòng, không slide, khi ảnh thấy nói chuyện với bạn chẳng mất gì thì lần sau ảnh ngồi lâu hơn. ## có người không bao giờ hợp tác Có những người bạn làm gì cũng vậy, thế thì đừng cố một mình đến kiệt sức, escalate sớm, kéo PM hoặc sếp của họ vào, và ghi lại từng lần mình đã thử liên hệ. Không có requirement thật thì mọi thứ phía sau đều là đoán mò, như mình viết trong bài [bộ kỹ năng khai phá "nhu cầu thật"](/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/). Stakeholder không hợp tác không phải lỗi của bạn, nhưng không có cách xử lý thì nó sẽ thành lỗi của bạn, vì cuối cùng dự án vẫn cần requirement, mà requirement lại nằm trong đầu họ. Bạn có nhớ một stakeholder từng đóng cửa với mình không, giờ nghĩ lại thì điều họ đang sợ là gì? --- # AI không cứu nổi quy trình rời rạc, nó chỉ phơi bày - URL: https://quanlamba.com/posts/ai-khong-cuu-noi-quy-trinh-roi-rac/ - Ngày đăng: 2026-08-12 - Cập nhật: 2026-11-05 - Thẻ: AI, ERP, Business Analyst, Chất lượng dữ liệu, Quy trình - Mô tả: AI không làm hệ thống thông minh hơn, nó phơi bày dữ liệu yếu, quy trình rời rạc và thiếu ownership. Trước khi mua AI, hãy sửa nền móng ERP đã. Tuần trước mình ngồi cà phê với một anh giám đốc nhà máy, ảnh hào hứng khoe sắp tới tụi anh mua AI về chạy scheduling với dự báo đơn hàng, khỏi cần planner ngồi chỉnh tay từng đơn nữa. Mình hỏi đúng một câu, dữ liệu BOM với lead time trên ERP của anh giờ chuẩn hết chưa? Ảnh im một hồi rồi bảo, thì... cũng tàm tạm. Đó. Mình không anti-AI, nhưng sau mấy năm đi triển khai ERP với làm BA, mình thấy một pattern lặp đi lặp lại, doanh nghiệp muốn AI, mà cái nền để AI chạy lên thì đang là một mớ hỗn độn. Robert Kramer, managing partner của KramerERP, vừa viết một bài trên ERP Today gãi đúng chỗ ngứa này: **AI không làm hệ thống thông minh hơn, nó phơi bày những điểm yếu vốn có**, dữ liệu yếu, quy trình rời rạc, ownership mập mờ. Đây không phải chuyện công nghệ, mà là chuyện operating model. ## AI chỉ chạy nhanh hơn cái đã hỏng sẵn Kramer viết: "AI does not remove those weaknesses. It can make them move faster." Giả sử một đơn hàng bị giữ vì vượt credit limit, nhưng email escalation lại gửi cho một người đã nghỉ việc, một purchase requisition nằm im trong inbox của approver mà approver không biết mình là approver, một cái BOM sai từ đời nào rồi production cứ thế chạy ra thành phẩm sai spec. Giờ thả một AI agent vào mớ này, nó sẽ escalate nhanh hơn, vào đúng cái email cũ, approve nhanh hơn, dựa trên đúng cái BOM sai, nghĩa là tự động hóa thật, nhưng là tự động hóa cái sai. Kramer gọi ERP là "control point for execution", tức là chỗ để kiểm soát chứ không phải sân cho AI tung hoành, nơi định nghĩa approval threshold, exception path, escalation rule. AI có thể đề xuất, routing, thậm chí execute, nhưng phải nằm trong vòng kiểm soát, có audit trail rõ ràng, và con người giữ quyền override. Chuyện này mình viết kỹ hơn ở bài [nợ quyết định](/posts/no-quyet-dinh-decision-debt/), thứ nguy hiểm hơn technical debt mà không dashboard nào đo được. ## nhìn thấy chưa chắc đã giải quyết được Supply chain bây giờ visibility tốt hơn xưa nhiều, bạn biết hàng đang ở đâu, chậm bao lâu, tồn kho bao nhiêu, nhưng Kramer có một câu đáng ghim: "Visibility without decision logic only shows the problem in higher resolution." Kiểu như gắn camera 4K trong nhà, thấy rõ mồn một cảnh nhà đang cháy, rõ hơn hẳn, nhưng không dập được lửa. Cái thiếu không phải data, mà là một operating model liền mạch từ data sang insight, sang decision, sang action, rồi audit. Theo mình một công ty có thể đổ tiền vào dashboard hoành tráng, real-time data đẹp mê, nhưng khi shortage xảy ra thì planner vẫn phải gọi điện, check Excel, forward email qua mấy phòng mới ra được quyết định, AI mà recommend trong mớ đó thì cũng chỉ là thêm một tab browser nữa thôi. ## dữ liệu bẩn thì AI càng ngu Cái này mình viết rồi trong bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/), nhưng nhắc lại chẳng bao giờ thừa. Data migration vốn đã đau đầu, nhất là khi không rõ thứ tự data nào phải migrate trước, giờ giả sử data nguồn có item master trùng, customer code trên CRM một đằng trên ERP một nẻo, supplier classification thì ai nhớ đâu mà phân, chạy MRP trên đống đó thì ra toàn rác. Rồi tưởng tượng AI agent lấy chính đống data đó để recommend mua hàng, chọn supplier, chốt lead time, bạn có dám không? Gartner báo cáo hồi tháng 4/2026 rằng tổ chức có AI initiative thành công đầu tư gấp 4 lần vào data quality, governance, AI-ready people và change management so với tổ chức thất bại. Không phải họ có AI xịn hơn, họ chỉ không để AI chạy trên nền rác. ## decision rights trước, agents sau Đây là đoạn mình tâm đắc nhất trong bài của Kramer, trước khi thả AI agent vào core process thì phải trả lời được **ai authorize, cho ai, trong giới hạn nào, escalate ra sao, audit thế nào**. Nghe quen không, đúng mấy thứ BA tụi mình ngồi facilitate với stakeholders hằng ngày, vậy mà thực tế mình thấy đa số công ty chưa có process map rõ ràng, ai approve cái gì còn chưa thống nhất, escalation path thì tùy hôm đó ai đang có mặt ở văn phòng. Xong định thả AI vào tự chạy? Thôi, ngồi xuống vẽ process map, định nghĩa RACI, thống nhất escalation rule trước đã, mấy thứ nhàm chán đó mới quyết định AI có chạy được hay không. Nó cũng là thứ mình nhắc trong bài [tích hợp trước AI](/posts/tich-hop-truoc-ai-bai-hoc-tu-duoc-pham-va-quoc-phong/), bài học từ cả dược phẩm lẫn quốc phòng Mỹ. ## không phải là đừng làm AI Mình chỉ nói AI có giá trị khi quy trình và dữ liệu đủ sạch, đủ rõ, còn ai đang nghĩ mua AI về là nó tự fix hết thì sai rồi, AI không fix gì cả, nó làm mọi thứ nhanh hơn, kể cả cái sai. Nên bắt đầu từ mấy thứ nhàm chán nhất như data cleansing, process documentation, role definition, exception handling, đúng việc BA làm hằng ngày, không hào nhoáng, không có demo đẹp, nhưng là nền. Lần tới có ai chào bạn giải pháp AI cách mạng hóa doanh nghiệp trong 3 tháng, hỏi lại họ, ERP bên mình data đã sạch chưa, quy trình đã map chưa, approver đã biết mình là approver chưa. Câu trả lời là chưa thì AI chỉ là cái loa phóng thanh cho mớ hỗn độn hiện tại thôi. Bạn đã gặp trường hợp AI làm lộ ra điểm yếu quy trình trong công ty mình chưa, hay toàn thấy demo đẹp? --- # BABOK đọc sao cho không ngủ gật - URL: https://quanlamba.com/posts/babok-doc-sao-cho-khong-ngu-gat/ - Ngày đăng: 2026-08-09 - Cập nhật: 2026-11-05 - Thẻ: BABOK, Chứng chỉ, CBAP, Business Analyst, Học tập - Mô tả: BABOK dày, khô, lại toàn tiếng Anh. Đây là cách mình đọc: tra theo việc đang vướng, nhờ AI dịch nhưng giữ thuật ngữ, và tự làm bài kiểm tra để nhớ. Bạn mở BABOK ra, đọc vài trang "Business Analysis Key Concepts", rồi chợt nhận ra mình vừa đọc lại cùng một đoạn lần thứ ba mà vẫn không nhớ nó nói gì. Quen không? Với mình còn thêm một cái khó nữa là tiếng Anh không tốt, mà BABOK lại viết bằng thứ tiếng Anh rất chuẩn mực, câu dài, mệnh đề lồng mệnh đề, đọc một trang phải tra từ liên tục thì buồn ngủ là chuyện đương nhiên. Mình đã thi CBAP xong, và cách mình đọc BABOK chẳng có gì thần kỳ, dưới đây là mấy thứ mình làm thật, cộng thêm vài điều theo mình là đáng thử. ## đừng đọc từ trang đầu tới trang cuối BABOK là tài liệu tham khảo chứ không phải tiểu thuyết, và theo mình đọc tuần tự là cách nhanh nhất để bỏ cuộc. Hợp lý hơn là bắt đầu từ chỗ bạn đang vướng, đang phải lấy yêu cầu từ stakeholder thì mở Elicitation and Collaboration, đang viết spec cho dev thì mở Requirements Analysis and Design Definition, đọc đúng thứ mình đang cần thì não tự giữ lại, vì nó có chỗ để bám. ## knowledge area là bản đồ, không phải bài học thuộc Sáu Knowledge Area nghe rất hàn lâm, nào Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, Solution Evaluation. Theo mình, cái cần nhớ không phải mỗi KA có bao nhiêu task, mà là logic dự án đang ở đâu thì cần KA nào, nó là la bàn chứ không phải đề trắc nghiệm. Thi xong rồi, KA làm mình nhớ nhất lại là cái nghe chán nhất, Business Analysis Planning and Monitoring. Ý của nó đơn giản thôi, việc BA cũng phải được lập kế hoạch và theo dõi, chứ không phải cứ có yêu cầu là lao vào làm. Nghe thì hiển nhiên, nhưng thử nhìn lại tuần vừa rồi của bạn xem, bao nhiêu việc là chữa cháy và bao nhiêu việc là có kế hoạch? ## tiếng Anh kém thì nhờ AI dịch, nhưng giữ nguyên thuật ngữ Đây là cách mình làm thật, nhờ AI dịch BABOK sang tiếng Việt cho dễ đọc, nhưng dặn rõ là giữ nguyên thuật ngữ BABOK bằng tiếng Anh. Lý do là đề thi CBAP bằng tiếng Anh, và khi làm việc với người khác thì "stakeholder", "elicitation", "traceability" là ngôn ngữ chung, dịch hết sang tiếng Việt thì bạn hiểu ý đấy, nhưng lúc gặp lại từ gốc lại không nhận ra. Phải tự phản biện chỗ này một chút, dịch bằng AI không thay được việc đọc bản gốc. Bản dịch giúp hiểu ý nhanh, nhưng đề thi và tài liệu thật vẫn là tiếng Anh, hôm đi thi mình vẫn mất khá nhiều thời gian để đọc mấy câu hỏi tiếng Anh dài dằng dặc, nên giờ mình vẫn đang học thêm tiếng Anh. ## tự làm chỗ học, tự ra bài kiểm tra Cái này hơi dân kỹ thuật, mình tạo hẳn một website riêng để học BABOK, rồi vibe code thêm phần làm bài kiểm tra để tự test. Bạn không nhất thiết phải code, theo mình điểm cốt lõi là biến việc đọc thụ động thành việc trả lời câu hỏi, đọc xong một phần mà tự hỏi mình được 5 câu thì nhớ lâu hơn nhiều so với tô highlight cả trang. Một file Excel câu hỏi, một bộ flashcard, hay nhờ AI ra đề từ chương vừa đọc đều được. ## mỗi technique là một tình huống, không phải định nghĩa 50 techniques nghe như núi, nhưng nếu bạn đã làm BA được một thời gian thì khả năng cao là đã dùng kha khá trong đó rồi, chỉ là không biết tên chính thức thôi. Bạn hỏi "anh muốn gì ở hệ thống mới", đó là Interviews, bạn vẽ quy trình lên bảng rồi hỏi "em hiểu thế này có đúng không ạ", đó là Process Modelling, bạn lôi file Excel của kế toán ra hỏi từng cột là Document Analysis, còn đứng cạnh người dùng xem họ làm thật là Observation. Theo mình, gắn mỗi technique với một tình huống bạn từng gặp, hoặc tự đặt ra một tình huống giả định, thì nhớ luôn được nó dùng khi nào. Technique nào chưa dùng bao giờ thì đánh dấu lại, chưa cần ép. ## đừng lướt qua Underlying Competencies Chương này nói về analytical thinking, problem solving, communication, business knowledge, và nhiều người lướt qua vì nó chẳng có task nào để học thuộc. Theo mình đây lại là chương đáng đọc chậm nhất, đọc tới đâu tự hỏi mình đang yếu cái nào tới đó. Với dân làm ERP/MES như mình, business knowledge về sản xuất, BOM chẳng hạn, là thứ dân IT hay thiếu nhất. ## mỗi tuần tự vấn một lần Một gợi ý nhỏ, cuối tuần mở một KA bất kỳ ra đọc lướt, rồi tự hỏi "tuần này mình đã làm cái gì trong đây chưa?". Thường câu trả lời là chưa, vì BA ở nhiều dự án đâu có tha hồ mà làm Strategy Analysis, nhưng chỉ cần biết khái niệm đó tồn tại thì tới lúc gặp tình huống thật bạn sẽ nhận ra "à, cái này có trong BABOK". ## BABOK không dành cho mọi giai đoạn Nói thật là BABOK không dành cho tất cả mọi người, ít nhất là không cho mọi giai đoạn. Nó mô tả một thế giới khá lý tưởng, stakeholder hợp tác, requirement rõ ràng, change control chặt chẽ, trong khi thực tế deadline và đặc thù dự án nhiều khi chẳng cho bạn làm đúng chuẩn, đọc xong quay lại dự án có khi còn bực vì biết vậy mà không làm được. Nhưng biết thế nào là chuẩn vẫn giúp bạn phân biệt mình đang làm đúng hay đang chữa cháy, và BABOK cho bạn ngôn ngữ để giải thích vì sao [scope creep](/posts/scope-creep-chuyen-kinh-dien-va-cach-song-sot/) là vấn đề thật, hay vì sao [thi CBAP](/posts/cbap-co-dang-thi-khong/) không chỉ để lấy cái badge. Không cần nhớ hết, chỉ cần biết chỗ nào để mở ra khi cần. Bạn đọc BABOK tới đâu rồi, có chương nào làm bạn ngủ gật nhanh nhất không? --- # ERP đổi hướng giữa chừng: tiếp, dừng hay hybrid? - URL: https://quanlamba.com/posts/erp-doi-huong-giua-chung/ - Ngày đăng: 2026-08-05 - Cập nhật: 2026-11-05 - Thẻ: ERP, Quản trị dự án, Business Analyst, Quyết định, Cloud ERP - Mô tả: Vendor cloud ERP ra tính năng trùng customization đang làm dở: tiếp tục, dừng hay đi đường hybrid? Khung 5 câu hỏi giúp BA và PM bỏ sunk cost. Tháng thứ 9 của dự án, requirement đã chốt, solution design đã duyệt, dev đang chạy full sprint, mọi thứ đi đúng lộ trình, rồi vendor publish roadmap, và trong danh sách tính năng mới có một feature standard làm y chang cái mà team đã bỏ mấy tháng thiết kế custom. Cả phòng im lặng, rồi ai đó hỏi, vậy giờ làm sao? Mình đã ngồi đúng khoảnh khắc đó hai lần. Lần đầu mình im, vì chưa biết nên nói gì, lần thứ hai mình mở miệng, không phải để trả lời mà để hỏi. ## không phải kế hoạch dở, mà là bản chất của cloud ERP Hồi on-premise, bạn mua version 10.2, triển khai version 10.2, go-live version 10.2, platform đứng yên cả năm. Cloud ERP thì khác, Oracle, SAP, Workday, IFS release 2-4 phiên bản mỗi năm, tính năng mới ra liên tục, có thứ team thiết kế custom 6 tháng trước thì giờ vendor đã gói thành standard, test sẵn, document sẵn, có sẵn cả upgrade path. Đây không phải bug, nó là hệ quả tất yếu khi triển khai trên một nền tảng liên tục tiến hóa, có điều nó đặt lên bàn steering committee một bài toán đau thật, tiếp tục build custom, dừng lại đợi standard, hay đi đường hybrid. ## phản xạ đầu tiên luôn là làm tiếp đi Tâm lý này dễ hiểu, team đã bỏ công mấy tháng, sponsor đã cam kết deadline, đổi hướng giữa chừng nhìn giống thất bại. Nhưng nó không phải thất bại, nó là governance có kỷ luật. Bài báo trên ERP Today tuần này của Gina, một chuyên gia từng làm ở Deloitte, EY, Accenture, tả rất đúng cảnh hai phe trong steering committee cãi nhau, phe một bảo làm tiếp đi sắp xong rồi, phe hai hỏi nếu vendor sắp có standard thì build làm gì cái mà go-live xong lại phải retire. Cả hai đều có lý, nhưng trước khi đứng về phe nào thì cần dữ liệu chứ không phải ý kiến. ## năm câu hỏi trước khi quyết Tác giả đưa ra một khung đánh giá khá thực dụng, không phải slide đẹp, mà là mấy câu BA và PM có thể mang thẳng lên steering committee. Câu đầu là phần nào của customization thật sự trùng với standard. Đừng nhìn tổng thể, mổ ra từng module, từng function, có khi 70% trùng nhưng 30% còn lại là thứ chỉ business của mình mới có, standard không làm được. Câu thứ hai là chi phí thật của việc làm tiếp là bao nhiêu, không chỉ tiền dev mà cả maintain, upgrade, test hồi quy mỗi lần vendor release, có những customization hôm nay build 2 tháng nhưng nuôi nó mất 5 năm. Câu thứ ba là dừng lại thì vận hành bị ảnh hưởng thế nào, ai bị đứt process, có workaround tạm được không hay user đứng hình, câu này phải hỏi thẳng người dùng cuối chứ không đoán trong phòng họp. Câu thứ tư là bao lâu nữa standard feature đó mới có thật. Vendor nói upcoming release, nhưng release nào, tháng sau, quý sau, hay chỉ là nằm trên roadmap mơ hồ, phải verify với account manager, đừng tin slide marketing. Câu cuối là quyết định nào tạo giá trị dài hạn nhất, không phải cái nào giữ được schedule hay giữ được sunk cost, mà là cái nào để ba năm nữa nhìn lại mình không thấy hối hận. ## ba con đường và cái giá của từng đường Bài báo tả ba kịch bản dựa trên những pattern lặp lại ở nhiều dự án ERP lớn, không gắn với khách hàng cụ thể nào, nhưng ai làm ERP lâu chắc sẽ thấy quen. Đường thứ nhất là làm tiếp custom và go-live đúng hạn, lựa chọn phổ biến nhất, schedule không xáo trộn, stakeholder không phải họp lại, ai cũng thở phào. Vấn đề tới sau go-live, khi vendor ra standard feature thì tổ chức lại phải chạy một mini-project, evaluate, retire, replace, test, retrain, cái custom build với tâm thế tạm thời giờ đã thành production, và cắt nó đi tốn gần bằng lúc build. Một tổ chức trong bài chọn đường này nhưng khác ở chỗ trước khi team implementation giải tán, họ đã lên sẵn post-go-live roadmap để retire custom và chuyển sang standard, funding được duyệt ngay, ownership được giao rõ, nên chuyện chuyển đổi sau này là chủ động chứ không phải chữa cháy. Đường thứ hai là dừng hẳn để đợi standard, quyết định khó nói nhất trong phòng họp, mấy tháng công sức coi như write-off, timeline dời vài tuần, sponsor hỏi vậy team làm gì mấy tháng qua. Nhưng khi phần trùng giữa custom và standard lớn, đây thường lại là quyết định khôn nhất về dài hạn, chi phí hôm nay có khi chỉ bằng chi phí maintain 3-5 năm, chưa kể giảm technical debt và rủi ro upgrade. Tác giả có một câu mình rất tâm đắc: câu hỏi không phải là đã bỏ bao nhiêu tiền, mà là nếu biết những gì mình biết hôm nay, mình có làm cái custom đó không. Đường thứ ba là hybrid, làm tối thiểu rồi hoãn phần còn lại, và đây là đường dễ bị bỏ qua nhất. Thay vì chọn trắng đen thì hỏi một câu khác, minimum capability nào đủ để business vận hành lúc go-live, team chỉ build đúng những gì user cần cho ngày đầu tiên, phần còn lại để sau, tới lúc vendor ra standard thì chuyển dễ hơn nhiều vì cái interim solution vốn được thiết kế với tâm thế nó sẽ biến mất. Không phải dự án nào cũng hợp hybrid, nhưng mình thấy nhiều team bỏ qua lựa chọn này chỉ vì chưa ai nghĩ tới. ## thứ quan trọng hơn cả quyết định Ba tổ chức trong bài chọn ba con đường khác nhau, nhưng có chung một điểm là **không ai phản ứng bốc đồng**, họ dừng lại, đánh giá, quyết dựa trên dữ liệu, không để áp lực schedule ép mình vào ngõ cụt. Mình từng viết về [nợ quyết định, thứ nguy hiểm hơn technical debt](/posts/no-quyet-dinh-decision-debt/), mà quyết vội cũng là một kiểu nợ khác, giống bốc thuốc không bắt mạch, triệu chứng hết mà bệnh vẫn còn, và trong ERP bệnh không chữa kịp thì vài năm sau nằm luôn trong danh sách [dự án thất bại](/posts/tai-sao-du-an-erp-that-bai/). Nên nếu sáng mai vendor của bạn publish roadmap mới, câu hỏi thật không phải bạn sẽ chọn đường nào, mà là **governance model của bạn có đủ nhanh để phản ứng không**. Steering committee có ai lo theo dõi vendor roadmap không, có process escalation khi phát hiện standard feature trùng với customization đang build không, hay mọi thứ trông vào việc PM thấy thì báo? Những tổ chức qua được mấy khúc cua kiểu này không phải vì đoán giỏi, mà vì họ có cơ chế để biết và có kỷ luật để làm. Bạn đã có cơ chế đó chưa? --- # làm BA có cần biết code không? Cần đọc được, chưa cần viết - URL: https://quanlamba.com/posts/lam-ba-co-can-biet-code-khong/ - Ngày đăng: 2026-08-02 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kỹ năng BA, Lập trình, Hướng nghiệp - Mô tả: Làm BA có cần biết code không? Không cần viết code sản phẩm, nhưng nên đọc được SQL, API và luồng dữ liệu để kiểm tra requirement với hệ thống thật. **Trả lời ngắn:** làm BA không cần viết code sản phẩm, nhưng nên đọc được SQL, tài liệu API và luồng dữ liệu, mức đó đủ để bạn tự kiểm tra requirement với dữ liệu thật và nói chuyện thẳng với dev, thay vì chuyển lời qua lại. Hỏi ba nhà tuyển dụng câu "BA có cần biết code không" thì bạn có thể nhận về ba câu trả lời khác nhau, chỗ này bảo chỉ cần hiểu nghiệp vụ, chỗ kia hỏi SQL, chỗ khác lại đưa một đoạn JSON rồi hỏi thiếu trường gì. Người mới nghe xong rất dễ hoang mang, nhưng thật ra ba câu đó không mâu thuẫn nhau, chúng chỉ phản ánh ba kiểu dự án khác nhau. Câu trả lời của mình là BA cần biết đọc, chưa cần biết viết, còn đọc cái gì và đến mức nào thì ở phần dưới. ## không viết code, nhưng phải hiểu logic BA không cần viết vòng lặp bằng Java, nhưng khi dev nói "endpoint này trả về 2.000 dòng, frontend mỗi lần gọi 100 dòng" thì BA nên hiểu chuyện đó ảnh hưởng tới người dùng ra sao, màn hình có phân trang không, tìm kiếm chạy trên toàn bộ dữ liệu hay chỉ trên trang đang xem. Thử hình dung một BA rất vững nghiệp vụ kho, thuộc từng bước nhập, xuất, kiểm kê, rồi dev hỏi "API tracking trả về cấu trúc thế nào, có trường số lô không?". Nếu BA không đọc được tài liệu API thì một câu hỏi hai phút biến thành một vòng hỏi qua hỏi lại kéo dài cả buổi, chẳng ai sai cả, chỉ là thiếu một kỹ năng đọc. Những vị trí BA thuần cầu nối, nhận yêu cầu từ user rồi chuyển cho dev, vẫn tồn tại. Theo mình đó là chỗ làm được nhưng dễ chạm trần, vì giá trị BA tạo ra chỉ dừng ở việc truyền lời. ## SQL là thứ nên học đầu tiên Nếu chỉ học một thứ kỹ thuật thì hãy học SQL, không phải để thành developer, mà để tự mở dữ liệu xem hệ thống đang chạy thế nào, tự viết query kiểm tra logic, và tự đối chiếu số trên báo cáo với dữ liệu gốc. Lý do là người dùng mô tả quy trình theo cách họ nghĩ nó đang chạy, còn dữ liệu cho thấy nó thật sự chạy ra sao. Giả sử quản lý kho khẳng định tồn kho lúc nào cũng khớp, bạn chạy một câu cộng số lượng theo vị trí và trạng thái thì thấy lệch với báo cáo, đào thêm mới biết báo cáo không tính hàng đang chờ kiểm tra chất lượng. Phát hiện ở bước phân tích thì rẻ hơn rất nhiều so với phát hiện sau go-live. Học tới đâu là đủ thì xem bài [SQL cho BA: SELECT, JOIN, GROUP BY là đủ sống](/posts/sql-cho-ba-select-join-group-by-la-du-song/), và học kèm cách đọc sơ đồ dữ liệu ở bài [ERD cho BA](/posts/erd-cho-ba/) để hiểu vì sao query phải JOIN. ## API và tích hợp là lợi thế khi làm ERP Ở dự án ERP hay chuỗi cung ứng, tích hợp gần như là chuyện mặc định, ERP trao đổi dữ liệu với MES, MES với hệ thống kho, kho với bên vận chuyển. Hiểu cơ bản về request, response, HTTP method và xác thực thì bạn tự đọc được tài liệu API của bên thứ ba, đánh giá sớm tích hợp có khả thi không, và bắt được chỗ không khớp trước khi dev mất công debug. Bạn không cần code API, bạn chỉ cần chỉ vào một đoạn JSON và nói được "thiếu trường số lô, mà requirement cần truy vết theo lô". Câu đó tiết kiệm cho cả đội hơn mọi slide. ## biết code là con dao hai lưỡi BA đi lên từ dev có lợi thế rõ, nghe requirement là thấy ngay technical constraint, ước lượng được độ phức tạp, chuyện rẽ hướng này có trong bài [Dev muốn chuyển sang BA thì nên làm gì](/posts/tu-dev-chuyen-sang-ba/). Nhưng có một cái bẫy, là biết code thì rất dễ rơi vào chế độ giải pháp. Thử hình dung buổi khảo sát với bộ phận kho, BA biết code ngồi phác luôn giao diện màn hình nhập liệu mới, trong khi câu cần hỏi là vì sao thủ kho phải nhập lại con số mà máy quét đã đọc rồi, biết đâu giải pháp tốt nhất là bỏ hẳn cái màn hình đó. BABOK Guide v3 tách rõ việc hiểu need trước khi định nghĩa solution là có lý do cả. ## BA cần kỹ thuật tới mức nào Mình chia ba mức để bạn tự định vị. Mức một là biết đọc, tức SQL cơ bản, đọc tài liệu API, hiểu luồng dữ liệu. Theo mình đây là mức tối thiểu cho BA làm ERP hay dự án nhiều tích hợp. Mức hai là biết chạy, tự viết query phức tạp hơn, tự gọi thử API bằng Postman hoặc curl, tự đọc log để khoanh vùng lỗi, ở mức này bạn làm việc với dev rất trơn dù chẳng viết dòng code sản phẩm nào. Mức ba là biết code, viết script tự động hóa, dựng prototype, hiểu kiến trúc hệ thống. Mức này đưa bạn đến gần vai Technical BA hay Solution Architect, với điều kiện đừng để giải pháp chạy trước vấn đề. ## khi nào nghiệp vụ quan trọng hơn kỹ thuật Tự phản biện lại chính mình một chút, ở các lĩnh vực như ngân hàng, bảo hiểm, y tế thì hiểu quy định và nghiệp vụ domain thường quyết định nhiều hơn, kỹ thuật có thể học sau. Đừng bỏ ra nửa năm học lập trình trong khi vị trí bạn nhắm cần hiểu nghiệp vụ tín dụng hơn. Còn nếu bạn nhắm ERP, SaaS hay dự án nặng tích hợp thì nền kỹ thuật ở mức một là thứ nên có sớm, và bước đầu rất nhỏ thôi, cài một database mẫu, viết câu SELECT đầu tiên, rồi mở Postman gọi thử một API công khai. Bạn đang ở mức nào trong ba mức trên, và đang kẹt ở bước nào? Kể mình nghe qua [Facebook](https://www.facebook.com/kiu98/) hoặc [LinkedIn](https://www.linkedin.com/in/quandd/). --- # Nợ quyết định: thứ nguy hiểm hơn technical debt - URL: https://quanlamba.com/posts/no-quyet-dinh-decision-debt/ - Ngày đăng: 2026-07-29 - Cập nhật: 2026-11-05 - Thẻ: Decision debt, Business Analyst, ERP, Quản trị dự án - Mô tả: Decision debt tích tụ khi ERP program trì hoãn quyết định quan trọng và thay bằng giả định tạm. Nguy hiểm hơn technical debt vì không ai tracking. Giả sử bạn ngồi trong một cuộc họp chỉ để chốt một câu tưởng đơn giản, cột này để mấy số thập phân, dev bảo ít là đủ, user muốn nhiều hơn vì sợ sai số làm tròn, cuối cùng cả phòng gật đầu để nhiều cho chắc rồi ai về nhà nấy, không ai ghi lại đã chốt gì và vì sao. Một quyết định nhỏ như thế, nhân lên hàng trăm lần trong một dự án ERP, là **decision debt**. Theo mình decision debt là thứ tích tụ khi dự án trì hoãn những quyết định kinh doanh quan trọng rồi lấp chỗ trống bằng giả định tạm, và nó còn nguy hiểm hơn technical debt, vì gần như chẳng bao giờ xuất hiện trên risk register hay dashboard nào. ## decision debt là gì Nói nôm na, decision debt là khoảng cách giữa "mình biết cần quyết cái gì" và "mình thật sự chốt được nó". Trong một ERP program, nó tích tụ khi team hoãn một quyết định architecture vì để sau go-live tính, chọn giải pháp tạm vì deadline đang dí, không chốt được business rule vì stakeholders chưa đồng thuận, hay cứ lấy assumption thay cho data để đi tiếp. Mỗi quyết định bị hoãn là một khoản nợ, và lãi của nó là rework, dev code xong theo assumption thì user mới ơ, hồi đó nói vậy thôi chứ đâu phải vậy. Trong bài [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/) mình có nhắc chuyện sponsor vắng mặt làm mọi quyết định bị treo, theo mình đó chính là decision debt, dự án hỏng không phải vì chọn sai phần mềm, mà vì không ai chốt quyết định đúng lúc. ## vì sao nó nguy hiểm hơn technical debt Technical debt còn có công cụ đo, SonarQube cho bạn biết code quality đang ở đâu, bạn lên kế hoạch refactor dần, tính được cả lãi suất. Decision debt thì vô hình, chẳng có dashboard nào báo bạn đang nợ chừng này quyết định, rework ước tính chừng kia giờ, nó như tảng băng trôi, không thấy cho tới lúc đâm vào. Nó còn ngấm ngầm hơn nhiều. Một quyết định sai thì dễ sửa, quay lại chốt lại là xong, nhưng hàng chục quyết định bị hoãn, mỗi cái dựa trên một assumption khác nhau, tới lúc chúng va vào nhau là dự án vỡ, dev bảo em code theo assumption A, business bảo bên em muốn B, còn BA lúc đó mới ngã ngửa ra là mình quên chốt A hay B từ mấy tháng trước. ## ba dấu hiệu nhận ra Dấu hiệu số một là họp liên tục mà không có decision log, họp xong ai cũng gật, nhưng không ai viết ra đã quyết XYZ, tuần sau họp lại hỏi lại đúng câu đó, không ai nhớ. Dấu hiệu thứ hai là assumption checklist dài hơn cả requirement list, decision log toàn "giả định là...", "chờ confirm với...", "tạm coi như...", tức là bạn đang nợ, vì assumption là một khoản nợ chưa đáo hạn. Dấu hiệu thứ ba là dev bắt đầu code trước khi BA kịp confirm, phải tự đoán business logic vì BA chưa chốt được với stakeholder, lúc đó decision debt đang đẻ lãi, mà lãi thường rất cao. ## BA làm được gì Mình nghĩ BA có trách nhiệm chặn decision debt từ sớm, chứ không chỉ ghi requirement rồi bàn giao. Một việc mình làm thật là khi khách đổi ý ngay trong cuộc họp, mình không chốt tại chỗ, mình ghi nhận yêu cầu, đánh giá ảnh hưởng, rồi hẹn họp sau để quyết, nghe thì chậm, nhưng tránh được kiểu quyết vội rồi lại thành nợ. Ngoài ra theo mình có mấy việc nhỏ đáng thử. Giữ một decision log, sau mỗi workshop ghi lại vài decision đã chốt dù nhỏ, decision còn pending, người chốt và deadline, gửi sớm sau buổi họp, làm đều không bỏ phiên nào. Đặt deadline cứng cho mỗi decision quan trọng, quá hạn thì escalate lên sponsor, không để pending kéo dài vô thời hạn. Coi mỗi assumption là một risk, cái nào để lâu chưa verify thì đưa lên báo động. Và vẽ một cái dependency map cho stakeholders thấy quyết định A chưa chốt thì module B không thiết kế được, team C ngồi chờ, nhìn tận mắt cái giá của việc trì hoãn thì người ta chốt nhanh hơn hẳn. Bài [scope creep, chuyện kinh điển và cách sống sót](/posts/scope-creep-chuyen-kinh-dien-va-cach-song-sot/) cũng có góc nhìn tương tự, càng ngại chốt quyết định thì về sau càng tốn rework. ## không ai về được số không Nói thật thì tránh tuyệt đối decision debt là không thể, ERP program phức tạp, có những quyết định cần thời gian, cần dữ liệu, cần người duyệt đang vắng mặt, cần thử mới biết đáp án. Mục tiêu không phải là zero decision debt, mà là quản lý nó như một loại risk chính thức, biết mình đang nợ gì, ảnh hưởng ra sao, trả dần thế nào. Cũng giống chuyện mình viết trong bài [tích hợp trước AI, bài học từ dược phẩm và quốc phòng](/posts/tich-hop-truoc-ai-bai-hoc-tu-duoc-pham-va-quoc-phong/), cái móng mới quyết định kết quả, chứ không phải tốc độ. Decision debt không hiện trên dashboard, không có số, không có biểu đồ, không có alert, nhưng theo mình BA nào đi qua một dự án ERP cũng cảm được nó, chỉ là có dám nhìn thẳng vào hay không. Dự án bạn đang làm có bao nhiêu quyết định đang chờ confirm, và đã chờ bao lâu rồi? --- # Scope creep, chuyện kinh điển và cách sống sót - URL: https://quanlamba.com/posts/scope-creep-chuyen-kinh-dien-va-cach-song-sot/ - Ngày đăng: 2026-07-26 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Quản lý phạm vi, Kinh nghiệm thực chiến, Quản trị dự án - Mô tả: Hợp đồng chỉ ghi 'module mua hàng' thì CR sẽ không bao giờ dừng. 5 dấu hiệu scope creep đang tới và cách BA giữ phạm vi mà không mất lòng khách. Hợp đồng ghi đúng ba chữ "module mua hàng", nghe thì rõ, nhưng module mua hàng 5 input với module mua hàng 15 input là hai thứ rất khác nhau, mà hợp đồng thì không nói là cái nào. Đây là chuyện mình gặp thật. Phạm vi không được ghi rõ nên change request cứ tới liên tục, scope cứ thế phình ra, và mình không có cách nào từ chối khách, vì chẳng có tờ giấy nào nói cái gì nằm ngoài phạm vi. Scope creep, cái thuật ngữ nghe rất chuyên nghiệp ấy, thực chất là chuyện những cái "thêm tí nữa" không bao giờ dừng, và nó không chỉ là vấn đề của BA mà của cả team, cả dự án, cả cái deadline. ## scope creep có phải lỗi của ai không Phản xạ đầu tiên thường là đổ lỗi, cho khách không biết mình muốn gì, cho PM nhận bừa, cho dev không phản biện sớm. Nhìn lại chuyện "module mua hàng" ở trên thì theo mình gốc nằm ở chỗ khác, phạm vi không được viết ra đủ rõ ngay từ đầu. Khách đòi thêm là chuyện bình thường của một dự án đang sống, cái không bình thường là chẳng có gì để đối chiếu. Vấn đề là mình có thấy nó từ xa không, và có plan để xử lý hay cứ để nó cuốn đi. Bài [BA mới vào nghề: 5 cú sốc không ai nói trước](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/) cũng có nhắc, requirement thay đổi mỗi ngày là chuyện cơm bữa. ## mấy câu nghe là biết scope sắp phình **"Cái này nhỏ thôi, một tiếng là xong."** Câu nguy hiểm nhất làng IT, vì chẳng có gì nhỏ một khi nó chạm vào logic nghiệp vụ. **"Làm luôn cái này, đằng nào cũng đang sửa."** Một cái nhỏ ghép với mấy cái nhỏ khác, thành một cục to không ai lường trước. **"Hồi sáng em mới nghĩ ra, hay quá anh ơi."** Ý tưởng mới lúc nào cũng có vẻ hay, câu hỏi là cái hay đó có đáng để trễ deadline không. **"Khách hàng bảo thêm, không làm mất lòng."** Sợ mất lòng khách là cái bẫy lớn nhất của BA mới, mà không có scope rõ thì nỗi sợ này càng to, vì bạn chẳng có căn cứ nào để nói không. **"BA ơi, cái này giống cái kia, copy qua sửa tí thôi."** Nếu đã giống thì sao lúc elicitation không ai nói? Vì nó không giống. ## cách xử lý Không có công thức thần kỳ nào, đây là những gì mình làm khi có change request, cộng thêm vài điều theo mình nên làm sớm hơn. Đầu tiên là chốt scope baseline rõ ràng trước khi build, một thứ mà cả hai bên cùng nhìn vào và gật đầu đây là scope, không cần document 50 trang, có thể là một cái bảng, một file spreadsheet, thậm chí một cái email, nhưng phải có. Bài [3 nguyên tắc sống còn để lấy yêu cầu hiệu quả](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/) nói kỹ chuyện này. Rồi tách must-have với nice-to-have, ai bảo thêm cái này nữa thì câu đầu tiên không phải có làm được không, mà là có cần cho go-live không, không cần thì cho vào v2. Change request phải đi đúng đường. Cách mình làm là ghi nhận yêu cầu, đánh giá impact, nhờ dev estimate, rồi báo cáo sếp để quyết, không có bước nào tên là gật đầu trong cuộc họp. Câu thần chú là "để em xem tác động rồi trả lời anh", vừa cho mình thời gian đánh giá, vừa cho họ thấy mình không phải cái máy gật đầu. Và change request nào cũng phải kèm trade-off, kiểu làm cái này thì release trễ X tuần, anh chị chọn thế nào, ai cũng có quyền đổi scope, nhưng phải chịu hậu quả của nó. ## không phải lúc nào creep cũng xấu Đôi khi cái "thêm tí nữa" lại làm lộ ra một requirement thật mà elicitation bỏ sót. Giả sử khách đòi thêm một cột kiểm tra hạn thanh toán ở màn hình mua hàng, nghe như thêm việc, nhưng thiếu nó thì kế toán phải dò tay mỗi cuối tháng, cái đó đáng làm. Chỗ khó là phân biệt đâu là **khám phá giá trị** và đâu là **thiếu chuẩn bị**, cái thêm giải quyết một pain point thật chưa ai nghĩ tới thì là discovery value, còn nó vốn nằm sẵn trong requirement từ đầu mà không ai đọc thì là thiếu chuẩn bị. Với mình, lúc nên nói không với khách hay với sếp khá rõ, là khi yêu cầu nằm ngoài scope, nhưng muốn nói được câu đó thì scope phải được viết ra trước, đủ chi tiết để "module mua hàng" không còn hiểu sao cũng được. Thế nên việc đáng làm nhất lại nằm ở đầu dự án, đọc kỹ hợp đồng, hỏi cho ra phạm vi chi tiết, rồi ghi lại. **Scope không rõ thì nói không cũng chẳng ai nghe.** Bạn từng bị scope creep hành thế nào, và có mẹo gì hay để đỡ câu "cái này nhỏ thôi" chưa? --- # ERP cloud: governance mới là thứ giết dự án - URL: https://quanlamba.com/posts/quan-tri-truy-cap-cloud-erp-bai-toan-iam/ - Ngày đăng: 2026-07-22 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, ERP, Cloud ERP, Quản trị truy cập, Chuyển đổi số - Mô tả: Cloud ERP chạy tốt, authentication ổn, integration OK, nhưng governance lại lộ lỗ hổng. Góc nhìn BA về cái bẫy ít ai nói trước khi deploy ERP cloud. Tuần trước mình đọc một bài khá hay trên ERP Today của Sridevi Mutyala bên Oracle, nói về identity governance trong cloud ERP. Bài kể một chuyện tưởng đơn giản, một nhân viên chuyển phòng ban, HR update xong, mấy ứng dụng cloud ERP như Oracle Fusion, SAP S/4HANA, Dynamics 365 đều chạy đúng config, authentication OK, provisioning OK, integration OK, vậy mà quyền truy cập vẫn bị delay, vì approval paths mỗi ứng dụng một kiểu, role definitions không đồng bộ, còn quyết định cấp quyền thì không ai nhớ rõ là của ai. Chuyện ấy quen không? Với mình thì quen lắm. ## công nghệ không phải vấn đề, governance mới là Đoạn mình tâm đắc nhất trong bài là: > Identity management challenges often originate in governance structures that have not kept pace with increasingly interconnected cloud ERP environments. Nôm na là authentication, provisioning, integration đều chạy tốt, chỉ có cấu trúc governance là không theo kịp tốc độ hệ thống phình ra. Đây là cái bẫy ít ai nói trước khi deploy ERP cloud, ai cũng lo migration, data cleansing, integration testing, còn chuyện role definitions có còn đúng không, approval paths có bị phân mảnh không, ai mới là owner thật của quyết định cấp quyền thì hiếm người hỏi. ## governance không phải chuyện của IT Làm BA cho các dự án ERP cloud, mình hay thấy một pattern là đội dự án coi IAM như một workstream kỹ thuật rồi giao cho team security hoặc infrastructure. Bài báo chỉ ra một điểm rất tinh: > The greatest obstacles appeared when governance decisions lacked clear business ownership. Governance là chuyện của business. IT setup được automation, enforce được security policies, nhưng định nghĩa ai được truy cập gì, ai approve, bao lâu review một lần thì là business decision, mà BA lại đứng đúng giữa business và IT, nên BA không đặt mấy câu hỏi governance từ giai đoạn requirements thì đến sau go-live là muộn. Nó làm mình nhớ tới bài ["Em ơi, làm giống Excel cũ nhé"](/posts/em-oi-lam-giong-excel-cu-nhe/), cùng một kiểu vấn đề, stakeholder nghĩ mọi thứ đơn giản vì công nghệ có sẵn rồi, trong khi cái thiếu lại là process design và governance. ## cái bẫy cloud sẽ tự lo Có một giả định khá nguy hiểm khi lên cloud, là cloud ERP có sẵn role-based access control (RBAC) rồi, cứ thế config là xong. Đúng là có RBAC, nhưng RBAC chỉ là cái khung, thứ quyết định là role definitions, segregation of duties (SoD), approval matrices, và mấy cái đó không có sẵn, tổ chức phải tự xây. Bài báo kể trong các cuộc audit người ta hay phát hiện role definitions lệch nhau giữa các ứng dụng, approval workflows mỗi nơi một kiểu, ownership của quyết định cấp quyền mờ dần, tất cả tích lũy qua nhiều năm từ từng thay đổi nhỏ. Cloud không đẻ ra mấy vấn đề này, nó chỉ phơi chúng ra. Bài [ERP Cloud vs On-premise cho nhà máy Việt](/posts/erp-cloud-vs-on-premise-cho-nha-may-viet/) của mình cũng cùng logic đó, chọn cloud hay on-premise không phải câu hỏi duy nhất, câu lớn hơn là tổ chức đã sẵn sàng cho cách cloud vận hành chưa. ## cloud cũng không phải thủ phạm Chạy on-premise thì governance gaps vẫn có, chỉ là ít bị để ý vì mọi thứ chậm hơn, ít nối với nhau hơn, còn cloud ERP với tốc độ thay đổi và số integration nhiều như vậy thì làm lộ lỗ hổng nhanh hơn và đau hơn. Bài báo gợi ý ba việc. Một là role ownership rõ ràng, có người thật sự chịu trách nhiệm về role definitions chứ không để IT tự xoay. Hai là chuẩn hóa approval workflows, không để mỗi business unit làm một kiểu. Ba là coi governance như một kỷ luật vận hành liên tục gắn với vòng đời nhân viên, chứ không phải làm một lần rồi thôi. Cả ba BA đều có thể chủ động đưa vào requirements và solution design ngay từ đầu. Nên lần tới ngồi requirements workshop cho một dự án ERP cloud, thử hỏi đội dự án một câu: > Sau go-live, ai sẽ approve quyền truy cập? Và nếu một người chuyển phòng ban, mất bao lâu để quyền được cập nhật trên tất cả các ứng dụng? Câu trả lời sẽ nói lên khá nhiều về governance của tổ chức, có khi còn nhiều hơn cả cái migration plan. Ở dự án bạn đang làm, governance đang được xử lý như một workstream kỹ thuật giao cho IT, hay như một business process có người chịu trách nhiệm rõ ràng? --- # ERP cloud vs on-premise cho nhà máy Việt, đừng để sale dụ - URL: https://quanlamba.com/posts/erp-cloud-vs-on-premise-cho-nha-may-viet/ - Ngày đăng: 2026-07-19 - Cập nhật: 2026-11-05 - Thẻ: ERP, Cloud ERP, Chuyển đổi số, Nhà máy Việt - Mô tả: ERP Cloud hay On-premise cho nhà máy Việt? Bài này không bênh bên nào: chỉ ra bẫy của từng bên và mấy câu hỏi nên trả lời trước khi nghe sale. Giả sử bạn là giám đốc một nhà máy vừa và nhỏ, trên bàn có hai bảng chào giá, một bên bảo Cloud ERP rẻ hơn, triển khai nhanh, bên kia bảo On-premise mới an toàn, dữ liệu xưởng sao mà đưa lên mây được. Tin ai bây giờ? Theo mình câu trả lời chưa bao giờ gói gọn trong một từ. ## cloud ERP, cái được và cái mất Cloud ERP bán chạy vì không cần đầu tư ban đầu lớn, không mua server, không thuê IT, không lo bảo trì, vendor lo hết, và với nhà máy vừa và nhỏ ở Việt Nam thì đây là đường ngắn nhất để có ERP. Có điều theo mình nó có mấy cái bẫy. Bẫy đầu là vừa chạy vừa ngã. Cloud ERP hứa go-live nhanh, mà nhanh thì dễ cắt xén requirement, giả sử yêu cầu batch tracking bị cắt cho kịp go-live, vài tháng sau xưởng lại quay ra làm Excel song song, đúng kiểu lỗi mình kể trong bài [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/). Bẫy thứ hai là chi phí dài hạn, năm đầu nghe rẻ, nhưng subscription thì trả mãi và có thể tăng theo năm, nên cứ tính tổng chi phí cho vài năm, kể cả số user tăng thêm, rồi hẵng so, đừng so mỗi năm đầu. Bẫy thứ ba là internet. Xưởng ở khu công nghiệp xa trung tâm mà mất mạng là mất ERP luôn, xưởng phụ thuộc hệ thống để chạy lệnh sản xuất thì vài tiếng mất mạng cũng đủ làm production đứng, nên hỏi thật kỹ phương án đường truyền dự phòng. ## on-premise, tưởng an toàn mà cũng đau đầu On-premise nghe an toàn hơn vì dữ liệu nằm ngay trong xưởng, không sợ mất mạng, không phụ thuộc vendor, nhưng câu đầu tiên là IT đâu ra. Nhà máy vừa và nhỏ ở Việt Nam hiếm khi có đội IT riêng, không có người quản trị thì server treo không ai sửa, patch không ai cài, càng chạy càng ì. Rồi upgrade là cực hình. Cloud ERP tự update, còn on-premise mỗi lần upgrade là một dự án riêng, nào test, nào data migration, nào downtime, thế là rất dễ rơi vào cảnh chạy mãi một phiên bản cũ vì không ai dám đụng. Chưa kể chi phí ẩn, license mua một lần nghe rẻ, nhưng cộng thêm server, backup, bảo trì, nhân sự, tiền điện, điều hòa cho phòng server thì tính ra chẳng rẻ chút nào. ## vậy chọn gì Không có câu trả lời chung, nhưng theo mình có thể nghĩ theo khung này. Cloud hợp với nhà máy vừa và nhỏ, chưa có đội IT riêng, mạng ổn định hoặc có đường dự phòng, và chấp nhận đánh đổi là không custom sâu được. On-premise đáng cân nhắc khi nhà máy lớn, chạy liên tục 24/7, có đội IT vận hành, yêu cầu bảo mật cao như sản xuất quốc phòng hay dược phẩm, hoặc xưởng ở vùng sâu mạng chập chờn. Còn hybrid, một ít cloud một ít tại chỗ, là hướng mà mấy vendor lớn như IFS, SAP đang làm, vừa linh hoạt vừa giữ được quyền kiểm soát dữ liệu nhạy cảm. ## công nghệ chỉ là phần nhỏ Theo mình phần lớn câu chuyện nằm ở con người và quy trình. Một dấu hiệu dự án ERP sắp có vấn đề mà mình từng thấy là mọi người work around với phần mềm, có cách né, không làm theo quy trình chuẩn, và dấu hiệu đó chẳng quan tâm hệ thống nằm trên cloud hay trong phòng server. Câu hỏi thật là doanh nghiệp có sẵn sàng đổi cách làm việc hay không, chưa sẵn sàng thì chọn gì cũng thế thôi. Bài học trong [IFS Cloud Procurement Pitfalls](/posts/ifs-cloud-procurement-pitfalls/) cũng áp vào đây được, công cụ không quan trọng bằng cách dùng công cụ. Còn nhà máy của bạn, hoặc công ty bạn đang tư vấn, đang nghiêng về cloud hay on-premise, và vì sao? --- # Tích hợp trước AI: Bài học từ dược phẩm và quốc phòng Mỹ - URL: https://quanlamba.com/posts/tich-hop-truoc-ai-bai-hoc-tu-duoc-pham-va-quoc-phong/ - Ngày đăng: 2026-07-15 - Cập nhật: 2026-11-05 - Thẻ: ERP, Business Analyst, Tích hợp, Chuyển đổi số, SAP - Mô tả: Dược phẩm ưu tiên integration hơn AI khi chạy SAP S/4HANA. Bài học cho BA: governance và integration là nền, AI chỉ là lớp trên. Tuần rồi mình đọc được hai case study trên ERP Today mà ngồi nghĩ cả buổi tối, một bài về ngành dược đang chạy SAP S/4HANA migration nhưng mối quan tâm số một lại không phải AI, một bài về Defense Logistics Agency (DLA) của Mỹ, nơi audit readiness mới là động lực chính cho ERP modernization. Một bên thuốc men, một bên vũ khí, khác nhau hoàn toàn, mà chung một câu chuyện là **AI không cứu được bạn nếu integration với governance chưa có**. Mình từng viết bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/), bài này đi sâu hơn vào cái giá của việc bỏ qua hai thứ đó. ## ngành dược đặt integration lên trước AI Bài báo kể ngành pharma đang migrate lên SAP S/4HANA và chọn **integration với audit readiness làm ưu tiên số một**, hơn hẳn AI adoption. Lý do cũng dễ hiểu, FDA guidance (21 CFR Part 11) về data integrity không cho cắt góc, sản xuất thuốc thì mỗi batch phải trace được từ nguyên liệu đầu vào đến lô xuất xưởng, nên MES, lab systems, quality platforms đều phải tích hợp đồng bộ. Data còn lộn xộn thì AI chỉ tạo ra lộn xộn ở tốc độ cao hơn. Thế nên thứ quan trọng nhất với họ là SAP BTP (Business Technology Platform) và SAP Integration Suite, chứ không phải AI copilot, họ nối các regulated business processes giữa SAP và non-SAP trước, chuyện AI tính sau. ## DLA coi audit là design requirement Case thứ hai còn ấn tượng hơn. DLA, cơ quan hậu cần của Lầu Năm Góc, đang chuyển từ đống legacy systems customize nặng nề sang SAP NS2 PCE RISE Cloud Services, và động lực không phải chuyển đổi số hay AI cách mạng gì cả, mà là **audit deadline 2027**. Họ phải tăng tốc dựng technical baseline, chuẩn hóa process, tạo evidentiary material cho audit, và cái hay là audit không bị coi như một reporting event cuối năm mà là design requirement của cả ERP program ngay từ đầu. Mình thấy bài học này đúng với mọi dự án ERP chứ không riêng quốc phòng, thiết kế hệ thống từ đầu với tư duy mọi transaction đều phải audit được thì về sau đỡ khổ retrofit. Mình đã thấy quá nhiều dự án [thất bại vì bỏ qua governance từ đầu](/posts/tai-sao-du-an-erp-that-bai/). ## BA học được gì Integration không sexy nhưng là xương sống. AI ERP đang hot, Oracle ra Fusion Agentic Applications, IFS xây operations layer, SAP có Joule, bài nào cũng nói AI, nhưng ai làm implementation đều biết chuyện nối MES với ERP, WMS với TMS, lab system với quality module mới là thứ quyết định dự án thành hay bại. Integration không vững thì AI chỉ là cái loa phóng to mớ hỗn độn của bạn lên. Governance cũng không phải chuyện riêng của compliance, audit readiness phải nằm ngay trong architecture, chứ đến giai đoạn testing mới à quên mất cái validation này thì muộn rồi. Là BA, lúc viết requirements mình hay hỏi transaction này ai kiểm tra, cần log những gì, data có cần sign-off không, vì governance là việc của người thiết kế quy trình chứ không phải của sếp. Và AI ngon nhất khi data đã sạch. Bài pharma nói rõ họ không anti-AI, họ đang chuẩn bị để AI chạy cho ra hồn, khi MES, lab systems, quality platforms đã tích hợp đúng, dữ liệu đã đồng bộ, governance đã vững, *lúc đó* AI mới phát huy. ## không phải lúc nào cũng phải chờ Cả hai case đều là môi trường bị quản lý chặt (FDA, DoD). Với doanh nghiệp sản xuất bình thường, bạn có thể chạy song song, vừa clean data vừa thử AI ở phạm vi nhỏ như predictive maintenance, demand forecasting hay anomaly detection trong quality. Cái cần giữ là thứ tự ưu tiên, budget ERP có hạn thì đổ vào integration architecture trước rồi mới tới AI features, đừng để buổi demo AI lung linh của bên sales làm mình quên là data nhà mình còn chưa sạch. Dự án ERP bạn đang làm hay đang tư vấn đã đầu tư đủ cho integration và governance chưa, hay cũng đang chạy theo AI mà quên mất cái móng? --- # SAP, Oracle, IFS, Infor: ai thắng ERP ngành năng lượng? - URL: https://quanlamba.com/posts/sap-oracle-ifs-infor-ai-thang-cuoc-dua-erp-cho-nganh-nang-luong/ - Ngày đăng: 2026-07-08 - Cập nhật: 2026-11-05 - Thẻ: ERP, IFS Cloud, SAP, Oracle, Infor, Ngành năng lượng, Chuyển đổi số - Mô tả: ERP Today so SAP, Oracle, IFS, Infor trong cuộc đua ERP năng lượng. Góc nhìn người trong cuộc về cách chọn đúng cho nhà máy và oil & gas. Mới đây ERP Today có bài phân tích khá hay về cuộc đua ERP ngành năng lượng giữa bốn ông lớn SAP, Oracle, IFS và Infor, đọc xong mình thấy có mấy điểm đáng nghĩ, nhất là với anh em đang tư vấn ERP cho nhà máy hay utility ở Việt Nam. Bài này không nhằm so xem ai tốt nhất, vì câu trả lời lúc nào cũng là tùy, mà để thấy mỗi ông có một góc tấn công riêng, và có cái khung đó trong đầu thì lúc chọn ERP mình đặt câu hỏi đúng hơn. ## SAP, ông già gân đang chạy clean-core SAP mạnh nhất về chiều sâu quy trình ngành, làm oil and gas mà cần hydrocarbon accounting, JV accounting, field logistics, commodity procurement/sales thì SAP có gần như đủ cả. Điểm thú vị là SAP đang đẩy mạnh Public Cloud, bài báo kể Squadron Energy (Úc) deploy S/4HANA Public Cloud cùng BTP và Analytics Cloud chỉ trong **4 tháng**, nhanh đáng kinh ngạc với một renewable operator. Câu hỏi lớn là cái clean-core của SAP có giữ được industry depth không, hay doanh nghiệp lại phải tự xây thêm side systems để bù, đây là bài toán trade-off kinh điển giữa tiêu chuẩn hóa và linh hoạt. Chuyện nền dữ liệu đằng sau lựa chọn này mình có viết trong bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/). ## Oracle, hệ sinh thái cho utility Oracle chơi bài khác, là suite integration, họ không chỉ bán ERP mà bán cả customer operations, asset management, field service, HR, analytics, và cả cloud infrastructure bên dưới. Reference mạnh có Exelon (10.7M customers, 6 regulated utilities), Air Selangor, El Paso Electric, toàn những utility lớn cần một platform đồng bộ. Điểm yếu là cái breadth đó có thật sự tích hợp đủ sâu không, hay chỉ là một đống sản phẩm đặt cạnh nhau, với utility có OT systems legacy nặng thì câu trả lời chưa chắc đã là Oracle. ## IFS, industrial AI và asset-heavy execution Đây là góc mình quen nhất. IFS không cố đấu finance depth với SAP hay breadth với Oracle, họ chơi asset management, field service và enterprise operations, tức là mấy thứ quyết định uptime của nhà máy. IFS Cloud 25R2 ra mắt với Industrial AI và Digital Workers, AI hỗ trợ maintenance accuracy, work order reporting, reliability analysis, kèm Resolve for Utilities cho grid resilience và emergency response, đúng chỗ đau của ngành điện mỗi lần gặp thiên tai. Có điều thách thức lớn nhất của IFS là độ phủ và độ nhận diện. Ở Việt Nam hỏi công ty anh dùng ERP gì thì câu trả lời thường là SAP hoặc một cái tên nội địa, IFS còn lạ lắm, dù sản phẩm ngon. Chuyện AI và sản xuất của IFS mình có viết trong bài [IFS đang xây lớp vận hành cho AI](/posts/ifs-dang-xay-lop-van-hanh-ai-san-xuat/). ## Infor, kẻ bị lãng quên? Bài báo có nhắc Infor nhưng không đi sâu. Từ khi về tay Koch Industries và rút khỏi sàn, Infor gần như im ắng, họ vẫn có CloudSuite cho LN, M3, vẫn mạnh ở fashion và discrete manufacturing, nhưng tiếng nói trong mảng ERP năng lượng thì yếu hẳn. ## chọn thế nào Theo mình câu đầu tiên là ngành của bạn là gì. Oil and gas upstream hay downstream thì SAP là lựa chọn an toàn nhất, regulated utilities như điện, nước thì Oracle có suite utility mạnh, còn vận hành asset-heavy như sản xuất, pipeline, energy services thì IFS đáng cân nhắc. Câu thứ hai là bạn đang ở đâu trên hành trình số, bắt đầu sạch từ đầu thì SAP Public Cloud hay IFS Cloud đều hợp lý, còn legacy nặng và muốn migrate từ từ thì breadth của Oracle giúp gom nhiều hệ thống một lúc. Câu thứ ba là AI có thật sự là ưu tiên ngay bây giờ không. Chưa có data governance, chưa có process ownership thì quên AI đi, mua ERP tử tế trước, tính AI sau, còn nền tảng đã có rồi thì IFS đang dẫn về Industrial AI cho asset-heavy. ## chuyện ở Việt Nam thì khác Phân tích của ERP Today chỉ đúng nếu bạn là doanh nghiệp năng lượng ở Mỹ hay châu Âu. Một nhà máy vừa và nhỏ ở Việt Nam cần ERP thì câu chuyện khác hẳn, budget eo hẹp, đội IT mỏng, quy trình chưa chuẩn, chọn IFS Cloud hay SAP Business One sẽ hợp lý hơn S/4HANA Public Cloud. Câu mình tâm đắc nhất trong bài là: Industrial AI will only scale if ERP buyers strengthen data models, governance, process ownership, and integration discipline before deploying AI. Bao nhiêu dự án AI trong sản xuất vấp vì mọi người chạy trước khi biết đi, pitch AI thì lung linh, data thì không có, takt time còn chưa đo được. Vì sao nền dữ liệu quan trọng vậy thì bạn đọc thêm [bài về data migration](/posts/data-migration-nhung-cai-bay-khong-ai-noi-truoc/) của mình. Công ty bạn, hoặc dự án bạn đang làm, dùng vendor nào? Có ai đã deploy IFS ở Việt Nam cho ngành utility chưa, mình tò mò lắm. --- # Data migration, những cái bẫy không ai nói trước - URL: https://quanlamba.com/posts/data-migration-nhung-cai-bay-khong-ai-noi-truoc/ - Ngày đăng: 2026-07-05 - Cập nhật: 2026-11-05 - Thẻ: ERP, Data migration, Kinh nghiệm thực chiến, Go-live - Mô tả: Năm cái bẫy data migration trong dự án ERP: mỗi phòng một chuẩn, dữ liệu sạch là huyền thoại, legacy mapping, historical data và cutover plan. Data migration làm mình đau đầu nhất ở một chỗ nghe rất cơ bản, là không hiểu rõ thứ tự các loại data phải migrate, cái gì đi trước, cái gì đi sau, cái gì phụ thuộc cái gì, đổ sai thứ tự một cái là dữ liệu phía sau không còn chỗ mà bám. Theo mình đó cũng là lý do data migration không phải chuyện code với script, nó là chuyện hiểu dữ liệu, hiểu con người, hiểu quy trình, và hiểu cả những ô Excel tưởng vô hại. ## mỗi phòng một kiểu Phòng kho gọi vật tư là "VT-001", phòng kế toán gọi là "M001-Vật tư A", phòng mua hàng ghi là "VatTu A (M001)". Ví dụ này là giả định, nhưng theo mình nó không xa thực tế lắm, ba phòng ba cái định danh cho cùng một vật tư, và đến lúc team migration hỏi dùng cái nào làm master thì ai cũng bảo của phòng em mới đúng. Cái bẫy thứ nhất là không có chuẩn dữ liệu chung trước khi migrate. Bạn tưởng mapping là việc của IT, nhưng các phòng ban chưa thống nhất được với nhau thì IT làm gì cũng sai. Chuyện dữ liệu nền này mình có viết trong bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/). ## dữ liệu sạch là huyền thoại Giả sử khách bảo dữ liệu bọn em sạch lắm, mở file ra thì item code có dấu cách thừa, description có ký tự đặc biệt, có ô ghi "xem file đính kèm" thay vì ghi số. Với master data không sạch, cách mình làm là làm template cho khách điền theo chuẩn rồi hướng dẫn họ điền. Data clean cũng không phải làm một lần là xong, nó là một vòng lặp, clean rồi review, review lại lòi ra lỗi mới, rồi clean tiếp, không có kỷ luật và process thì cái vòng này kéo dài tới tận ngày cutover. Nên đừng bao giờ tin ai nói data đã sạch, tự mở ra xem, tự chạy validation script, và lúc nào cũng nên có Plan B. ## legacy mapping, nỗi ám ảnh của BA Theo mình đây là phần BA dễ underestimate nhất, vì [ERP chạy trên dữ liệu chứ không chạy trên phần mềm](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/), mapping sai thì hệ thống đúng mấy cũng ra số sai. Giả sử hệ thống cũ chạy nhiều năm, có field "Ghi chú" mà người dùng lại dùng để nhập số PO, có field "Mã khách hàng" dùng chung cho cả nhà cung cấp, hay một date field thiết kế dd/mm/yyyy mà người dùng nhập tháng trước ngày, nhìn trên màn hình thì số đẹp, tới lúc import mới vỡ lẽ. Legacy mapping vì thế không phải chuyện trường A sang trường B, mà là chuyện hiểu business logic đằng sau từng field, và cái business logic đó thường không có document nào, nó nằm trong đầu mấy anh chị đã dùng hệ thống cũ lâu năm. Thiếu tài liệu thì có khi còn không điều tra nổi tại sao một công thức lại tính như vậy, nó là bug hay là cố ý. ## historical data, càng nhiều càng chết Câu hỏi kinh điển là mang bao nhiêu năm dữ liệu sang hệ thống mới, và khách thường muốn mang hết, vì lỡ sau này cần đối chiếu. Vấn đề là dữ liệu càng nhiều thì migration càng lâu, performance sau go-live càng ì, còn QA thì không thể verify hết đống data lịch sử. Theo mình nên migrate tối thiểu, chỉ mang master data với open transactions, tức là PO chưa đóng, SO chưa ship, work order đang chạy, còn dữ liệu lịch sử để lại hệ thống cũ ở chế độ read-only, cần thì làm thêm cái giao diện tra cứu legacy là đủ. Thuyết phục khách chuyện này không dễ, nhưng gồng cả đống data không ai dùng thì còn mệt hơn. ## cutover plan không có kịch bản cho ngày tồi tệ nhất Cutover plan nào cũng dễ lạc quan. Giả sử plan ghi script chạy mấy tiếng, validation mấy tiếng, sáng mai go-live, rồi script fail giữa chừng, fix mất thêm vài tiếng, validation làm lại, giờ go-live trôi qua mà vẫn chưa xong. Cái này mình có trải qua một phần, một đêm kiểm kê, 4h chiều mới có file kiểm đếm, upload dữ liệu lên hệ thống mất vài tiếng, cả nhóm ở lại tới 1h đêm mới xong. Nên cutover plan phải có rollback plan rõ ràng, không phải kiểu hy vọng không sao mà là nếu sai thì làm gì, có backup dữ liệu, có checkpoint để biết dừng đúng lúc, và theo mình quan trọng nhất là dry run trước ngày chính thức, càng sát thật càng tốt. Lần đầu thường lòi lỗi, lần sau ổn hơn, đến lúc thật thì ít nhất bạn biết mình đang đối mặt với cái gì. ## không phải việc của một team Nói gì thì nói, data migration không phải chuyện một người hay một team làm được mà là chuyện của cả tổ chức, các phòng ban không chịu dành thời gian clean data, thống nhất chuẩn, review mapping thì BA giỏi mấy cũng chịu. Giả sử tới ngày go-live ai cũng biết data chưa sẵn sàng nhưng deadline đã ấn, thế là cứ launch, theo mình kết quả gần như chắc chắn là người dùng ghét hệ thống mới vì data sai, mà lòng tin đã mất thì lấy lại khó lắm. Còn bạn, đã dính cú data migration nào chưa, và cái bẫy nào làm bạn đau nhất? --- # IFS đang xây lớp vận hành cho AI trong sản xuất - URL: https://quanlamba.com/posts/ifs-dang-xay-lop-van-hanh-ai-san-xuat/ - Ngày đăng: 2026-07-01 - Cập nhật: 2026-11-05 - Thẻ: IFS Cloud, AI, Sản xuất thông minh, ERP, Chuyển đổi số - Mô tả: IFS mua Softeon, 7bridges, EmpowerMX không chỉ để thêm module, mà để xây một tầng vận hành nơi AI chạm được vào sàn xưởng, kho và tài sản thật. Tuần trước, một anh quản lý sản xuất gọi mình hỏi: > "IFS giờ mua Softeon với 7bridges làm gì thế? Có phải đang cạnh tranh với Blue Yonder với Manhattan Associates không?" Câu hỏi hay, nhưng theo mình câu trả lời không nằm ở chuyện cạnh tranh WMS với TMS, mà ở chỗ IFS đang xây một lớp vận hành (operations layer) cho nhà máy và tài sản công nghiệp, nơi AI không chỉ phân tích số liệu mà còn ra quyết định dựa trên bối cảnh vật lý thật ngoài xưởng. Bài này mình ngồi gỡ ba thương vụ M&A gần đây của IFS, xem họ đang nhắm tới cái gì, và cái bẫy mà ai làm tư vấn ERP cũng nên biết trước. ## softeon không chỉ là WMS Softeon không phải loại WMS kiểu quét mã vạch rồi nhập kho, nó quản lý robot, tối ưu đường đi của picker và xử lý throughput theo thời gian thực. Cái hay nằm ở chỗ warehouse execution data là thứ ERP truyền thống gần như không chạm tới, ERP biết bạn nhập 100 cái pallet, nhưng không biết anh picker mất 45 giây hay 3 phút để lấy một SKU. Khi Softeon nằm trong hệ sinh thái IFS, dữ liệu đó không còn nằm im trong WMS nữa mà kéo theo cả lịch sản xuất, mua hàng, thậm chí service commitment. ## 7bridges, logistics có thêm mô phỏng 7bridges được mua năm 2025, ra mắt thành IFS.ai Logistics năm 2026, là lớp dành cho transportation optimization nhưng khác TMS cổ điển ở chỗ nó không chỉ tính cước mà còn mô phỏng, kiểu đổi lộ trình này thì chi phí giảm bao nhiêu, carbon footprint tăng bao nhiêu, service level bị ảnh hưởng thế nào. Có điều logistics AI mà không có warehouse data thì chỉ giải được một nửa bài toán, 7bridges thấy cước rẻ mà không biết kho đang quá tải thì cái recommendation đó cũng vứt. ## empowermx và ván cờ ngành nặng tài sản EmpowerMX là phần mềm MRO cho hàng không, và mình thấy vụ này thú vị nhất, vì nó cho thấy IFS không nhắm logistics chung chung mà nhắm vào từng ngành asset-intensive cụ thể. Bảo trì máy bay khác hẳn bảo trì máy ép nhựa, nó dính tới compliance, quy định FAA/EASA và turnaround time cực ngắn. Ghép EmpowerMX, Softeon và 7bridges lại thì bức tranh là kho biết part nào sắp hết, logistics biết đặt part đó từ đâu và ship về hangar nào, MRO biết lịch downtime của từng aircraft, còn ERP ghi nhận chi phí và lên lịch sản xuất. Nghe đẹp nhỉ. Trước đó mình có viết bài [ERP không chạy trên phần mềm mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/), chuyện ở đây cũng y vậy, phần mềm chỉ tốt bằng dữ liệu nó nuốt vào, và operations layer của IFS chỉ có giá trị khi dữ liệu kho, logistics và bảo trì thực sự chảy thông. ## cẩn thận với cái bẫy AI viễn chinh Chỗ này phải nói thật, AI trong ERP đang có một khoảng cách rất lớn giữa tham vọng và production. Bài viết trên ERP Today dẫn lời Mukesh Kumar (SAP America) một câu mình thấy thấm: > *"In public, every leader has an AI strategy. The honest version — many pilots, very little in production."* IFS có tầm nhìn đẹp, nhưng AI chỉ có giá trị khi chạy trên sản xuất thật, chứ demo với dữ liệu sạch trên PowerPoint thì ai chả làm được. Với tư cách BA, mình quan tâm mấy câu hỏi: cross-domain handoff có thật sự trơn không, một warehouse event có trigger được logistics re-plan không; AI recommendation có đi kèm ownership và audit trail không, AI gợi ý sai thì ai chịu; và mấy thương vụ này có tích hợp sâu vào IFS Cloud hay chỉ là add-on dán nhãn lại. Cũng bài báo đó kể một case study, một công ty nông nghiệp toàn cầu dùng SAP Document AI để xử lý consignment orders dạng PDF, ảnh chụp, scan viết tay, kết quả là 70% đơn hàng tự động, giảm 90% effort manual, month-end close rút từ mấy ngày xuống còn 2 ngày. Họ thành công vì bắt đầu từ một compliance problem, chứ không phải từ tham vọng AI. Đừng mua AI feature, hãy mua use case. ## khi nào nên để ý tới operations layer của IFS Theo mình là khi doanh nghiệp có ít nhất hai trong ba thứ, kho riêng, đội logistics và tài sản cần bảo trì nặng, lại vận hành trong môi trường asset-intensive như sản xuất, hàng không, năng lượng, dầu khí, và thấy ERP đã ổn mà execution vẫn là điểm nghẽn. Bài [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/) của mình cũng nói về đúng cái execution gap giữa kỳ vọng và thực tế đó. Với dân tư vấn như mình, IFS đang xây một thứ khác với Oracle hay SAP, họ nhắm vào cái thị trường mà phần mềm không chạy trên mây, nó chạy trên sàn xưởng. Chỗ đó mới đáng chơi. Còn bên bạn thì sao, đã dùng IFS chưa, và chuyện nối kho, logistics với bảo trì lại với nhau đang làm bạn đau đầu ở khúc nào? --- # "em ơi, làm giống Excel cũ nhé": cơn ác mộng của BA - URL: https://quanlamba.com/posts/em-oi-lam-giong-excel-cu-nhe/ - Ngày đăng: 2026-06-28 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Elicitation, Kinh nghiệm thực chiến, Chuyển đổi số - Mô tả: Câu 'làm giống Excel cũ nhé' là ác mộng của BA làm chuyển đổi số: vì sao làm y chang Excel cũ là cái bẫy, và mình né nó thế nào. Giả sử bạn đang họp với một anh trưởng phòng, anh ấy mở ra cái file Excel đã dùng nhiều năm, ô xanh ô đỏ loạn xạ, VLOOKUP chồng lên VLOOKUP, rồi nhẹ nhàng bảo "em ơi, làm giống cái này nhé, đơn giản thôi". Bạn cười, trong lòng thì không cười nổi. Chưa nghe câu đó bao giờ thì chắc bạn chưa làm BA cho dự án chuyển đổi số ở Việt Nam, còn nghe rồi thì chắc bạn hiểu cái cảm giác vừa buồn cười vừa bất lực ấy. ## cái Excel đó có gì đặc biệt Excel cũ không chỉ là một bảng tính, nó là cả một quá trình người dùng tự mày mò, từng cái conditional formatting, từng cái pivot table, từng công thức ghép từ nhiều sheet đều có lý do của nó, mà thường không phải lý do kỹ thuật, là lý do thói quen. Ô màu đỏ nghĩa là "hàng này sắp trễ", ô màu vàng là "đang chờ duyệt", có dòng bị ẩn vì là số tổng hợp cũ họ giữ lại để đối chiếu. Họ thuộc lòng cái file đó, còn mình vào nhìn thì chẳng hiểu gì. Vấn đề là cái Excel ấy ổn cho một người dùng, đưa lên ERP với hàng chục người cùng nhập, cùng xem, cùng báo cáo thì mọi chuyện khác hẳn. Mình từng gặp khách muốn giữ Excel cũ chỉ vì một lý do, là họ báo cáo sếp bằng Excel, mà sếp đọc Excel cũng lâu. Theo mình, trường hợp đó chuyển sang dashboard và báo cáo ngay trên hệ thống là tốt nhất, cho cả người làm lẫn người đọc. Cái bẫy dữ liệu này mình có viết trong bài [ERP không chạy trên phần mềm, mà chạy trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/). ## cái bẫy "làm giống" Nguy hiểm nhất không phải câu nói, mà là cái gật đầu của BA. Gật thì dễ lắm, ừ có mấy cái cột, làm y chang thôi, nhưng theo mình đó là sai to, vì làm giống Excel cũ nghĩa là copy luôn mấy cái workaround họ tự chế ra vì không có hệ thống, giữ nguyên quy trình thủ công trong khi Excel chẳng validate hay enforce business rule nào cả, và đóng khung tư duy vào cách làm cũ trong khi ERP có thể làm tốt hơn nhiều. Rất dễ tưởng việc của BA là làm đúng y chang những gì stakeholder yêu cầu. Theo mình, việc thật là mổ xẻ cái yêu cầu đó, hỏi tại sao họ cần cái ô màu đỏ, cái VLOOKUP kia, rồi đề xuất cách làm tốt hơn, chuyện này bài [3 nguyên tắc sống còn để lấy yêu cầu hiệu quả](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/) có nói kỹ. ## nghe câu đó thì làm gì Không có công thức thần kỳ nào đâu, chỉ có mấy việc mà theo mình nên làm. **Đừng gật đầu ngay.** Câu đầu tiên nên là "anh cho em xem file đó được không?", xem xong rồi hẵng nói. **Hỏi "cái này để làm gì?" thay vì "cái này làm thế nào?".** Người dùng sẽ chỉ cho bạn cách họ làm, còn việc của BA là hỏi tại sao họ làm thế và nó giải quyết vấn đề gì. **Chốt gap giữa Excel và ERP.** Kiểu "Excel làm được A, B, C, ERP có ưu điểm X, Y, Z cho team nhưng sẽ mất một số thói quen cũ, anh chịu trade-off không?", câu hỏi này nghe hơi khó chịu nhưng cần thiết. **Khách chưa tin thì cho chạy song song, nhưng có điểm dừng.** Nhiều khi khách giữ Excel chỉ vì chưa tin hệ thống. Ở một dự án, mình đồng ý cho chạy Excel song song khoảng 2 tuần, số liệu khớp hoàn toàn thì khách ok bỏ Excel. Cái quan trọng là phải có điểm dừng, chứ để song song mãi thì thành làm trùng việc. **Đề xuất quy trình mới, đừng chỉ copy.** Thay vì "em làm màn hình y chang Excel", hãy rủ "mình cùng thiết kế cái tốt hơn nhé, giữ cái hay của Excel, bỏ cái dở, thêm mấy thứ ERP làm được mà Excel không làm được". ## người dùng không ngu Công bằng mà nói, không phải cái gì của Excel cũ cũng nên bỏ, có những logic nằm trong file đó là kinh nghiệm thật của người dùng, chỉ là chưa ai viết ra thôi. Người dùng không ngu, họ chỉ đang dùng công cụ họ có theo cách họ biết, và việc của BA là tách cái hay ra khỏi thói quen, rồi cho họ thấy có cách tốt hơn. Bạn đã nghe câu "làm giống Excel cũ nhé" bao giờ chưa, và lúc đó bạn xử lý sao? --- # ERP không chạy trên phần mềm, mà chạy trên dữ liệu - URL: https://quanlamba.com/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/ - Ngày đăng: 2026-06-24 - Cập nhật: 2026-11-05 - Thẻ: ERP, Business Analyst, Chuyển đổi số, Tích hợp - Mô tả: Nhà máy có ERP, MES, kho đủ cả mà vẫn đối chiếu Excel mệt nghỉ, vì thứ làm nên khác biệt là dữ liệu sạch và tích hợp xuyên suốt. Bài học cho BA làm ERP. Người ta hay hỏi nhau "bên đó chạy ERP gì", như thể chọn đúng phần mềm là xong một nửa dự án, nhưng càng làm mình càng thấy câu hỏi đó đặt sai chỗ, vì hai nhà máy chạy cùng một hệ thống vẫn có thể một bên trơn tru, một bên ngày nào cũng ngồi đối chiếu Excel. Khác nhau ở dữ liệu. ## không phải ERP gì, mà dữ liệu có chạy xuyên không Giả sử một nhà máy có ERP, có MES, có hệ thống kho, nhưng mỗi hệ thống là một ốc đảo, dữ liệu từ PLM sang ERP phải export Excel, từ ERP sang MES lại import bằng tay, mỗi lần đổi cấu hình sản phẩm là một đợt đối chiếu mệt nghỉ. Theo mình, cảnh này không hiếm ở nhà máy Việt. Ai cũng biết dữ liệu quan trọng, nhưng nối được một mạch từ khâu thiết kế đến khâu vận hành thì không nhiều nơi làm được, và phần mềm có xịn đến đâu mà dữ liệu đi bộ qua tay người thì cũng chỉ nhanh bằng người gõ. ## integration gaps, chỗ BA dễ bị ăn hành nhất Theo mình có mấy ranh giới tích hợp dễ đứt gãy nhất trong sản xuất: PLM sang ERP, ERP sang MES, ERP sang hệ thống nhà cung cấp, và ERP sang MRO (Maintenance, Repair & Overhaul). Chỗ nào có ranh giới là chỗ đó có spreadsheet archaeology, tức là cảnh đào bới file Excel để đối chiếu dữ liệu, một revision sai hay một configuration đổi mà không cập nhật kịp là cả chuỗi delivery, quality, exception-management vỡ trận. Làm BA, mỗi lần nghe stakeholder bảo "cái này bọn anh toàn làm thủ công bằng Excel mà, cũng ổn mà" là mình biết ngay đây là pain point thật, vì ổn ở quy mô nhỏ thôi, scale lên là chết. ## ba việc BA nên làm ngay **Map integration gaps trước khi bàn đến AI hay công nghệ mới.** Đừng vội chạy theo AI agents hay digital twin khi còn chưa biết dữ liệu từ PLM sang ERP đã sạch chưa, bước đầu tiên là liệt kê các handoff PLM–ERP, ERP–MES, ERP–supplier, xem chỗ nào còn đối chiếu tay, đó mới là chỗ cần sửa trước. **Predictive maintenance cần master data đáng tin trước.** AI giỏi cỡ nào cũng vô ích nếu asset history, telemetry, configuration records không đáng tin, và theo mình nhiều dự án AI trong sản xuất vấp đúng ở bước này. Làm sạch master data, sửa integration, xong rồi hẵng tính chuyện AI, chứ dữ liệu nền mà bẩn thì AI chỉ sinh ra rác nhanh hơn thôi. **Khép vòng từ NPI sang quản lý tài sản.** Cái handoff từ engineering change sang production, tooling, maintenance, spares planning là một trong những khoảng trống khó nhằn nhất, và người cầm chương trình cần coi đây là việc ưu tiên chứ không phải chuyện để sau. Bài trước mình có nói về [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/), và integration chính là một phần trong đó, cũng gần giống chuyện [cấu hình IFS Cloud Procurement](/posts/ifs-cloud-procurement-pitfalls/), config mà không hiểu dòng chảy dữ liệu thì sớm muộn cũng gặp rắc rối. ## dữ liệu trước, phần mềm sau Không phải nơi nào cũng có tiền và người để làm một nền tảng dữ liệu hoành tráng, mà cũng không cần, cái đáng học là tư duy đầu tư vào dữ liệu trước rồi mới tới phần mềm, giải bài toán integration trước khi bỏ tiền vào công nghệ mới. Theo mình, khi review hệ thống cho một nhà máy thì câu hỏi đầu tiên nên là dữ liệu từ bước A sang bước B mất bao lâu, bao nhiêu người phải gõ lại bằng tay, còn xưởng dùng ERP gì thì hỏi sau. Một việc nhỏ mình làm thật với master data là làm template chuẩn cho khách điền và hướng dẫn họ điền, nghe đơn giản, nhưng dữ liệu vào đúng chuẩn từ đầu thì về sau đỡ đối chiếu hẳn. Bạn đã bao giờ gặp cảnh dữ liệu giữa hai hệ thống phải đi bộ qua Excel chưa, và bạn thuyết phục team đầu tư vào integration trước khi mua công nghệ mới bằng cách nào? --- # BA mới vào nghề: 5 cú sốc không ai nói trước - URL: https://quanlamba.com/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/ - Ngày đăng: 2026-06-21 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, BA mới vào nghề, Kỹ năng mềm, Kinh nghiệm thực chiến - Mô tả: Những cú sốc khi mới làm BA mà trường lớp ít nói: khách nói một đằng cần một nẻo, requirement đổi liên tục, và vài thứ khác bạn nên chuẩn bị trước. Khách nói họ cần cả một đống màn hình quản lý ở nhiều module, mình hì hục đào mãi mới vỡ ra là thứ họ thật sự cần chỉ là một cái dashboard. Sốc nhẹ. Đó là một trong những cú sốc đầu tiên của mình với nghề BA, và nó chẳng có trong giáo trình nào mình từng đọc. Bài này gom lại mấy cú sốc mà BA mới vào nghề hay va phải, trong đó hai cú đầu là chuyện thật của mình, còn ba cú sau là quan điểm của mình về những gì người trong nghề hay gặp. ## khách nói một đằng, cái họ cần là một nẻo Chuyện là có khách yêu cầu rất nhiều màn hình quản lý phức tạp ở các module khác nhau, nghe qua thì tưởng việc to lắm, nhưng khi đào sâu hơn mới thấy thứ họ cần là một dashboard tổng hợp vài chỉ số đơn giản, để theo dõi chỉ số và sự thay đổi theo thời gian, vì họ làm gì có thời gian đi theo dõi công việc từng ngày. Cách đào từ lời khách nói xuống nhu cầu thật, mình viết kỹ hơn trong [bộ kỹ năng khai phá nhu cầu](/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/). Cái sốc ở đây là yêu cầu khách nói ra thường là giải pháp họ đã nghĩ sẵn trong đầu, chứ không phải vấn đề của họ. Theo mình, câu đáng hỏi nhất khi nghe một yêu cầu là "anh chị dùng nó để làm gì, và bao lâu dùng một lần", chuyện này mình có viết thêm trong bài [3 nguyên tắc sống còn để lấy yêu cầu hiệu quả](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/). ## nhiều stakeholder, nhiều cách hiểu, yêu cầu đổi liên tục Cú này cũng là chuyện của mình. Khi nhiều stakeholder cùng tham gia thiết kế chức năng thì mỗi phiên họp lại vắng một vài người khác nhau, buổi này thiếu ông này, buổi kia thiếu ông kia, thế là chẳng bao giờ thống nhất được cách làm, mà gốc của vấn đề là ngay trong quy trình hiện tại họ đã hiểu khác nhau rồi, nên yêu cầu cứ đổi liên tục. Hoá ra yêu cầu đổi nhiều đôi khi không phải do khách khó tính, mà là dấu hiệu bên trong khách chưa thống nhất với nhau. Đoạn này là quan điểm của mình chứ không phải kể mình đã làm. Theo mình, trước khi cãi nhau chuyện sẽ làm thế nào, nên đưa các bên về cùng một bản mô tả quy trình hiện tại (AS-IS) và để họ xác nhận, rồi mỗi quyết định thì ghi lại ai quyết, ngày nào, gửi cho cả những người vắng mặt. Đến lúc yêu cầu đổi, bạn có chỗ để chỉ vào mà hỏi: thay đổi này khác gì so với cái cả nhóm đã thống nhất? ## dev và ba hiểu spec theo hai kiểu Phần này là quan điểm chứ không phải chuyện của mình. Nhiều BA mới vào nghề nghĩ cứ viết spec xong là dev sẽ hiểu, nhưng theo mình BA ngồi giữa stakeholder và dev, mà hai bên cần hai kiểu thông tin khác nhau, stakeholder cần thấy vấn đề của họ được giải quyết, còn dev cần biết dữ liệu nào, logic nào, trường hợp ngoại lệ nào. Viết dài chưa chắc đã rõ, viết sao cho dev hỏi lại ít nhất mới đáng quý. ## cảm giác "mình đang đóng góp gì thế nhỉ" Giả sử một BA mới vào nghề dành mấy tuần đầu chỉ để quan sát và ghi biên bản họp, trong khi dev vẫn code, stakeholder vẫn nói chuyện với nhau, thì cảm giác mình là người đứng ngoài lề rất dễ xuất hiện. Đây là tình huống giả định, không phải chuyện của mình. Theo mình, giá trị của BA nằm ở chỗ nhìn ra những chỗ các phòng ban hiểu quy trình khác nhau mà chính họ không nhận ra, và giá trị đó thường đến muộn hơn cái cảm giác vô dụng. Nếu bạn đang ở giai đoạn này thì cứ tập đi xuống chỗ làm việc thật và hỏi những câu tưởng là ngớ ngẩn. ## không có template nào dùng nguyên xi được Cái này cũng là quan điểm. Template giúp bạn khỏi phải bắt đầu từ trang trắng, nhưng mỗi dự án, mỗi stakeholder một khác, và một tài liệu dày chưa chắc đã có người đọc. Theo mình, BA giỏi là người đọc được tình huống rồi chọn công cụ vừa đủ, thậm chí dám vứt template đi khi nó không giúp gì. --- Kể ra mấy cú sốc này không phải để bạn sợ. Theo mình gần như BA nào cũng sẽ va phải ít nhất một cú, và chính chúng dạy mình làm nghề. Còn bạn, bạn đang gặp cú sốc nào nhất, hay có cú nào mình chưa kể ra? --- # 3 bẫy cấu hình IFS Cloud Procurement team hay mắc - URL: https://quanlamba.com/posts/ifs-cloud-procurement-pitfalls/ - Ngày đăng: 2026-06-19 - Cập nhật: 2026-11-05 - Thẻ: IFS Cloud, Procurement, ERP, Cấu hình - Mô tả: 3 cạm bẫy cấu hình IFS Cloud Procurement: approval route một cỡ, bỏ qua lead time, không dùng Purchase Agreement, nên team vẫn ngập Excel sau go-live. Giả sử module IFS Cloud Procurement đã go-live rồi mà team mua hàng vẫn ngập trong Excel và việc tay, theo mình chuyện này nằm gọn trong [5 lý do khiến dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/), và root cause thường không nằm ở phần mềm mà ở cách người ta set-up nó từ lúc triển khai. Dưới đây là 3 cái bẫy mình thấy lặp đi lặp lại. ## approval route một cỡ cho tất cả Luồng duyệt mặc định của IFS Cloud là phẳng, mọi requisition chạy chung một chain bất kể giá trị, chủng loại hay phòng ban, và nhiều team cứ để vậy với ý nghĩ "sau này refine". Kết quả là cái request mua giấy vài chục nghìn và cái đơn thiết bị bạc tỷ xếp chung một hàng chờ, ông approver nghỉ phép vài hôm là dây chuyền đứng. Cách làm là thiết lập approval route theo điều kiện ngay từ đầu, vì IFS Cloud hỗ trợ route dựa trên document amount, part category, department, project code. Định nghĩa ít nhất 3 luồng, đơn giá trị nhỏ thì auto-approve, đơn tầm trung thì duyệt cấp phòng ban, đơn lớn mới đi multi-tier, còn ngưỡng tiền cụ thể thì mỗi công ty tự chốt theo chính sách của mình, làm vậy thì cycle time rút ngắn thấy rõ. ## bỏ qua lead time ở cấp Part-Supplier IFS Cloud lưu lead time ở link Part Supplier chứ không phải ở header supplier, vậy mà mình thấy nhiều team chỉ nhập một con số chung chung ở master supplier rồi thôi. Vấn đề là cùng một supplier, cái bracket đặc chủng có thể mất mấy tuần còn con bolt tiêu chuẩn chỉ vài hôm, MRP chạy ra đọc chung một con số cho cả hai, thế là bracket về trễ, còn bolt về sớm nằm kho tốn tiền giữ. Cách làm là lúc migrate dữ liệu thì chịu khó điền lead time chính xác cho từng part, một cái spreadsheet 3 cột Supplier ID, Part ID, Lead Time (ngày), rồi upload qua Data Import tool của IFS Cloud. Mất một buổi chiều, đổi lại tiết kiệm hàng tuần đi expediting sau này. ## không dùng Purchase Agreement cho hàng mua định kỳ Purchase Agreement với agreement lines là một trong những tính năng bị underuse nhất của IFS Cloud Procurement. Team mua hàng cứ dùng purchase order một lần cho những thứ mua đi mua lại hàng tháng như văn phòng phẩm, MRO consumables, bao bì, cùng supplier, cùng giá, thành ra tháng nào buyer cũng copy PO cũ, đổi ngày, sửa số lượng, tháng nào cũng cùng một thao tác, cùng rủi ro nhập sai, và cùng một mớ thời gian vứt đi. Cách tốt hơn là tạo blanket Purchase Agreement với agreement lines cho từng recurring item, gồm giá, thời hạn, call-off terms, rồi dùng Requisition Auto-Release để tự sinh PO từ agreement khi tồn kho chạm reorder point. Setup mỗi agreement không mất bao lâu, còn phần thao tác lặp lại hằng tháng của từng buyer thì gần như biến mất, nhân lên cả team là con số đáng kể, chỉ từ một lần đổi cấu hình. ## ngày 1 hay ngày 90 Ba cái trên không phức tạp, không cần code custom, không cần consultant đắt tiền, chỉ cần nghĩ về thực tế vận hành trước khi lock cấu hình. Lần tới set-up IFS Cloud Procurement, thử tự hỏi một câu, cái này chạy được vào ngày 90 hay chỉ chạy được ngày 1? Mấy việc cần chốt trước ngày đầu tiên mình có ghi trong bài [go-live: chuẩn bị gì, sai gì, sửa gì](/posts/go-live-chuan-bi-gi-sai-gi-sua-gi/). Bên bạn có cái bẫy cấu hình nào làm team mất cả tuần sửa không? --- # chào mừng đến Quân làm BA blog - URL: https://quanlamba.com/posts/welcome/ - Ngày đăng: 2026-06-19 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, ERP, IFS Cloud - Mô tả: Quân làm BA Blog: blog của Đức Quân, Business Analyst triển khai ERP, IFS Cloud, Supply Chain, kể bài học thực tế từ nhà máy sản xuất. Mình mở blog này vì một lý do khá ích kỷ, là viết ra thì mới biết mình hiểu đến đâu. Mấy năm đi làm, có những thứ mình cứ tưởng là hiểu rồi, đến lúc ngồi gõ lại thành câu cho người khác đọc mới lòi ra chỗ nào mình còn mơ hồ, nên blog này về cơ bản là cái bàn nháp của mình. Nháp công khai. ## mình là ai Mình là Đức Quân, nghề chính là Business Analyst, chuyên triển khai ERP và quản lý chuỗi cung ứng (SCM) trong các nhà máy sản xuất. Việc hằng ngày xoay quanh **IFS Cloud**, từ procurement, inventory đến manufacturing, cộng thêm mấy dự án ERP tự viết. Mình có chứng chỉ CBAP của IIBA, nhưng thứ giúp mình làm được việc không phải mấy chữ cái đó, mà là những buổi chiều đứng dưới xưởng nghe quản đốc chửi hệ thống. Bản đầy đủ hơn, làm gì, ở đâu, liên hệ thế nào, mình để ở trang [Về mình](/about/). ## blog này viết về gì Có năm mảng chính, xoay quanh đúng mấy thứ mình làm hằng ngày: - **Triển khai ERP**: chuyện thật từ dự án, go-live, data migration, phạm vi phình ra, quyết định bị treo. - **IFS Cloud**: cấu hình, mấy cái bẫy trong module, những thứ tài liệu không nói. - **Supply Chain**: procurement, tồn kho, kế hoạch sản xuất. - **Business Analysis**: BABOK đọc sao cho không ngủ gật, kỹ năng hỏi, viết requirement, làm việc với stakeholder. - **Góc cá nhân**: chuyện nghề, lương, chuyển ngành, và cả mấy ngày thấy mình vô dụng. Mình cố không viết lý thuyết suông, bài nào cũng muốn trả lời được câu hỏi cái này áp vào công việc thứ Hai tới như thế nào. ## mới vào thì đọc gì trước Mình ghét kiểu để người đọc tự bơi, nên tùy bạn đang ở đâu mà chọn đường vào. Nếu bạn mới toe với nghề BA, đọc [Business Analyst là gì?](/posts/the-tum-lai-business-analyst-la-gi-nhuy/) để nghe người trong nghề nói chứ không phải định nghĩa trong sách, rồi [BA mới vào nghề: 5 cú sốc không ai nói trước](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/) cho đỡ sốc, và [tự học BA 6–9 tháng](/posts/tu-hoc-ba-6-9-thang-lich-that/), một lịch học thật chứ không phải lộ trình bán khóa học. Nếu bạn đang làm dự án ERP và thấy sai sai, có [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/), [3 cái bẫy cấu hình IFS Cloud Procurement](/posts/ifs-cloud-procurement-pitfalls/) cho ai đang vật lộn với mua hàng sau go-live, và [ERP không chạy trên phần mềm, mà trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/). Nếu bạn chuẩn bị thi chứng chỉ, đọc [CBAP, CCBA hay ECBA?](/posts/chung-chi-ba-cbap-vs-ccba-vs-ecba-chon-cai-nao/), chọn theo kinh nghiệm thật của mình chứ đừng chọn theo oai. Còn nếu đang tìm việc thì có [portfolio BA khi chưa có dự án khách](/posts/portfolio-ba-khi-chua-co-du-an-khach-case-simulation/), làm case simulation để bù cho phần kinh nghiệm. ## mình viết cho ai Cho chính mình hồi mới chân ướt chân ráo vào nghề, tức là sinh viên, BA fresher, người từ ngành khác nhảy sang, và mấy anh chị đang làm dự án mà chẳng ai giải thích cho tại sao. Mình cũng viết cho mấy bạn đang nghĩ "hay là bỏ nghề", mình không khuyên bạn ở lại đâu, chỉ kể lại mình đã đi qua đoạn đó thế nào thôi. ## bao lâu một bài Thường hai tuần một bài, hay rơi vào thứ Năm, và mình không hứa gì hơn, vì có tuần dự án cháy thì bài trễ, mà mình cũng không định giả vờ là người đọc không nhận ra. Bài cũ thỉnh thoảng mình quay lại sửa, vì sai số, vì diễn đạt chưa tới, hoặc đơn giản là mình đã nghĩ khác đi, chỗ nào sửa thì trang bài đó sẽ hiện ngày cập nhật. ## đọc sao cho có ích Đừng đọc liền một mạch, cứ chọn một bài đúng chỗ bạn đang kẹt, đọc xong mang đi thử luôn trong tuần đó. Kiến thức về BA với ERP rất dễ thành "biết rồi", cái khó là làm được một lần, và mình viết cũng là để tự nhắc mình chuyện đó. Bạn đang kẹt ở đâu trong công việc hiện tại, và bài nào ở đây có thể giúp bạn thử một cách làm khác vào tuần tới? --- # tại sao dự án ERP thất bại: 5 lý do từ chiến hào - URL: https://quanlamba.com/posts/tai-sao-du-an-erp-that-bai/ - Ngày đăng: 2026-06-19 - Cập nhật: 2026-11-05 - Thẻ: ERP, Thất bại, Bài học - Mô tả: 5 lý do dự án ERP thất bại từ thực tế: chọn phần mềm trước khi khảo sát, copy quy trình cũ, sponsor vắng mặt, test dữ liệu giả, thiếu metrics. Go-live xong, hệ thống chạy, nhưng người dùng lại work around, có cách né, không làm theo quy trình chuẩn, file Excel vẫn mở sẵn "cho chắc". Với mình, đó là dấu hiệu rõ nhất một dự án ERP sắp có chuyện. Vậy cái gì dẫn tới đó? Dưới đây là 5 lý do, có cái mình gặp thật, có cái là quan điểm của mình, và nếu bạn muốn một ví dụ cụ thể thì bài [3 cái bẫy cấu hình IFS Cloud Procurement](/posts/ifs-cloud-procurement-pitfalls/) cũng xuất phát từ những lỗi tương tự. ![5 lý do ERP thất bại](/images/posts/erp-failure-infographic.jpg) ## bắt đầu từ phần mềm chứ không từ vấn đề Nghe quen không, sếp đi hội thảo về, ký hợp đồng với vendor ERP xong rồi mới gọi BA vào bảo "giờ em đi khảo sát requirement đi". Cái dở là requirement không phải thứ để đi khảo sát sau khi đã chọn xong phần mềm, nó là thứ quyết định chọn phần mềm nào, chứ không phải ngược lại. Theo mình, làm ngược thì rất dễ rơi vào cảnh còng lưng custom một module mà phần mềm vốn không được thiết kế để làm, chỉ vì lúc chọn chẳng ai hỏi "cái này có thật sự giải quyết vấn đề của mình không?". ## "cứ làm giống quy trình cũ đi em" Câu này quen lắm. Theo mình, người ta nói vậy vì không thích thay đổi, hoặc không muốn học lại từ đầu, và mình từng gặp stakeholder cứ báo bận, tìm đủ cách không tham gia dự án, chỉ vì không thích phải thay đổi. ERP không phải bản số hóa của quy trình giấy, nó là cơ hội để chuẩn hóa, cắt bỏ những bước thừa, tự động hóa những thứ đáng lẽ không cần người làm. Nhưng khi BA chiều stakeholder quá thì kết cục là một cái ERP chạy y hệt quy trình cũ, chỉ khác là giờ nhập liệu trên màn hình thay vì trên giấy, tốn cả một dự án để đổi lấy cái Excel màu mè hơn. Hơi phí. ## sponsor vắng mặt, hoặc chỉ sếp có mặt Giả sử giám đốc nhà máy là sponsor dự án, đồng thời là người bận nhất công ty, họp steering committee thì gửi trợ lý đi thay, còn mỗi lần cần quyết chuyện lớn như đổi quy trình hay thêm budget thì lại "để anh hỏi sếp đã". Sponsor vắng mặt thì quyết định nào cũng bị treo, dự án vẫn chạy nhưng chạy mà không có người cầm lái, và đến lúc go-live sponsor mới thấy hệ thống không giống mình tưởng tượng. Ngược lại cũng nguy hiểm không kém, là chỉ có sếp có mặt. Mình từng đi lấy yêu cầu mà chỉ được làm việc với sếp, không được gặp nhân viên trực tiếp làm, sếp chốt sai, tới UAT nhân viên mới báo là không ổn. Sponsor cần có mặt để quyết, nhưng người làm thật cũng phải có tiếng nói. ## test bằng dữ liệu giả, và test thiếu người Giả sử UAT chỉ chạy bằng vài dòng dữ liệu mẫu, chạy ngon lành, rồi go-live xong đổ dữ liệu thật vào thì lỗi lòi ra đủ kiểu, trùng mã, sai định dạng, thiếu trường bắt buộc. Cách viết kịch bản để tránh chuyện này mình để ở bài [UAT cho dự án ERP](/posts/uat-kich-ban-uat-du-an-erp/). Theo mình, dữ liệu thật lúc nào cũng bẩn hơn mình tưởng, nên với master data mình hay làm template chuẩn cho khách điền và hướng dẫn họ điền cho đúng. Thêm một chuyện mình gặp thật, là UAT không như kỳ vọng vì user không có thời gian tham gia test, nên kịch bản UAT nên đi theo quy trình end to end, và phải giữ được lịch cho người dùng thật ngồi test. ## không đo được thành công "Hết dự án là xong" là một câu sai, vì hết go-live mới là bắt đầu, mà nếu từ đầu không có metrics thì lấy gì biết dự án thành công hay không? Theo mình, câu nên hỏi trước dự án là "sau go-live một thời gian, anh chị muốn thấy điều gì khác?", không ai trả lời được thì sau này câu "ERP chẳng cải thiện được gì" cũng chẳng ai cãi được, vì chưa từng định nghĩa cải thiện là cái gì. ## nói cho công bằng Có những lúc phần mềm chọn sai thật, hoặc vendor yếu thật, nhưng theo mình kể cả khi đó thì năm cái trên vẫn làm mọi thứ tệ hơn, và phần lớn là lỗi ở cách mình làm dự án. {{< compare title="5 lý do ERP thất bại — Tổng kết" >}} | # | Vấn đề | Hậu quả | Cách tránh | |---|--------|---------|------------| | 1 | Chọn phần mềm trước, khảo sát sau | Custom module không phù hợp | Requirement → chọn ERP, không ngược lại | | 2 | Copy quy trình cũ nguyên xi | ERP thành "Excel màu mè" | Chuẩn hoá + cắt bỏ trước khi số hoá | | 3 | Sponsor vắng mặt, hoặc chỉ sếp có mặt | Trì hoãn, chốt sai | Sponsor có mặt để quyết, user thật được hỏi | | 4 | Test bằng dữ liệu giả, thiếu user | Lỗi lòi ra khi go-live | Làm sạch data thật, UAT end to end có user thật | | 5 | Không có metrics thành công | Không biết dự án có hiệu quả không | Định nghĩa metrics trước, đo lại sau go-live | {{< /compare >}} Hỏi thật, dự án ERP của bạn đang bị cái nào trong năm cái trên âm thầm giết dần? --- # 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả - URL: https://quanlamba.com/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/ - Ngày đăng: 2025-12-15 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Kinh nghiệm thực chiến, Elicitation, Chuyển đổi số - Mô tả: Ba nguyên tắc lấy yêu cầu mình rút ra từ dự án ERP/MES: chuẩn bị kỹ, vẽ ra cho người ta thấy, và nghe mà đầu vẫn phải nhảy số. Lấy yêu cầu nghe thì đơn giản, cứ đến ngồi hỏi rồi ghi lại là xong, nhưng làm thật rồi mới thấy nó dễ biến thành ác mộng thế nào, và mấy nguyên tắc dưới đây là những thứ mình đúc ra từ chính các vết sẹo của mình ở dự án ERP/MES. ## hai trở ngại lớn Cái bẫy đầu tiên là kinh nghiệm. Thiếu kinh nghiệm thì mình chỉ khai thác được phần nổi của tảng băng, còn phần chìm thì nằm ở mấy chỗ khách hay quên kể như các trường hợp ngoại lệ (business cases), các rủi ro kỹ thuật kiểu tích hợp hệ thống hay chuyển đổi dữ liệu, và phức tạp nhất là yếu tố con người. Cái này không có đường tắt, phải trầy vi tróc vảy qua ít nhất một dự án trọn vẹn mới mong thuần thục. Theo mình, nếu chỉ cầm bảng câu hỏi mẫu đi hỏi thì bạn sẽ chỉ nhận về đúng phần nổi đó, còn nếu người cần hỏi lại né tránh thì xem thêm [cách làm khi stakeholder không hợp tác](/posts/stakeholder-khong-hop-tac-lam-gi-khi-khong-ai-muon-noi-chuyen/). Trở ngại thứ hai là lúc lời nói bất lực, mình diễn đạt một đằng, ý trong đầu một nẻo, thế là đối tác hiểu sai. Cách của mình là vẽ, vẽ mọi lúc mọi nơi, trên bảng trắng, giấy nháp, PowerPoint, Excel, cái gì vẽ được thì vẽ. ## nguyên tắc 1: luôn chuẩn bị Fail to prepare là prepare to fail, câu này cũ nhưng chưa bao giờ sai. Thứ đầu tiên cần chuẩn bị là bảng câu hỏi, và nó phải được tùy biến cho từng khách hàng chứ đừng dùng template chung. Nguyên liệu thường là RFP (hồ sơ mời thầu) hoặc UR (yêu cầu người dùng), mà mấy tài liệu này thường mông lung lắm nên càng cần câu hỏi để làm rõ, còn nếu không có RFP thì phải ngồi với Sales hoặc PM để nắm pain point của khách. Bảng câu hỏi mình hay dùng có bốn cột: số thứ tự, câu hỏi, câu trả lời ghi nhận, và người hay bộ phận chịu trách nhiệm trả lời. Làm xong thì nhờ một anh chị senior trong team review để lấp lỗ hổng kiến thức. Các kỹ thuật hỏi cụ thể hơn mình gom trong [bộ kỹ năng khai phá nhu cầu thật](/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/). Thứ hai là chọn đúng người. Workshop nên tối giản, chỉ mời người liên quan trực tiếp, nói chuyện kho thì mời thủ kho, nói chuyện sản xuất thì mời quản đốc, rồi gửi khách một lịch chi tiết ngày nào, giờ nào, cần gặp ai. Mục đích là đừng làm khách mệt, vì khách mệt thì trả lời qua loa, requirement tệ, và dự án fail từ đó. Thứ ba là biết mình muốn mang gì về trước khi bước vào phòng họp, quy trình Sales, cách làm hợp đồng hay sơ đồ tổ chức, có mục tiêu rồi mới chọn được cách moi tin cho đúng. Và giai đoạn này là để moi tin, đừng sa đà vào tư vấn quá sớm. Mình đến để nghe họ nói, chứ không phải để dạy họ làm. ## nguyên tắc 2: khi cần là phải show Nói anh không hiểu thì show hình cho anh xem, màn hình phần mềm, mockup, sơ đồ, diagram, cái gì cũng được. Có hình thì người nghe đỡ buồn ngủ vì mắt có cái để nhìn, cả phòng về cùng một góc nhìn thay vì ông nói gà bà hiểu vịt, và thảo luận cũng dễ hơn vì chỉ thẳng vào từng ký hiệu, từng bước. Thực hành thì đơn giản thôi, đứng dậy, cầm bút lông, vừa vẽ lên bảng vừa nói "hàng về thì ông Kho nhận, rồi đẩy sang ông Kế toán...", khách xác nhận đúng sai chỉ trong 5 giây, hiệu quả gấp trăm lần nói suông. ## nguyên tắc 3: tỉnh táo khi lắng nghe BA không phải máy ghi âm hay thư ký, nên khi nghe thì đầu phải nhảy số liên tục. Cùng một câu hỏi, hỏi ông A và ông B có ra cùng đáp án không, lệch là có chuyện. Câu trả lời cho vấn đề A có chỗ nào mâu thuẫn với quy trình B nghe hôm trước không, có thì phải đào sâu. Cứ hỏi, phân tích, tổng hợp, rồi mới vẽ ra được bức tranh tổng thể cho chính xác, và đừng quên kiểm tra chéo với team nhà, Dev hay Tech lead, xem giải pháp có khả thi không. Sơ suất vớ nhầm thông tin sai là tèo ngay. ## mấy vết sẹo Mình từng sai nhiều vì thiếu chuẩn bị, và chính mấy vết sẹo đó mới thành ra các nguyên tắc ở trên. Họp lấy yêu cầu không đáng sợ đến thế, miễn là nắm được nguyên tắc và lúc nào cũng sẵn sàng sửa sai. *Bài đăng lần đầu trên [quanlamba.wordpress.com](https://quanlamba.wordpress.com/2025/12/15/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/).* --- # bộ kỹ năng khai phá nhu cầu thật mà ba nào cũng cần - URL: https://quanlamba.com/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/ - Ngày đăng: 2025-12-15 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Elicitation, ERP, Sản xuất, Quân làm BA - Mô tả: Bài học từ một dự án ERP nhà máy cơ khí: phần mềm xịn mà không ai dùng, và bộ kỹ năng khai phá nhu cầu thật để BA không lặp lại chuyện đó. Sản phẩm làm ra xịn thật, giao diện đẹp long lanh, nhưng không ai dùng, anh em thủ kho vẫn lén ghi sổ tay, còn dữ liệu trên phần mềm thì sai bét nhè. Đó là bài học đắt giá từ một dự án ERP ở nhà máy cơ khí, và gốc của nó nằm ở chỗ BA chỉ ghi lại đúng lời Giám đốc nói, "làm cho anh cái phần mềm quản lý kho thông minh hơn, xịn hơn", mà không ai đào xem phía sau câu đó là nhu cầu gì. ## đừng tin ngay những gì họ nói Yêu cầu của stakeholder giống tảng băng trôi, BA chỉ nhìn phần nổi thì sớm muộn cũng đâm đầu vào đá. Mình hay tách nó ra ba lớp cho dễ hình dung: | Lớp yêu cầu | Ví dụ | |-------------|-------| | **Stated** (nói ra) | "Anh muốn có nút Xuất Excel báo cáo tồn kho." | | **Implied** (ngầm định) | "File Excel phải giữ nguyên định dạng để in ra ký, số liệu phải khớp thực tế từng phút." Họ coi đó là hiển nhiên nên không nói. | | **Real needs** (nhu cầu thật) | Họ cần nút Excel vì sếp bắt báo cáo hàng tuần, và họ phải cộng trừ thủ công mất cả ngày thứ Bảy. | Nhìn đến lớp thứ ba mới thấy giải pháp thật chẳng phải cái nút Excel, mà là một dashboard tự cập nhật số liệu lên tivi của sếp, khỏi báo cáo, khỏi in ấn. Còn cứ mù quáng làm theo lời nói thì kiểu gì cũng dính scope creep, sửa đi sửa lại không dứt. ## mấy kỹ thuật moi tin, phiên bản nhà máy Lý thuyết có cả rổ kỹ thuật, nhưng mang xuống nhà máy thì phải linh hoạt, mấy cái dưới đây là những cái mình thấy hợp với môi trường sản xuất nhất. **Phỏng vấn, nhưng đừng hỏi "anh muốn gì?"** Hỏi trúng nỗi đau của họ, kiểu "khó khăn lớn nhất khiến anh hay bị trễ đơn hàng là gì?", lúc đó họ mới kể ra vấn đề thật như vật tư về chậm, máy hỏng vặt, và đấy là mỏ vàng của BA. **Quan sát, đi Gemba.** Xuống xưởng đứng cạnh cô công nhân đóng gói, để ý xem vì sao cô ấy phải dừng máy để ghi vào tờ giấy nhàu nát, rồi nhìn lên máy thấy dán đầy giấy note "Lưu ý: mã hàng X hay bị kẹt". Đó chính là yêu cầu ngầm định mà không ai nói ra. **Workshop, một sàn đấu vật có trọng tài.** Khi ông Kho với ông Mua hàng cãi nhau chuyện hàng về trễ thì lùa hết vào một phòng, BA làm facilitator, cho họ cãi chán rồi thống nhất một quy trình chung, chứ gặp riêng từng người thì người nào cũng đổ lỗi cho người kia, dân dự án gặp chuyện này suốt. **Phân tích tài liệu.** Mượn cuốn sổ tay, mượn file Excel lủng củng của kế toán xưởng về đọc, sẽ thấy quy trình đang chạy thật khác xa quy trình ISO trên giấy. **Benchmarking.** Sếp gửi link video "nhà máy thông minh của Đức" rồi bảo "làm cho anh giống thế này" thì đừng hoảng, cứ phân tích xem video đó giải quyết vấn đề gì, rồi hỏi thẳng "anh tâm đắc nhất đoạn nào, robot tự hành hay hệ thống báo cáo?". Còn brainstorming, survey, prototyping thì để dành bài khác. ## công cụ là bạc, tư duy mới là vàng Kỹ thuật thì học được, nhưng thứ làm sản phẩm có hồn là thấu cảm. Đặt mình vào chỗ người công nhân đứng hết ca rã rời chân tay, mình sẽ tự hiểu vì sao giao diện cần nút bấm to, dễ nhìn, thao tác càng ít càng tốt. Thứ còn lại là tư duy phản biện, mà công cụ đơn giản nhất là cứ hỏi "tại sao" cho đến khi chạm gốc. Số liệu sai, tại sao? Do nhập sai. Tại sao nhập sai? Do mã hàng dài quá khó nhớ. Thế tại sao không dùng mã vạch? Đến đây mới chạm vào root cause. ## đi tìm sự thật Khơi gợi yêu cầu không phải điền vào chỗ trống, nó là hành trình đi tìm sự thật, và BA cần chuyển từ người hỏi "cần gì?" thành người tư vấn "nên làm gì để giải quyết vấn đề?". Làm ra một phần mềm ERP không khó, làm ra cái phần mềm mà anh em dưới xưởng chịu vứt cuốn sổ tay đi để dùng mới khó. Muốn đọc tiếp thì có bài [3 nguyên tắc sống còn để lấy yêu cầu](/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/) và [BA trong nhà máy: 6 món võ](/posts/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/). --- # ba trong nhà máy: 6 món võ để không gãy dự án - URL: https://quanlamba.com/posts/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/ - Ngày đăng: 2025-12-11 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, BABOK, ERP, Tư duy làm nghề, Quân làm BA - Mô tả: Sáu Knowledge Area của BABOK, Việt hóa thành sáu món võ phòng thân cho BA trong nhà máy, để không bị task đè và không làm ra hệ thống đắp chiếu. Ngày đầu đi làm BA, mình từng nghĩ "cần gì mấy thứ này, cứ lao xuống xưởng hỏi khách hàng cần gì rồi về bảo IT code là xong", rồi đời dạy cho một bài rằng không như là mơ. Bài này là sáu vùng kiến thức (Knowledge Areas) của BABOK mà mình thấy giúp BA trong nhà máy trụ được, viết lại bằng ngôn ngữ bình dân cho dễ nhớ. Với mình, kiến thức trong sách, tức BABOK, là cái móng nhà, còn kinh nghiệm thực chiến là những viên gạch, thiếu cái nào thì nhà cũng đổ. BA trong nhà máy lại là nghề làm dâu trăm họ, vừa phải hiểu chuyện sản xuất vừa phải nói chuyện được với đội Dev, nên cứ lao vào làm mà thiếu phương pháp thì dự án gãy lúc nào không hay. ## planning & monitoring: đừng để nước đến chân mới nhảy BA không ỷ lại vào Project Manager được, vì lịch của nhà máy lủng cà lủng củng lắm, hôm nay bận kiểm kê, mai lại quyết toán thuế bất ngờ, mình không chuẩn bị trước thì đến lúc cần gặp người là không gặp được ai. Cho nên cần một BA Approach rõ ràng: gặp ai, lúc nào, chuẩn bị gì trước khi gặp. Có cái đó thì mình chủ động được, chứ không thì task cứ dồn dập đè lên đầu. Mệt lắm. ## elicitation & collaboration: nghệ thuật moi tin Thông tin không bao giờ nằm sẵn trên mặt bàn, nó nằm trong đầu người dùng, nên việc của BA không chỉ là "lấy yêu cầu" (gather) mà là khơi gợi (elicitation). Công nhân hay quản đốc sẽ không nói bằng ngôn ngữ phần mềm, họ chỉ than "máy hay hỏng lắm", "viết giấy mỏi tay lắm", và BA phải ngồi trà đá, hút thuốc cùng họ mới moi ra được pain point thật nằm sau lời than đó. ## requirements life cycle management: trị bệnh sáng nắng chiều mưa Hôm nay sếp chốt "làm nút màu xanh", tuần sau sếp đổi ý "thôi màu đỏ cho hợp phong thủy", đây là ác mộng của mọi dự án, và nếu BA gật đầu vô tội vạ thì scope nát bét. Kỹ năng ở đây là biết lúc nào nói có, lúc nào nói không, và đánh giá được thay đổi đó ảnh hưởng đến tiến độ với tiền bạc ra sao, tất cả phải đi qua quy trình, giấy trắng mực đen, chứ không dựa vào lời nói. Chuyện yêu cầu phình dần mình có viết riêng ở bài [scope creep](/posts/scope-creep-chuyen-kinh-dien-va-cach-song-sot/). ## strategy analysis: nhìn rừng chứ đừng chỉ nhìn cây Khách bảo "anh muốn mua phần mềm CRM", BA non tay sẽ đi tìm CRM ngay, còn BA có tầm sẽ hỏi ngược lại: tại sao anh cần CRM, chiến lược ba năm tới là bán lẻ hay bán buôn, anh muốn tăng doanh số hay giữ chân khách cũ? Hiểu đúng chiến lược thì mới tư vấn đúng giải pháp, mà đôi khi thứ họ cần chẳng phải CRM, chỉ là chấn chỉnh lại quy trình Sales đang lộn xộn thôi. ## requirements analysis & design definition: làm người phiên dịch Dịch sai một chữ là ông Dev code sai một dặm. Khi ôm về một đống thông tin hổ lốn từ xưởng, BA phải xào nấu lại thành sơ đồ (flowchart), thành mô hình dữ liệu, thành bản mô tả (SRS) để IT đọc là hiểu ngay, và khâu này đòi tư duy logic rất chắc tay. ## solution evaluation: dùng được hay đắp chiếu? Làm ra một hệ thống xịn sò mà không ai dùng thì giá trị của BA bằng 0. Đánh giá giải pháp không dừng ở chuyện hết bug, mà phải quay lại hỏi nó có giải quyết được vấn đề ban đầu không: công nhân có chịu dùng không hay vẫn lén ghi giấy, doanh nghiệp có tiết kiệm được chi phí không, và rốt cuộc giá trị thật nó mang lại là gì. ## móng và gạch BABOK là nền móng, thực chiến là gạch xây, chỉ có một thứ thì nhà vẫn đổ. Trong môi trường sản xuất rối rắm, sáu món võ trên gói lại thành mấy việc rất đời: chủ động lên kế hoạch, moi đúng nỗi đau, giữ chặt thay đổi, nhìn chiến lược trước khi nhìn tính năng, phiên dịch nghiệp vụ sang công nghệ cho chuẩn, và sau go-live thì quay lại xem cái mình làm có ai dùng thật không. Nghe thì dễ, làm mới thấm. Nếu bạn muốn xem chuyện dự án gãy thì trông như thế nào, đọc thêm bài [tại sao dự án ERP thất bại](/posts/tai-sao-du-an-erp-that-bai/). *Bài đăng lần đầu trên [quanlamba.wordpress.com](https://quanlamba.wordpress.com/2025/12/11/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/).* --- # Vài kinh nghiệm về chuyện deal lương cho "BA tay ngang" - URL: https://quanlamba.com/posts/vai-kinh-nghiem-ve-chuyen-deal-luong-cho-ba-tay-ngang/ - Ngày đăng: 2025-12-11 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Chuyển ngành BA, Deal lương, Góc nhìn - Mô tả: Deal lương cho BA tay ngang: coi tuyển dụng là trao đổi giá trị, cầm dữ liệu thị trường trong tay, và biết phiên dịch kinh nghiệm cũ sang ngôn ngữ BA. Anh em làm BA mà đi deal lương bằng niềm tin thì chết dở, nhất là anh em tay ngang hay fresher, vốn đã thấy mình ở cửa dưới, vào phòng là chỉ mong người ta nhận cho, ai hỏi bao nhiêu cũng ậm ừ "dạ tuỳ anh chị". Bài này là cách mình nghĩ về chuyện deal lương, mà nghĩ theo đúng kiểu BA, tức là dữ liệu và phân tích. ## tuyển dụng là trao đổi giá trị, không phải xin cho Bản chất của việc tuyển dụng nó sòng phẳng lắm: **trao đổi giá trị**. Công ty có nỗi đau, quy trình lộn xộn, phần mềm lỗi, nghiệp vụ rắc rối, còn bạn, một Business Analyst, là thuốc giải, và lương là cái giá họ trả cho giải pháp bạn mang lại. Khi đổi câu hỏi từ "mình xin bao nhiêu thì được?" sang "giải pháp mình mang lại trị giá bao nhiêu?" thì cuộc đàm phán thành cuộc nói chuyện sòng phẳng giữa hai người lớn. Thế là đỡ run hẳn. ## chuẩn bị vũ khí, mà vũ khí là dữ liệu Bước đầu tiên là market research. Quét các trang tuyển dụng như TopCV, ITviec, các group cộng đồng BA, các báo cáo lương như của Adecco hay Navigos, rồi lập một file Excel ghi lại mặt bằng lương theo cấp bậc (fresher, junior), theo loại công ty (product, outsource), theo khu vực (Hà Nội, TP.HCM). Làm xong là bạn có con số cụ thể trong tay, không còn "hình như", "em nghĩ là…" nữa. Cách mình đọc mặt bằng lương từ tin tuyển dụng thì bạn xem ở bài [lương BA Việt Nam 2026](/posts/luong-ba-viet-nam-2026/). Bước tiếp theo là tự định giá mình bằng ba con số riêng: điểm sàn (walk-away point) là mức tối thiểu đủ trang trải cuộc sống, cái này giữ bí mật; điểm mục tiêu (target point) là mức xứng đáng và khiến bạn vui; còn điểm trong mơ (dream point) thì cao hơn thị trường một chút, để dành khi bạn đang ở thế cửa trên. ## phiên dịch kinh nghiệm cũ sang ngôn ngữ ba Kinh nghiệm cũ không bao giờ vô nghĩa, quan trọng là anh em có biết phiên dịch nó sang ngôn ngữ BA hay không. Dân marketing thì đừng kể chuyện chạy Ads, hãy nói về phân tích hành vi khách hàng, đi tìm pain point, tức là user research. Dân kế toán, tài chính thì đừng bảo chỉ biết nhập liệu, hãy nhấn vào chuyện tối ưu quy trình báo cáo, tự động hoá bằng Excel, tức là process improvement. Còn sale hay chăm sóc khách hàng thì bạn chính là người lắng nghe khách rồi biến feedback thành yêu cầu cải tiến sản phẩm, có khác gì cái cầu nối đâu. Với sinh viên mới ra trường, kinh nghiệm làm việc bằng không cũng chẳng sao, cứ lôi đồ án tốt nghiệp, dự án cá nhân (vẽ wireframe, viết user story), cả vai trò tổ chức sự kiện ra mà kể, để cho thấy bạn đã biết làm việc với stakeholder và có tư duy BA. Nhà tuyển dụng fresher là đang mua tiềm năng mà. ## lúc con số xuất hiện Nguyên tắc vàng là né ra giá trước, vì ai ra giá trước thì người đó mất lợi thế mỏ neo. Khéo một chút kiểu "Dạ, em muốn tìm hiểu thêm về ngân sách của bên mình cho vị trí này…" là quả bóng đã về lại phía HR. Còn nếu bị ép phải nói thì đưa ra khoảng lương (range) đã chuẩn bị, đại loại "Dựa trên tìm hiểu thị trường và giá trị em có thể đóng góp, em kỳ vọng mức lương từ X đến Y". Nếu họ trả thấp hơn kỳ vọng thì đừng vội nhăn mặt. Cảm ơn và ghi nhận trước ("Em rất vui vì offer này…"), sau đó mới trình bày luận điểm bằng data, kiểu "Tuy nhiên theo tìm hiểu của em thì mặt bằng chung…", cộng thêm "Với kinh nghiệm X năm làm nghề cũ, em tin em có thể…", rồi đưa ra counter-offer, một con số ở giữa, hoặc chuyển sang thương lượng phúc lợi khác. Cũng nhớ nhìn vào total package, vì lương cứng thấp mà có thưởng dự án, bảo hiểm xịn, có ngân sách cho học chứng chỉ ECBA chẳng hạn, thì có khi còn lợi hơn vài triệu tiền lương. ## mấy cái bẫy chết người Đừng bao giờ nói dối lương cũ, mất niềm tin là mất hết. Đừng đưa lý do cá nhân kiểu "em cần tiền đóng trọ", "vợ em sắp đẻ", vì nhà tuyển dụng không quan tâm chuyện đó, họ chỉ quan tâm bạn làm được gì cho họ. Đừng nhận offer ngay lập tức dù sướng đến mấy, cứ "xin phép suy nghĩ đến mai" để giữ giá trị và sự cẩn trọng của mình. Và đừng giữ thái độ cửa trên, đàm phán là hợp tác chứ có phải cãi nhau đâu. Nghĩ kỹ thì deal lương cũng giống một dự án BA, thu thập yêu cầu, phân tích dữ liệu, đưa ra giải pháp hai bên cùng thắng, và cái tự tin trong phòng phỏng vấn đến từ sự chuẩn bị chứ không phải từ chém gió. Cầm file Excel phân tích lương trong tay thì cuộc nói chuyện sẽ khác hẳn. --- Đọc thêm: [Business Analyst là gì?](/posts/the-tum-lai-business-analyst-la-gi-nhuy/) --- # Bạn là "phi công" hay là "thợ máy"? - URL: https://quanlamba.com/posts/ban-la-phi-cong-hay-la-tho-may/ - Ngày đăng: 2025-12-02 - Cập nhật: 2026-11-05 - Thẻ: Chuyển đổi số, Leadership, CEO, Dashboard, MES, ERP - Mô tả: Phi công nhìn dashboard để bay, còn nhiều chủ nhà máy vẫn phải xuống xưởng làm thợ máy. Chuyển đổi số là dựng cái buồng lái đó, và BA ngồi ở đâu. ![Tác giả check-in trước máy bay Vietnam Airlines — bạn là phi công hay thợ máy?](https://quanlamba.wordpress.com/wp-content/uploads/2025/12/paper-3.png?w=1024) Chao-xìn anh iem, nay tranh thủ lúc boarding làm kiểu ảnh check-in, ngồi ngắm cái máy bay một lúc thì bệnh nghề nghiệp lại tái phát. Hehe. Anh em thử tưởng tượng nhé, ông phi công ngồi trong buồng lái kín bưng, ổng đâu có nhìn thấy cánh quạt đang quay thế nào, cũng đâu thò đầu ra ngoài xem bánh xe đã thu lên chưa, thứ duy nhất ổng nhìn là cái màn hình điều khiển, cái dashboard, nơi tốc độ gió, độ cao, nhiên liệu, nhiệt độ động cơ gom hết về mấy con số xanh đỏ trước mặt. Thế là đủ để bay. ![Bảng đồng hồ buồng lái máy bay và hình vẽ người ngồi suy nghĩ trước dashboard](https://quanlamba.wordpress.com/wp-content/uploads/2025/12/image-1.png?w=1024) Theo mình thì nhiều anh chủ nhà máy đang khổ quá, mang tiếng Tổng Giám đốc, tức là cơ trưởng, mà cứ phải chạy xuống xưởng làm thợ máy để hỏi "Hàng làm đến đâu rồi?", "Máy này sao lại hỏng?". Tại sao vậy? Tại không có dữ liệu, hoặc có thì là dữ liệu "chết" từ tuần trước, mà dưới xưởng còn là cái hộp đen mù mịt thì ai dám ngồi phòng máy lạnh điều hành. Chuyển đổi số trong sản xuất, nói cho vuông, là quá trình dựng cái dashboard buồng lái đó cho doanh nghiệp, để người lãnh đạo được làm đúng việc của phi công, nhìn dữ liệu, ra quyết định, đưa con tàu đi đúng hướng, chứ không phải người chạy đi vặn từng con ốc. ## mấy dấu hiệu anh đang ngồi nhầm ghế Theo mình không cần vào nhà máy lâu, ngồi họp một lúc là đoán được anh đang làm cơ trưởng hay đang làm thợ máy. Dấu hiệu đầu tiên là con số nào cũng phải gọi điện hỏi. Muốn biết hôm nay xuất được bao nhiêu thùng thì nhấc máy gọi quản đốc, muốn biết tồn kho nguyên liệu thì gọi thêm một cuộc nữa, ý là số liệu không nằm trong hệ thống, nó nằm trong điện thoại của anh. Dấu hiệu thứ hai là ngày làm việc mở đầu bằng câu hỏi về hiện trường chứ không phải về kế hoạch, "Hàng làm đến đâu rồi?" thay vì "Tuần này mình có đang đúng hẹn với khách không?", một câu là chữa cháy, câu kia mới là điều hành. Dấu hiệu thứ ba là ai cũng hỏi anh, không ai hỏi hệ thống. Khi cả xưởng coi anh là cái loa phát thanh của nhà máy thì anh hết thời gian nghĩ chuyện sáu tháng tới, mà chuyện sáu tháng tới mới là việc của người cầm lái. Còn một dấu hiệu nữa khó thấy hơn: anh vẫn ra quyết định được, nhưng quyết định nào cũng kèm câu "để tôi xuống xem đã". Nghe thì có vẻ cẩn thận, thật ra là đang thiếu niềm tin vào con số. ## cái buồng lái của nhà máy gồm những gì Không cần 40 chỉ số, cần vài thứ đúng, và đúng nghĩa là phải sống: giao hàng thì đơn nào trễ, trễ mấy ngày, trễ vì thiếu vật tư hay vì máy hỏng; sản xuất thì đang có bao nhiêu lệnh mở, cái nào tới hạn, cái nào đang tắc; thiết bị thì tuần này dừng máy bao nhiêu giờ, vì lý do gì; tồn kho thì cái gì sắp hết, cái gì đang chôn vốn; chất lượng thì tỷ lệ hàng phải làm lại đang tăng hay giảm. Nhưng quan trọng hơn cả danh sách là điều kiện này: **một KPI, một định nghĩa, một nguồn dữ liệu, một người chịu trách nhiệm**. Nghe đơn giản mà đây là chỗ chết người. Cùng gọi là "đúng hạn giao hàng" nhưng kinh doanh tính theo ngày khách nhận, sản xuất tính theo ngày xuất kho, kế toán tính theo ngày hoá đơn, thế là ba con số lệch nhau, ba phòng cãi nhau, ông chủ ngồi giữa không biết tin ai, và cái dashboard lúc đó chỉ làm cuộc cãi nhau có minh chứng hơn thôi. ## ba ngồi ở đâu trong chuyện này Nếu anh nghĩ BA là người đi mua phần mềm làm dashboard thì thôi, khỏi cần BA. Việc thật của BA trong một dự án dashboard, theo mình, gọn lại có ba cái. Cái đầu tiên là chốt định nghĩa với người ra quyết định, không phải với IT, vì người nhìn con số mỗi sáng mới là người có quyền nói "đúng hạn nghĩa là gì". Cái thứ hai là truy nguồn dữ liệu tới tận cùng, con số này sinh ra ở đâu, ai nhập, lúc nào, quên nhập thì chuyện gì xảy ra, chỗ này mới là nơi requirement sống hoặc chết. Cái thứ ba là viết rõ "số này sai thì sao", sai một ngày thì báo động, sai một tháng thì phải chặn, còn không ai định nghĩa thì hệ thống mặc định im lặng, mà im lặng trong sản xuất nghĩa là anh chỉ biết khi khách đã gọi. Làm được ba việc đó thì dashboard mới là bảng đồng hồ, không thì nó chỉ là cái slide đẹp, mở họp cho có. ## nhưng phi công vẫn phải đi walk-around Nói vậy không có nghĩa lãnh đạo cứ ngồi phòng lạnh. Trước mỗi chuyến bay, phi công thật vẫn phải đi một vòng quanh máy bay, nhìn bằng mắt, sờ bằng tay, cái đó gọi là walk-around và không đồng hồ nào thay được. Xuống xưởng cũng vậy, khác nhau ở chỗ anh xuống để **kiểm tra giả định** hay xuống để **làm hộ việc**, một bên là phi công đi walk-around, một bên là cơ trưởng chui xuống khoang máy siết ốc. Mà cái thứ hai rất dễ thành thói quen, vì nó cho cảm giác mình đang làm việc, trong khi thứ đang bị bỏ lỡ lại là quyết định. Bay lên nào! Tuần rồi, bao nhiêu quyết định của bạn được ra bằng dữ liệu, và bao nhiêu được ra bằng cảm giác? --- Đọc thêm: [BA trong nhà máy: 6 món võ](/posts/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/) và [ERP không chạy trên phần mềm, mà trên dữ liệu](/posts/erp-khong-chay-tren-phan-mem-ma-chay-tren-du-lieu/). --- # Chuyện về "cái nết" làm nghề - URL: https://quanlamba.com/posts/chuyen-ve-cai-net-lam-nghe/ - Ngày đăng: 2025-12-01 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Chuyển ngành BA, Tâm sự, Quân làm BA, Thái độ làm việc - Mô tả: Cái nết làm nghề BA, tức behavioral characteristics: đạo đức, trách nhiệm cá nhân và sự tin cậy, thứ quan trọng hơn hard skills mà ít ai hỏi. Dạo này hay có mấy bạn BA mới ra trường, đang thực tập, nhắn hỏi mình đủ thứ, kiểu "Anh ơi học tool nào cho ngầu?", "Anh ơi vẽ BPMN thế nào cho chuẩn?", rồi cả "Học Python hay PHP thì lương cao hơn?", hỏi nhiều đến mức mình bắt đầu thấy hơi lo. Lo thật. Không phải mấy câu đó sai, mà vì kỹ năng cứng nó giống thanh kiếm sắc, muốn dùng cho đúng thì người cầm kiếm phải có cái nền về thái độ và đạo đức nghề nghiệp trước đã. Mình gọi cái nền đó là "cái nết làm nghề", BABOK gọi nó là Behavioral Characteristics. Thiết nghĩ, trước khi thành chuyên gia thì mình phải thành một con người tử tế cái đã. Trong cái nết đó, có ba thứ mình thấy quan trọng nhất. ## đạo đức là cái ranh giới mong manh BA nắm trong tay những thứ sống còn của khách hàng, dữ liệu, quy trình, cả bí mật kinh doanh, nên rất dễ bị lung lay trước những câu kiểu "Em ơi, hay là mình 'xào' lại cái số liệu này tí cho báo cáo nó đẹp?", hoặc khi phát hiện ra lỗ hổng quy trình thì thiên vị bên này, hại bên kia. Với mình, đạo đức ở đây không phải làm từ thiện, mà là sự công bằng (fairness): giải pháp mình đề xuất phải tốt cho tổng thể doanh nghiệp, chứ không phải vì mình thích ông này hay ghét bà kia. Giữ được thế thì tối mới ngủ ngon. ## trách nhiệm cá nhân, đừng đổ tại "số" Thói đổ thừa thì phổ biến lắm, dự án chậm thì "tại ông dev code chậm", requirement sai thì "tại khách đổi ý liên tục", họp muộn thì "tại trời mưa tắc đường", nghe quen không anh em. Personal accountability theo mình là tính làm chủ (ownership): nhận việc gì thì việc đó là đứa con của mình, thành hay bại cũng do mình. Khách thay đổi thì mình đi clear lại scope, dev chậm thì mình hỗ trợ hoặc báo sớm, và không hứa suông, việc nhận mà chưa xong thì phải thấy áy náy, thấy nhục, chứ đừng coi là chuyện bình thường. Uy tín của một thằng đàn ông, và của một người làm nghề, nó được xây bằng những hành động nhỏ nhặt thế thôi. ## sự tin cậy là tài sản lớn nhất của ba Khách hàng chịu mở lòng kể nỗi đau của họ không phải vì BA giỏi kỹ thuật, mà vì họ tin mình. Muốn được tin thì phải trung thực, giải pháp có rủi ro thì nói thẳng, mình sai thì nhận rồi sửa ngay, dự án có dấu hiệu "toang" thì cảnh báo sớm, chứ đừng lươn lẹo giấu lỗi như mèo giấu… Sự tin cậy nó giống cái ly thuỷ tinh, xây thì lâu, mà đập vỡ chỉ cần một lần lươn lẹo. Khi stakeholder đã tin thì BA thành điểm tựa, nói gì họ cũng nghe, còn mất niềm tin rồi thì quy trình vẽ đẹp đến mấy cũng bị vứt sọt rác. Nếu bạn đang ở cái đoạn stakeholder quay lưng rồi thì xem thêm [cách làm khi stakeholder không hợp tác](/posts/stakeholder-khong-hop-tac-lam-gi-khi-khong-ai-muon-noi-chuyen/). ## chậm một chút cũng được Nghề BA, mà nghề nào cũng vậy, suy cho cùng là giải quyết vấn đề cho con người, nên với mình cái nết quan trọng hơn bằng cấp. Kỹ năng thiếu thì học bổ sung được, còn đạo đức lệch, trách nhiệm thiếu, niềm tin mất thì chẳng ai cứu nổi. Chậm một chút cũng được, nhưng đi cho nó chắc. Bài sau mình sẽ "chém gió" về mấy kỹ năng hàn lâm hơn. --- Đọc thêm: [Business Analyst là gì?](/posts/the-tum-lai-business-analyst-la-gi-nhuy/) --- # Thế túm lại Business Analyst là gì nhuỷ? - URL: https://quanlamba.com/posts/the-tum-lai-business-analyst-la-gi-nhuy/ - Ngày đăng: 2025-12-01 - Cập nhật: 2026-11-05 - Thẻ: Business Analyst, Tư duy làm nghề, Quân làm BA, Góc nhìn - Mô tả: Business Analyst là gì? Không chỉ là cái cầu nối dịch tiếng khách sang tiếng dev. Nghề này là tư duy giải quyết vấn đề, kể cả lúc xe hết xăng. ![ba là gì](https://quanlamba.wordpress.com/wp-content/uploads/2025/12/paper.png?w=1024) Hôm nay ngồi cafe, nghe mấy anh em kháo nhau: "Làm BA (Business Analyst) sướng nhỉ, chỉ việc làm cái 'cầu nối', đi dịch tiếng người (khách hàng) sang tiếng máy (dev) là xong." Nghe xong mình chỉ biết cười trừ ._. Mà thú thật, hồi mới vào nghề mình cũng nghĩ y chang thế, tưởng đâu chỉ cần biết chút tiếng Anh, biết chút IT, đứng giữa ba hoa chích choè một tí là có lương, đến lúc làm thật mới thấy đời nó không như mơ. Không như mơ tí nào. ## ba không phải chức danh, ba là cái cách nghĩ Nhiều người cứ thần thánh hoá, nghĩ BA (Bít nit ana lít) là phải biết vẽ hươu vẽ vượn, phải rành SQL, rành API này nọ, nhưng theo mình bản chất của nghề nó đơn giản, và cũng chua chát, hơn nhiều: nhìn thấy một đống quy trình đang lủng cà lủng củng của doanh nghiệp rồi tìm cách làm cho nó trơn tru hơn. Thế thôi. Cái mạch của một ông BA chạy "kiểu lày": nhìn ra nỗi đau (problem), xác định mình muốn đi tới đâu (objective), tìm cách đi (solution), rồi đưa cách đó vào đời thật (transition). Mà nếu cái đích là giải quyết vấn đề thì solution đâu nhất thiết phải là phần mềm xịn sò, đôi khi chỉ cần đổi một thói quen, hoặc dùng một file Excel cùi bắp, miễn nó hiệu quả là được. Công cụ là chuyện sau, cái đầu biết giải quyết vấn đề mới là chuyện trước. ## ba có ở mọi ngóc ngách, kể cả lúc hết xăng Nói lý thuyết thì mông lung, nên lấy cái ví dụ đời thường này cho cả nhà dễ hình dung. Đang đi làm về thì xe hết xăng, lúc này business objective của anh em là gì ạ? Là vác được cái xác về nhà ăn cơm với vợ, đúng không. Thế là cái đầu "ba" bắt đầu nảy số: dắt bộ đi tìm cây xăng, gọi thằng bạn mang xăng tới, hay gửi xe lại rồi bắt xe về trước. Phương án nào cũng có cái giá của nó, và anh em phải cân cả đám stakeholders xung quanh, vợ đang chờ cơm, con đang khóc, thằng bạn không biết có rảnh không, chọn sao cho các bên vui vẻ nhất. Đấy, làm BA đấy. ![Ảnh động người đàn ông cười bụm miệng — dở khóc dở cười khi cân nhắc stakeholders](https://media0.giphy.com/media/v1.Y2lkPTc5MGI3NjExZGxjb3J6ZWhrdzJubm5zMHNuaTdjMWdzd203czkwdzU4NWk1ZXRucCZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/GpyS1lJXJYupG/giphy.gif) ## và túm lại thì ![An infographic explaining the role of a Business Analyst (BA) focusing on the distinction between myth and reality, the core values of the profession, and a real-life case study involving problem-solving when running out of gas.](https://quanlamba.wordpress.com/wp-content/uploads/2025/12/frame-2-1.png?w=1024) Biến cái chưa tốt thành cái tốt, biến cái tốt rồi thành cái tốt hơn, với mình đó mới là cái lẽ sống của nghề này, chứ làm "cầu nối" không thôi thì cũng lắm nhỉ ^^ Anh em làm BA thấy mình nói có đúng không? --- Đọc thêm: [BA mới vào nghề: 5 cú sốc không ai nói trước](/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/) và [Chuyện về "cái nết" làm nghề](/posts/chuyen-ve-cai-net-lam-nghe/).