[{"content":"Mình nhớ tháng đầu tiên làm BA. Ngồi phòng họp với 8 người, ai cũng nói, ai cũng có ý kiến. Mình ghi chép hết — xong về bàn không biết cái nào mới là requirement thật.\nKinh khủng hơn: mình ngồi đó, gật đầu lia lịa, tỏ vẻ \u0026ldquo;OK em hiểu\u0026rdquo; — mà thực ra chẳng hiểu gì. Cảm giác như đi thi mà đề toàn tiếng Tây Ban Nha.\nKhông trường lớp nào dạy mình mấy cái dưới đây. Toàn tự ngã, tự vỡ đầu ra mới thấm.\n1. Stakeholder không biết mình muốn gì # Hồi mới ra trường, mình tưởng BA là nghề đẹp nhất thế gian: stakeholder nói requirement, mình ghi vào, đem về cho dev làm. Như đi chợ: người ta kêu gà, mình mua gà.\nSai be.\nPhần lớn stakeholder không biết họ muốn gì. Họ chỉ biết họ đau, không biết thuốc nào trị. Họ nói \u0026ldquo;em làm cái màn hình giống Excel cũ nhé\u0026rdquo; — nhưng Excel cũ họ cũng ghét, (Mình đã viết kỹ hơn về chuyện này trong bài 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả.)\nRồi mình mất 3 tuần làm đúng như họ nói. Xong họ bảo: \u0026ldquo;không phải ý anh.\u0026rdquo;\nCú sốc thứ nhất: requirement không nằm sẵn trong đầu ai cả. Nó là thứ mình phải moi ra, phải đặt câu hỏi ngu, phải propose phương án, phải cho họ thấy prototype mới biết họ gật hay lắc.\n2. Requirement thay đổi mỗi ngày # Tuần 1: \u0026ldquo;Làm cái này trước, gấp lắm.\u0026rdquo; Tuần 2: \u0026ldquo;Thôi bỏ, cái kia quan trọng hơn.\u0026rdquo; Tuần 3: \u0026ldquo;Hai cái đều làm, thêm cái này nữa.\u0026rdquo; Tuần 4: \u0026ldquo;Sao chậm thế?\u0026rdquo;\nMình từng thấy BA khóc vì cái vòng luẩn quẩn này. Mình cũng từng muốn khóc.\nHóa ra scope creep không phải exception — nó là default. Quan trọng không phải ngăn nó (không ngăn được), mà là có trace được mỗi thay đổi, có chữ ký cho mỗi lần \u0026ldquo;thêm cái này nữa.\u0026rdquo;\n3. Dev không tin BA # Có lần mình ngồi nghe một dev nói thẳng: \u0026ldquo;Em viết spec xong rồi, anh dev tự hiểu mà làm, khỏi giải thích.\u0026rdquo;\nCảm giác lúc đó như mình là cái bánh kẹp. Stakeholder đổ requirement lên đầu. Dev đổ code lên đầu. BA ở giữa hứng hết.\nDev muốn spec chi tiết từng dấu phẩy. Stakeholder muốn \u0026ldquo;tự động xử lý hết đi, đừng hỏi tôi.\u0026rdquo;\nCú sốc thứ ba: giao tiếp với dev là một kỹ năng riêng, không phải cứ viết dài là xong. Phải nói chuyện bằng ngôn ngữ của họ — data model, logic flow, edge case. Và quan trọng nhất: phải chứng minh được mình hiểu business để họ tôn trọng.\n4. \u0026ldquo;Mình làm gì thế nhỉ?\u0026rdquo; — cảm giác vô dụng 3 tháng đầu # Tháng một: mình quan sát. Tháng hai: mình viết meeting minutes. Tháng ba: mình hỏi \u0026ldquo;bao giờ em được làm việc thật?\u0026rdquo;.\nNhìn xung quanh: stakeholder vẫn nói chuyện với nhau, dev vẫn code, dự án vẫn chạy. Mình như cái bóng. Có mình cũng được, không mình cũng chẳng sao.\nPhải đến một lần mình phát hiện requirement conflict giữa phòng sale và phòng kho — cùng một quy trình, hai đầu óc khác nhau — mình mới hiểu: cái giá trị nhất của BA không phải viết spec. Mà là nối những mảnh ghép mà mỗi phòng ban không thấy, vì họ chỉ nhìn từ góc của họ.\nCú sốc thứ tư: cảm giác vô dụng là bình thường. Kéo dài 3-6 tháng. Sau đó, nếu bạn chịu khó đi xuống xưởng, hỏi mấy câu \u0026ldquo;ngu\u0026rdquo;, bạn sẽ là người hiểu quy trình nhất — hơn cả stakeholder, hơn cả dev.\n5. Không có template nào áp dụng được nguyên xi # Học BA ở trường: có khung, có mẫu, có đáp án. Làm BA thực tế: mỗi dự án mỗi khác, mỗi stakeholder mỗi tính, template chép mạng về không dùng được.\nMình từng mất 2 tuần làm một cái BRD 30 trang. Stakeholder lật 2 trang đầu: \u0026ldquo;Dài quá, tôi không hiểu.\u0026rdquo;\nLần sau mình chỉ làm 2 trang A4, vẽ 4 cái hộp với mũi tên. Stakeholder gật: \u0026ldquo;Thế mới dễ hiểu.\u0026rdquo;\nCú sốc thứ năm: không có công thức chung. Cái hiệu quả ở dự án này có thể fail thảm ở dự án khác. BA giỏi không phải người thuộc nhiều template — mà là người đọc được tình huống và biết nên xài template nào, hay nên vứt template đi.\nNăm cái trên không phải để bạn sợ. Ai mới vào cũng va phải. Mình cũng từng muốn bỏ nghề vì mấy thứ này.\nGiờ nghĩ lại, chính mấy cú sốc đó mới dạy mình làm nghề.\nHỏi thật: bạn đang gặp cú sốc nào nhất? Hay có cú nào mình chưa liệt kê? Comment hoặc DM mình nhé.\n#DehaDigitalSolutions #BusinessAnalyst #BAMoiVaoNghe\n📖 Xem thêm:\nXem thêm: Business Analyst là gì? ","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/posts/ba-moi-vao-nghe-5-cu-soc-khong-ai-noi-truoc/","section":"Posts","summary":"Mình nhớ tháng đầu tiên làm BA. Ngồi phòng họp với 8 người, ai cũng nói, ai cũng có ý kiến. Mình ghi chép hết — xong về bàn không biết cái nào mới là requirement thật.\nKinh khủng hơn: mình ngồi đó, gật đầu lia lịa, tỏ vẻ “OK em hiểu” — mà thực ra chẳng hiểu gì. Cảm giác như đi thi mà đề toàn tiếng Tây Ban Nha.\n","title":"BA mới vào nghề: 5 cú sốc không ai nói trước","type":"posts"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/tags/ba-moi-vao-nghe/","section":"Tags","summary":"","title":"Ba-Moi-Vao-Nghe","type":"tags"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/tags/business-analyst/","section":"Tags","summary":"","title":"Business-Analyst","type":"tags"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/tags/ky-nang-mem/","section":"Tags","summary":"","title":"Ky-Nang-Mem","type":"tags"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/","section":"Quân làm BA Blog — ERP, IFS Cloud \u0026 Business Analysis","summary":"","title":"Quân làm BA Blog — ERP, IFS Cloud \u0026 Business Analysis","type":"page"},{"content":"","date":"21 tháng 6, 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"Mình không nhớ nổi bao nhiêu lần bước vào site khách hàng, module IFS Cloud Procurement đã go-live rồi — mà team mua hàng vẫn đang ngập trong Excel và việc tay. Đây không phải lỗi đơn lẻ — nó nằm trong 5 lý do khiến dự án ERP thất bại mà mình từng thấy lặp đi lặp lại. Không phải do phần mềm. Gần như không bao giờ do phần mềm. Là do cách người ta set-up nó từ 6 tháng trước.\nDưới đây là 3 cái bẫy mình thấy lặp đi lặp lại.\n🏭 1. Approval route một cỡ cho tất cả\nLuồng duyệt mặc định của IFS Cloud là phẳng: mọi requisition chạy cùng một chain, bất kể giá trị, chủng loại, phòng ban. Nhiều team để vậy, nghĩ \u0026ldquo;sau refine\u0026rdquo;.\nKết quả: cái request mua giấy 50 nghìn và cái đơn hàng thiết bị 50 nghìn đô xếp chung một hàng chờ. Ông approver nghỉ phép 2 ngày — dây chuyền đứng.\nCách làm: thiết lập approval route theo điều kiện ngay từ đầu. 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: auto-approve dưới 10 triệu, duyệt phòng ban cho 10-100 triệu, multi-tier trên 100 triệu. Cắt 40-60% cycle time là bình thường.\n📦 2. Bỏ qua lead time ở cấp Part-Supplier\nIFS Cloud lưu lead time ở link Part Supplier, không phải ở header supplier. Mình thấy nhiều team chỉ nhập lead time chung chung kiểu \u0026ldquo;5 ngày\u0026rdquo; ở master supplier rồi thôi.\nVấn đề: cùng một supplier, cái bracket đặc chủng mất 15 ngày, con bolt tiêu chuẩn 2 ngày. MRP chạy ra đọc \u0026ldquo;5 ngày\u0026rdquo; cho cả hai — bracket về trễ, bolt về sớm nằm kho tốn tiền giữ.\nCách làm: lúc migrate dữ liệu, bỏ thời gian điền PartSupplierLeadTime chính xác từng part. Một cái spreadsheet 3 cột: Supplier ID, Part ID, Lead Time (ngày) — upload qua Data Import tool của IFS Cloud. Làm một buổi chiều, tiết kiệm hàng tuần expediting sau này.\n📋 3. Không dùng Purchase Agreement cho hàng mua định kỳ\nMột trong những tính năng bị underuse nhất trong IFS Cloud Procurement: Purchase Agreement với agreement lines. 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 — văn phòng phẩm, MRO consumables, bao bì — cùng supplier, cùng giá.\nChuyện gì xảy ra: mỗi tháng, buyer copy PO cũ, đổi ngày, sửa số lượng. Mỗi tháng cùng một thao tác, cùng rủi ro nhập sai, cùng 1 tiếng vứt đi.\nCách tốt hơn: 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ự gen PO từ agreement khi stock chạm reorder point.\nSetup mất 15 phút cho mỗi agreement. Tiết kiệm khoảng 1 tiếng/tháng cho mỗi buyer. Năm buyer — 5 tiếng mỗi tháng, từ một lần đổi cấu hình.\nBa 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.\nLần tới set-up IFS Cloud Procurement, tự hỏi mình một câu: Cái này chạy được vào ngày 90 không, hay chỉ ngày 1?\nBê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? 👇\n#DehaDigitalSolutions #IFSCloud #Procurement\n","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/posts/ifs-cloud-procurement-pitfalls/","section":"Posts","summary":"Mình không nhớ nổi bao nhiêu lần bước vào site khách hàng, module IFS Cloud Procurement đã go-live rồi — mà team mua hàng vẫn đang ngập trong Excel và việc tay. Đây không phải lỗi đơn lẻ — nó nằm trong 5 lý do khiến dự án ERP thất bại mà mình từng thấy lặp đi lặp lại. Không phải do phần mềm. Gần như không bao giờ do phần mềm. Là do cách người ta set-up nó từ 6 tháng trước.\n","title":"3 cái bẫy cấu hình IFS Cloud Procurement khiến team mua hàng ngập trong việc tay","type":"posts"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/ba/","section":"Tags","summary":"","title":"Ba","type":"tags"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/b%C3%A0i-h%E1%BB%8Dc/","section":"Tags","summary":"","title":"Bài Học","type":"tags"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/c%E1%BA%A5u-h%C3%ACnh/","section":"Tags","summary":"","title":"Cấu Hình","type":"tags"},{"content":" Tôi là ai? # Tôi là Đức Quân — Business Analyst chuyên về triển khai ERP và Quản lý Chuỗi Cung ứng. Tôi làm việc với IFS Cloud ở các module procurement, inventory, manufacturing, đồng thời tự phát triển các giải pháp ERP riêng.\nBlog này viết về gì? # Triển khai ERP — những bài học thực tế từ chiến hào IFS Cloud — deep-dive vào module và cấu hình Supply Chain — procurement, logistics, tối ưu tồn kho Business Analysis — BABOK trong thực tế, không lý thuyết suông Góc cá nhân — đời consultant, suy nghĩ vẩn vơ, những ngày bình thường Tại sao tôi viết? # Sau nhiều năm consulting, tôi thấy cùng một lỗi lặp đi lặp lại ở các công ty. Blog này là cách tôi chia sẻ những gì hiệu quả, những gì không, và cách xây dựng hệ thống thực sự tạo ra giá trị.\nKhông có lịch cố định. Khi nào có gì đáng viết thì viết.\n","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/posts/welcome/","section":"Posts","summary":"Tôi là ai? # Tôi là Đức Quân — Business Analyst chuyên về triển khai ERP và Quản lý Chuỗi Cung ứng. Tôi làm việc với IFS Cloud ở các module procurement, inventory, manufacturing, đồng thời tự phát triển các giải pháp ERP riêng.\nBlog này viết về gì? # Triển khai ERP — những bài học thực tế từ chiến hào IFS Cloud — deep-dive vào module và cấu hình Supply Chain — procurement, logistics, tối ưu tồn kho Business Analysis — BABOK trong thực tế, không lý thuyết suông Góc cá nhân — đời consultant, suy nghĩ vẩn vơ, những ngày bình thường Tại sao tôi viết? # Sau nhiều năm consulting, tôi thấy cùng một lỗi lặp đi lặp lại ở các công ty. Blog này là cách tôi chia sẻ những gì hiệu quả, những gì không, và cách xây dựng hệ thống thực sự tạo ra giá trị.\n","title":"Chào mừng đến Quân làm BA Blog","type":"posts"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/erp/","section":"Tags","summary":"","title":"ERP","type":"tags"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/ifs-cloud/","section":"Tags","summary":"","title":"Ifs-Cloud","type":"tags"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/procurement/","section":"Tags","summary":"","title":"Procurement","type":"tags"},{"content":"Mình từng ngồi trong một cuộc họp \u0026ldquo;rút kinh nghiệm\u0026rdquo; dự án ERP kéo dài 4 tiếng. Phòng họp kín, điều hoà 16 độ mà mặt ai cũng đỏ bừng. Dự án ngốn 2 năm, 15 tỷ — go-live xong thì team mua hàng vẫn dùng Excel để tracking đơn hàng \u0026ldquo;cho chắc\u0026rdquo;.\nKhông phải lần đầu mình thấy cảnh này. Dưới đây là 5 lý do mình thấy lặp đi lặp lại. (Một ví dụ cụ thể: 3 cái bẫy cấu hình IFS Cloud Procurement cũng xuất phát từ những lỗi tương tự.)\n🏭 1. Bắt đầu từ phần mềm, không phải từ vấn đề # Nghe quen không: sếp đi hội thảo về, ký hợp đồng với vendor ERP xong mới gọi BA vào. \u0026ldquo;Giờ em đi khảo sát requirement đi.\u0026rdquo;\nVấn đề là: requirement không phải thứ mình \u0026ldquo;đi khảo sát\u0026rdquo; sau khi đã chọn xong phần mềm. Requirement là thứ quyết định chọn phần mềm nào, không phải ngược lại. Mình thấy nhiều dự án còng lưng custom một module mà phần mềm không được thiết kế để làm việc đó, đơn giản vì lúc chọn không ai hỏi: \u0026ldquo;Cái này có thực sự giải quyết vấn đề của mình không?\u0026rdquo;\n📋 2. \u0026ldquo;Cứ làm giống quy trình cũ đi em\u0026rdquo; # Câu này mình nghe ít nhất 10 lần mỗi dự án. Ông trưởng phòng nói vậy vì ổng sợ thay đổi. Bà kế toán nói vậy vì bả không muốn học lại từ đầu.\nERP không phải là phiên bản số hoá của quy trình giấy. Nó là cơ hội để chuẩn hoá, cắt bỏ những bước thừa, tự động hoá những thứ đáng lẽ không cần người làm. Nhưng khi BA chiều stakeholder quá, mình kết thúc với 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. Phí mất 2 năm và 15 tỷ cho một cái \u0026ldquo;Excel màu mè hơn\u0026rdquo;.\n👤 3. Sponsor không có mặt # Giám đốc nhà máy là sponsor dự án. Ổng cũng là người bận nhất công ty. Mỗi lần họp steering committee, ổng gửi trợ lý đi họp thay. Mỗi lần cần quyết định lớn (đổi quy trình, thêm budget), \u0026ldquo;để anh hỏi sếp đã\u0026rdquo;.\nKhi sponsor vắng mặt, mọi quyết định đều bị trì hoãn. Dự án vẫn chạy — nhưng chạy mà không có người cầm lái. Đến lúc go-live, ông giám đốc mới tá hoả: \u0026ldquo;Sao cái này không giống tôi tưởng tượng?\u0026rdquo;\n🔄 4. Test bằng dữ liệu giả # Mình từng thấy một dự án test UAT bằng 20 dòng dữ liệu mẫu. Chạy ngon lành. Go-live xong, migrate 50.000 dòng dữ liệu thật vào — hệ thống sập vì data không sạch, trùng mã, sai định dạng, thiếu trường bắt buộc.\nDữ liệu thật bẩn hơn mình tưởng rất nhiều. Mã hàng nào cũng có ít nhất 3 phiên bản: một trong ERP cũ, một trong file Excel của thủ kho, một trong sổ tay của quản đốc. Không dành ít nhất 2 tuần để làm sạch data trước khi test UAT là tự bắn vào chân.\n📉 5. Không đo được thành công # \u0026ldquo;Hết dự án là xong\u0026rdquo; — câu này sai. Hết go-live mới là bắt đầu. Nhưng làm sao biết dự án thành công nếu không có metrics từ đầu?\nMình hay hỏi khách hàng trước dự án: \u0026ldquo;6 tháng sau go-live, anh muốn thấy điều gì khác?\u0026rdquo; Câu trả lời thường là im lặng. Không ai nghĩ đến chuyện đó. Rồi 6 tháng sau, họ nói \u0026ldquo;ERP chẳng cải thiện được gì\u0026rdquo; — trong khi chưa từng định nghĩa \u0026ldquo;cải thiện\u0026rdquo; là cái gì.\nNăm cái trên không phải lỗi của phần mềm. Là lỗi của cách mình làm dự án.\n5 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 \u0026ldquo;Excel màu mè\u0026rdquo; Chuẩn hoá + cắt bỏ trước khi số hoá 3 Sponsor vắng mặt Trì hoãn, sai hướng Sponsor phải có mặt ở steering committee 4 Test bằng dữ liệu giả Sập hệ thống khi go-live Dành 2 tuần làm sạch data thật, test UAT bằng data 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 6 tháng sau go-live Hỏi thật: dự án ERP của bạn, cái nào trong 5 cái trên đang âm thầm giết nó? 👇\n#DehaDigitalSolutions #ERP #ChuyenDoiSo\n","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/posts/tai-sao-du-an-erp-that-bai/","section":"Posts","summary":"Mình từng ngồi trong một cuộc họp “rút kinh nghiệm” dự án ERP kéo dài 4 tiếng. Phòng họp kín, điều hoà 16 độ mà mặt ai cũng đỏ bừng. Dự án ngốn 2 năm, 15 tỷ — go-live xong thì team mua hàng vẫn dùng Excel để tracking đơn hàng “cho chắc”.\nKhông phải lần đầu mình thấy cảnh này. Dưới đây là 5 lý do mình thấy lặp đi lặp lại. (Một ví dụ cụ thể: 3 cái bẫy cấu hình IFS Cloud Procurement cũng xuất phát từ những lỗi tương tự.)\n","title":"Tại sao dự án ERP thất bại — 5 lý do từ chiến hào","type":"posts"},{"content":"","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/tags/th%E1%BA%A5t-b%E1%BA%A1i/","section":"Tags","summary":"","title":"Thất Bại","type":"tags"},{"content":" Đức Quân — ERP/SCM Consultant # Business Analyst với kinh nghiệm triển khai IFS Cloud trong các mảng procurement, inventory, manufacturing. Tôi giúp doanh nghiệp thu hẹp khoảng cách giữa yêu cầu nghiệp vụ và khả năng của ERP.\nTôi làm gì:\nTư vấn triển khai IFS Cloud (Procurement, SCM, Manufacturing) Phát triển module ERP tuỳ chỉnh Phân tích và tối ưu quy trình nghiệp vụ Requirements engineering theo BABOK Chứng chỉ:\nIFS Certified Practitioner — Procurement (IFS Cloud) IFS Certified Practitioner — Sustainability (IFS Cloud) Professional Scrum Master (PSM I \u0026amp; II) Kết nối:\nX (Twitter): @quannkiu LinkedIn: quandd Facebook: kiu98 Sống ở Hà Nội, Việt Nam 🇻🇳 ","date":"19 tháng 6, 2026","externalUrl":null,"permalink":"/about/","section":"Quân làm BA Blog — ERP, IFS Cloud \u0026 Business Analysis","summary":"Đức Quân — ERP/SCM Consultant # Business Analyst với kinh nghiệm triển khai IFS Cloud trong các mảng procurement, inventory, manufacturing. Tôi giúp doanh nghiệp thu hẹp khoảng cách giữa yêu cầu nghiệp vụ và khả năng của ERP.\nTôi làm gì:\nTư vấn triển khai IFS Cloud (Procurement, SCM, Manufacturing) Phát triển module ERP tuỳ chỉnh Phân tích và tối ưu quy trình nghiệp vụ Requirements engineering theo BABOK Chứng chỉ:\n","title":"Về tôi","type":"page"},{"content":" 3 NGUYÊN TẮC \u0026ldquo;SỐNG CÒN\u0026rdquo; ĐỂ LẤY YÊU CẦU HIỆU QUẢ # Nguồn: Quân làm BA | Ngày: 15/12/2025\nThể loại: Nghề BA | Tags: #BusinessAnalyst #KinhNghiemThucChien #LayYeuCau #RequirementElicitation #ChuyenDoiSo\nBài viết chia sẻ 3 nguyên tắc cốt lõi để tránh biến việc lấy yêu cầu thành \u0026ldquo;cơn ác mộng\u0026rdquo;, đúc kết từ thực tế dự án ERP/MES.\nPHẦN 1: HAI TRỞ NGẠI LỚN KHI LẤY YÊU CẦU # 1.1. Cái bẫy của \u0026ldquo;Kinh nghiệm\u0026rdquo; # Thiếu kinh nghiệm → chỉ khai thác được 30% tảng băng nổi. 70% còn lại nằm ở: Trường hợp ngoại lệ (Business cases) khách hàng quên kể. Rủi ro kỹ thuật tiềm tàng (tích hợp hệ thống, chuyển đổi dữ liệu). Yếu tố con người – phức tạp nhất. Giải quyết: phải \u0026ldquo;trầy vi tróc vảy\u0026rdquo; qua ít nhất một dự án trọn vẹn mới mong thuần thục. \u0026ldquo;Nếu không có kinh nghiệm, mình chỉ biết cầm cái bảng câu hỏi mẫu đi hỏi, và thứ mình nhận được chỉ là 30% tảng băng nổi.\u0026rdquo;\n1.2. Sự bất lực trong diễn đạt # Truyền đạt kém, lời nói không khớp ý nghĩ → đối tác hiểu sai. Giải pháp cá nhân: VẼ – mọi lúc mọi nơi, trên mọi công cụ (bảng trắng, giấy nháp, PowerPoint, Excel). Hỗ trợ làm rõ vấn đề khi \u0026ldquo;lời nói bất lực\u0026rdquo;. PHẦN 2: 3 NGUYÊN TẮC \u0026ldquo;BẤT DI BẤT DỊCH\u0026rdquo; # 2.1. Nguyên tắc 1: LUÔN CHUẨN BỊ (Fail to prepare = Prepare to fail) # a. Bảng câu hỏi (Questionnaire) \u0026ldquo;xương máu\u0026rdquo; # Tùy biến cho từng khách hàng, tuyệt đối không dùng template chung. Dựa trên RFP (Hồ sơ mời thầu) hoặc UR (Yêu cầu người dùng) – đây là những mô tả ban đầu thường mông lung → cần câu hỏi làm rõ. Nếu không có RFP, phải làm việc với Sales/PM để nắm Pain point (nỗi đau) của khách hàng. Cấu trúc bảng câu hỏi khuyên dùng: Cột 1: Số thứ tự Cột 2: Câu hỏi Cột 3: Câu trả lời ghi nhận Cột 4: Người/Bộ phận chịu trách nhiệm trả lời Review với Senior trong team để lấp lỗ hổng kiến thức. b. Sàng lọc đối tượng (Đúng người – Đúng việc) # Workshop nên tối giản, chỉ mời người liên quan trực tiếp: Kho → Thủ kho Sản xuất → Quản đốc Lên lịch trình chi tiết gửi khách hàng: ngày, giờ, cần gặp ai. Mục đích: tránh làm khách hàng mệt mỏi, trả lời qua loa → requirement tệ → dự án fail. c. Xác định mục tiêu rõ ràng # Trước khi vào họp, phải biết rõ mình muốn mang gì về: Quy trình Sales? Cách làm hợp đồng? Sơ đồ tổ chức? Có mục tiêu mới chọn đúng phương pháp \u0026ldquo;moi tin\u0026rdquo;. Lưu ý: Giai đoạn này là moi tin, đừng sa đà vào tư vấn quá sớm. Mình đến để nghe, không phải để dạy. \u0026ldquo;Bám sát mục tiêu là \u0026lsquo;Moi tin\u0026rsquo;, chứ đừng sa đà vào \u0026lsquo;Tư vấn\u0026rsquo; quá sớm. Mình đến để nghe họ nói, chứ không phải để dạy họ làm.\u0026rdquo;\n2.2. Nguyên tắc 2: TRỰC QUAN HÓA – KHI CẦN LÀ PHẢI \u0026ldquo;SHOW\u0026rdquo; # \u0026ldquo;Nói anh không hiểu thì tôi show hình cho anh xem.\u0026rdquo;\nSử dụng màn hình phần mềm, mockup, sơ đồ, diagram. Lợi ích: Đỡ buồn ngủ – mắt có cái để nhìn. Gom về một góc nhìn chung – tránh ông nói gà bà hiểu vịt. Dễ thảo luận, chỉ thẳng vào ký hiệu/quy trình. Thực hành: Đứng dậy, cầm bút lông, phác thảo lên bảng, vừa vẽ vừa nói. \u0026ldquo;Hàng về thì ông Kho nhận, rồi đẩy sang ông Kế toán…\u0026rdquo; Khách hàng xác nhận đúng/sai chỉ trong 5 giây, hiệu quả gấp trăm lần nói suông. 2.3. 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ý. Khi nghe, đầu phải nhảy số liên tục để: Kiểm tra chéo: cùng một câu hỏi, hỏi ông A và ông B có ra cùng đáp án không? Nếu lệch → có vấn đề. Phát hiện mâu thuẫn: câu trả lời cho vấn đề A có ý Y mâu thuẫn với quy trình B đã nghe trước đó → cần đào sâu. Quy trình tư duy: HỎI → PHÂN TÍCH → TỔNG HỢP → vẽ bức tranh tổng quan chính xác. Đừng quên kiểm tra chéo với team nhà (Dev/Tech lead) để đảm bảo giải pháp khả thi. \u0026ldquo;Sơ suất vớ nhầm thông tin sai là \u0026rsquo;tèo\u0026rsquo; ngay.\u0026rdquo;\nLời kết # Tác giả thừa nhận từng mắc nhiều sai lầm do thiếu chuẩn bị, nhưng những \u0026ldquo;vết sẹo\u0026rdquo; đó giúp đúc kết nên các nguyên tắc trên. Họp lấy yêu cầu không đáng sợ nếu nắm vững nguyên tắc, và luôn sẵn sàng sửa sai.\n","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/posts/3-nguyen-tac-song-con-de-lay-yeu-cau-hieu-qua/","section":"Posts","summary":"3 NGUYÊN TẮC “SỐNG CÒN” ĐỂ LẤY YÊU CẦU HIỆU QUẢ # Nguồn: Quân làm BA | Ngày: 15/12/2025\nThể loại: Nghề BA | Tags: #BusinessAnalyst #KinhNghiemThucChien #LayYeuCau #RequirementElicitation #ChuyenDoiSo\nBài viết chia sẻ 3 nguyên tắc cốt lõi để tránh biến việc lấy yêu cầu thành “cơn ác mộng”, đúc kết từ thực tế dự án ERP/MES.\n","title":"3 NGUYÊN TẮC \"SỐNG CÒN\" ĐỂ LẤY YÊU CẦU HIỆU QUẢ","type":"posts"},{"content":" BỘ KỸ NĂNG KHAI PHÁ \u0026ldquo;NHU CẦU THẬT\u0026rdquo; MÀ BA NÀO CŨNG CẦN! # Bài học thực tế từ dự án ERP nhà máy cơ khí – Tác giả: Quân làm BA\nBài học đắt giá: Làm phần mềm \u0026ldquo;xịn\u0026rdquo; mà không ai dùng # \u0026ldquo;Sản phẩm làm ra \u0026lsquo;xịn\u0026rsquo; thật, giao diện đẹp long lanh. Nhưng… KHÔNG AI DÙNG. Anh em thủ kho vẫn lén lút dùng sổ tay ghi chép. Dữ liệu trên phần mềm thì sai bét nhè.\u0026rdquo;\nNguyên nhân gốc rễ: BA chỉ ghi lại yêu cầu theo lời nói của Giám đốc (\u0026ldquo;làm cho anh cái phần mềm quản lý kho thông minh hơn, xịn hơn\u0026rdquo;) mà không khai phá nhu cầu thật phía sau.\n1. Đừng tin những gì họ nói (ngay lập tức) # Yêu cầu của stakeholder giống như tảng băng trôi – BA nếu chỉ nhìn phần nổi sẽ \u0026ldquo;đâm đầu vào đá\u0026rdquo;.\nBa lớp yêu cầu – Ví dụ minh họa # Lớp yêu cầu Ví dụ cụ thể Stated (Nói ra) \u0026ldquo;Anh muốn có nút Xuất Excel báo cáo tồn kho.\u0026rdquo; Implied (Ngầm định) \u0026ldquo;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.\u0026rdquo; (Họ coi đó là hiển nhiên) 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, họ phải cộng trừ thủ công mất cả ngày thứ Bảy. Giải pháp thật sự: Không phải cái nút Excel, mà là một Dashboard tự động cập nhật số liệu lên tivi của sếp. Khỏi cần báo cáo, khỏi cần in ấn.\nCảnh báo: Mù quáng làm theo lời họ nói sẽ dẫn đến Scope Creep (phình to phạm vi), sửa đi sửa lại không dứt.\n2. 9 kỹ thuật moi tin – Phiên bản nhà máy # Lý thuyết có 9 kỹ thuật, nhưng áp dụng vào môi trường sản xuất cần \u0026ldquo;ngầu\u0026rdquo; và linh hoạt.\n① Phỏng vấn – Đừng hỏi \u0026ldquo;Anh muốn gì?\u0026rdquo; # Đặt câu hỏi trúng nỗi đau của họ:\n\u0026ldquo;Khó khăn lớn nhất khiến anh hay bị trễ đơn hàng là gì?\u0026rdquo;\nKhi đó họ mới phun ra vấn đề thật: vật tư chậm, máy hỏng vặt… → mỏ vàng cho BA.\n② Quan sát / Shadowing – Đi \u0026ldquo;Gemba\u0026rdquo; # Xuống xưởng, đứng cạnh công nhân đóng gói. Để ý: tại sao cô ấy phải dừng máy để ghi chép vào tờ giấy nhàu nát? Nhìn lên máy, thấy dán đầy giấy note: \u0026ldquo;Lưu ý: Mã hàng X hay bị kẹt\u0026rdquo;.\n→ Đó chính là yêu cầu ngầm định không ai nói ra. ③ Hội thảo – \u0026ldquo;Sàn đấu vật\u0026rdquo; có trọng tài # Khi ông Kho và ông Mua hàng cãi nhau chuyện hàng về trễ, lùa hết vào một phòng.\nBA làm Facilitator, cho họ cãi chán rồi thống nhất quy trình chung. Không gặp riêng lẻ, nếu không họ sẽ đổ lỗi cho nhau (điều này dân dự án gặp suốt). ④ Phân tích tài liệu # Mượn sổ tay ghi chép, file Excel \u0026ldquo;lủng củng\u0026rdquo; của kế toán xưởng. Đọc để thấy quy trình thực tế đang chạy khác xa quy trình ISO trên giấy. ⑤ Benchmarking / Phân tích link # Khi sếp gửi link video \u0026ldquo;Nhà máy thông minh của Đức\u0026rdquo; và bảo \u0026ldquo;Làm cho anh giống thế này\u0026rdquo;, đừng hoảng.\nPhân tích xem video đó giải quyết vấn đề gì. Hỏi trực tiếp: \u0026ldquo;Anh tâm đắc nhất đoạn nào? Robot tự hành hay hệ thống báo cáo?\u0026rdquo; (Các kỹ thuật khác: Brainstorming, Survey, Prototyping… sẽ có bài chi tiết sau.)\n3. Công cụ là bạc, tư duy mới là vàng # 🔷 Thấu cảm (Empathy) # Đặt mình vào vị trí công nhân đứng 8 tiếng rã rời chân tay. Thiết kế giao diện: nút bấm to, dễ nhìn, thao tác đơn giản. Chỉ khi thấu hiểu nỗi đau của họ, sản phẩm mới có hồn. 🔷 Tư duy phản biện (Critical Thinking) – 5 Whys # Liên tục hỏi Tại sao để tìm gốc rễ:\nTại sao số liệu sai?\n→ Do nhập sai.\n→ Tại sao nhập sai?\n→ Do mã hàng quá dài khó nhớ.\n→ Tại sao không dùng mã vạch?\nVấn đề gốc rễ nằm ở đó.\nTHIẾT NGHĨ… # \u0026ldquo;Khơi gợi yêu cầu không phải là điền vào chỗ trống. Nó là hành trình đi tìm SỰ THẬT.\u0026rdquo;\nHãy chuyển mình từ người hỏi \u0026ldquo;Cần gì?\u0026rdquo; thành người tư vấn \u0026ldquo;Nên làm gì để giải quyết vấn đề?\u0026rdquo;.\n\u0026ldquo;Làm ra một cái 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 bỏ cuốn sổ tay đi để dùng… cái đó mới khó.\u0026rdquo;\n📖 Xem thêm:\nXem thêm: 3 nguyên tắc sống còn để lấy yêu cầu\nXem thêm: BA trong nhà máy: 6 món võ\n","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/posts/bo-ky-nang-khai-pha-nhu-cau-that-ma-ba-nao-cung-can/","section":"Posts","summary":"BỘ KỸ NĂNG KHAI PHÁ “NHU CẦU THẬT” MÀ BA NÀO CŨNG CẦN! # Bài học thực tế từ dự án ERP nhà máy cơ khí – Tác giả: Quân làm BA\nBài học đắt giá: Làm phần mềm “xịn” mà không ai dùng # “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 lút dùng sổ tay ghi chép. Dữ liệu trên phần mềm thì sai bét nhè.”\n","title":"BỘ KỸ NĂNG KHAI PHÁ \"NHU CẦU THẬT\" MÀ BA NÀO CŨNG CẦN!","type":"posts"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/businessanalyst/","section":"Tags","summary":"","title":"BusinessAnalyst","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/chuyendoiso/","section":"Tags","summary":"","title":"ChuyenDoiSo","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/kinhnghiemthucchien/","section":"Tags","summary":"","title":"KinhNghiemThucChien","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/layyeucau/","section":"Tags","summary":"","title":"LayYeuCau","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/quanlamba/","section":"Tags","summary":"","title":"QuanLamBA","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/requirementelicitation/","section":"Tags","summary":"","title":"RequirementElicitation","type":"tags"},{"content":"","date":"15 tháng 12, 2025","externalUrl":null,"permalink":"/tags/sanxuat/","section":"Tags","summary":"","title":"SanXuat","type":"tags"},{"content":" BA TRONG NHÀ MÁY: 6 \u0026ldquo;MÓN VÕ\u0026rdquo; PHÒNG THÂN ĐỂ KHÔNG BỊ \u0026ldquo;GÃY\u0026rdquo; DỰ ÁN # Tác giả: Quân (Quân làm BA)\nNguồn: quanlamba.wordpress.com\nNgày: 11/12/2025\nBài viết chia sẻ kinh nghiệm thực chiến của một Business Analyst (BA) trong môi trường nhà máy sản xuất. Từ thất bại ban đầu khi bỏ qua BABOK, tác giả đúc kết 6 Vùng Kiến thức (Knowledge Areas) cốt lõi giúp BA trụ vững – được \u0026ldquo;Việt hóa\u0026rdquo; bằng ngôn ngữ bình dị, dễ áp dụng.\n🔑 Tư duy cốt lõi # \u0026ldquo;Kiến thức trong sách (BABOK) nó là cái móng nhà. Kinh nghiệm thực chiến là những viên gạch. Thiếu cái nào thì nhà cũng đổ.\u0026rdquo;\nBA trong nhà máy là \u0026ldquo;làm dâu trăm họ\u0026rdquo;, vừa phải hiểu chuyên môn sản xuất vừa phải giao tiếp với đội Dev. Nếu chỉ lao vào làm mà thiếu phương pháp, dự án sẽ \u0026ldquo;gãy\u0026rdquo;.\n🛠️ 6 \u0026ldquo;MÓN VÕ\u0026rdquo; PHÒNG THÂN (Knowledge Areas thực chiến) # 1. Planning \u0026amp; Monitoring – Lập kế hoạch \u0026amp; Theo dõi # Khẩu quyết: Đừng để \u0026ldquo;nước đến chân mới nhảy\u0026rdquo;\nBA không thể ỷ lại vào Project Manager. Nhà máy có lịch trình \u0026ldquo;lủng cà lủng củng\u0026rdquo;: họ bận kiểm kê, quyết toán thuế bất ngờ. Cần kế hoạch tiếp cận (BA Approach) rõ ràng: gặp ai, lúc nào, chuẩn bị gì. Tác dụng: chủ động thay vì bị task dồn dập \u0026ldquo;đè\u0026rdquo; chết. 2. Elicitation \u0026amp; Collaboration – Khơi gợi \u0026amp; Cộng tác # Khẩu quyết: Nghệ thuật \u0026ldquo;moi tin\u0026rdquo;\n\u0026ldquo;Thông tin không bao giờ nằm trên mặt bàn, nó nằm trong đầu người dùng.\u0026rdquo;\nPhân biệt: Không phải đơn thuần \u0026ldquo;lấy yêu cầu\u0026rdquo; (Gather), mà phải khơi gợi (Elicitation). Công nhân/quản đốc chỉ than: \u0026ldquo;Máy hay hỏng lắm\u0026rdquo;, \u0026ldquo;Viết giấy mỏi tay lắm\u0026rdquo; – không nói được ngôn ngữ phần mềm. BA phải \u0026ldquo;ngồi trà đá, hút thuốc\u0026rdquo; để moi ra Pain point thật sự ẩn sau lời than đó. 3. Requirements Life Cycle Management – Quản lý vòng đời yêu cầu # Khẩu quyết: Trị bệnh \u0026ldquo;Sáng nắng chiều mưa\u0026rdquo;\n\u0026ldquo;Hôm nay Sếp chốt: \u0026lsquo;Làm nút màu xanh\u0026rsquo;. Tuần sau Sếp đổi ý: \u0026lsquo;Thôi màu đỏ cho hợp phong thủy\u0026rsquo;.\u0026rdquo;\nĐây là cơn ác mộng với mọi dự án. Nếu BA gật đầu vô tội vạ, Scope sẽ \u0026ldquo;nát bét\u0026rdquo;. Kỹ năng quản lý yêu cầu: biết khi nào Say Yes, Say No, đánh giá tác động đến tiến độ \u0026amp; tiền bạc. Bắt buộc: quy trình, giấy trắng mực đen – không dùng lời nói. 4. Strategy Analysis – Phân tích chiến lược # Khẩu quyết: Nhìn rừng chứ đừng chỉ nhìn cây\n\u0026ldquo;Anh muốn mua phần mềm CRM.\u0026rdquo; – Câu hỏi chất vấn: \u0026ldquo;Tại sao anh cần CRM? Chiến lược kinh doanh 3 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 hàng cũ?\u0026rdquo;\nBA non tay sẽ đi tìm CRM ngay. BA có tầm sẽ phân tích chiến lược trước. Hiểu đúng chiến lược giúp tư vấn giải pháp đúng. Đôi khi cái cần không phải CRM mà là chấn chỉnh quy trình Sales đang lộn xộn. 5. Requirements Analysis \u0026amp; Design Definition – Phân tích \u0026amp; Thiết kế # Khẩu quyết: Vai trò \u0026ldquo;Người phiên dịch\u0026rdquo;\n\u0026ldquo;Dịch sai một chữ, ông Dev code sai một dặm.\u0026rdquo;\nKhi có một đống thông tin hổ lốn từ xưởng, BA phải \u0026ldquo;xào nấu\u0026rdquo; lại: Biến lời than thành sơ đồ (Flowchart) Thành mô hình dữ liệu Thành bản mô tả (SRS) cho IT hiểu ngay. Đòi hỏi tư duy logic cực mạnh. 6. Solution Evaluation – Đánh giá giải pháp # Khẩu quyết: Có dùng được hay \u0026ldquo;đắp chiếu\u0026rdquo;?\n\u0026ldquo;Nế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.\u0026rdquo;\nKhông chỉ kiểm tra hết bug. Phải hỏi: Nó có giải quyết được vấn đề ban đầu không? Ba câu hỏi sống còn: 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í? Giá trị thực sự mang lại là gì? 💡 Bài học \u0026amp; Tổng kết # BABOK là nền móng – đừng như tác giả ngày đầu:\n\u0026ldquo;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.\u0026rdquo; → \u0026ldquo;Đời không như là mơ.\u0026rdquo;\nThực chiến là gạch xây – chỉ có nền móng hoặc chỉ có gạch đều khiến \u0026ldquo;nhà\u0026rdquo; đổ.\nTrong môi trường sản xuất phức tạp, BA phải:\n✅ Chủ động lên kế hoạch\n✅ Moi đúng nỗi đau\n✅ Quản lý thay đổi chặt chẽ\n✅ Nhìn chiến lược trước khi nhìn tính năng\n✅ Phiên dịch chính xác nghiệp vụ sang công nghệ\n✅ Đánh giá hiệu quả thực tế sau triển khai\nBài viết đăng kèm hashtag: #BusinessAnalyst #BABOK #ChuyenDoiSo #ERP #TuDuyLamNghe #DangDucQuan\n📖 Xem thêm:\nXem thêm: Tại sao dự án ERP thất bại ","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/posts/ba-trong-nha-may-6-mon-vo-phong-than-de-khong-bi-gay-du-an/","section":"Posts","summary":"BA TRONG NHÀ MÁY: 6 “MÓN VÕ” PHÒNG THÂN ĐỂ KHÔNG BỊ “GÃY” DỰ ÁN # Tác giả: Quân (Quân làm BA)\nNguồn: quanlamba.wordpress.com\nNgày: 11/12/2025\nBài viết chia sẻ kinh nghiệm thực chiến của một Business Analyst (BA) trong môi trường nhà máy sản xuất. Từ thất bại ban đầu khi bỏ qua BABOK, tác giả đúc kết 6 Vùng Kiến thức (Knowledge Areas) cốt lõi giúp BA trụ vững – được “Việt hóa” bằng ngôn ngữ bình dị, dễ áp dụng.\n","title":"BA TRONG NHÀ MÁY: 6 \"MÓN VÕ\" PHÒNG THÂN ĐỂ KHÔNG BỊ \"GÃY\" DỰ ÁN","type":"posts"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/babok/","section":"Tags","summary":"","title":"BABOK","type":"tags"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/chuyennganhba/","section":"Tags","summary":"","title":"ChuyenNganhBA","type":"tags"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/dangducquan/","section":"Tags","summary":"","title":"DangDucQuan","type":"tags"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/dealluong/","section":"Tags","summary":"","title":"DealLuong","type":"tags"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/gocnhinthucchien/","section":"Tags","summary":"","title":"GocNhinThucChien","type":"tags"},{"content":"","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/tags/tuduylamnghe/","section":"Tags","summary":"","title":"TuDuyLamNghe","type":"tags"},{"content":" Vài Kinh Nghiệm Về Chuyện Deal Lương Cho \u0026ldquo;BA Tay Ngang\u0026rdquo; # Nguồn: Quân làm BA – 11/12/2025\nBài viết chia sẻ chiến lược đàm phán lương thực chiến dành cho người chuyển ngành và fresher BA, xây dựng trên tư duy \u0026ldquo;dữ liệu và phân tích\u0026rdquo; đúng chất BA.\n1. Tư duy cốt lõi: Trao đổi giá trị, không xin – cho # \u0026ldquo;Bản chất của việc tuyển dụng nó sòng phẳng lắm: TRAO ĐỔI GIÁ TRỊ.\u0026rdquo;\nCô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…). Bạn là \u0026ldquo;thuốc giải\u0026rdquo; – Business Analyst. Lương là cái giá họ trả cho giải pháp bạn mang lại. Chuyển câu hỏi từ \u0026ldquo;Mình xin bao nhiêu thì được?\u0026rdquo; thành \u0026ldquo;Giải pháp mình mang lại trị giá bao nhiêu?\u0026rdquo; → đàm phán trở thành cuộc đối thoại sòng phẳng của hai người lớn.\n2. Chuẩn bị \u0026ldquo;vũ khí\u0026rdquo; – Dữ liệu, dữ liệu, dữ liệu # \u0026ldquo;Anh em làm BA mà đi deal lương bằng… niềm tin thì chết dở.\u0026rdquo;\nBước 0: Nghiên cứu thị trường (Market Research) # Quét các trang tuyển dụng (TopCV, ITviec…), group cộng đồng BA, báo cáo lương (Adecco, Navigos). Lập file Excel liệt kê mặt bằng lương theo: Cấp bậc (Fresher, Junior) Loại công ty (Product, Outsource) Khu vực (Hà Nội, TP.HCM) → Kết quả: con số cụ thể, không còn \u0026ldquo;hình như\u0026rdquo;, \u0026ldquo;em nghĩ là…\u0026rdquo;.\nBước 0.5: Định giá bản thân (Pricing) # Xác định 3 con số riêng:\nĐiểm Sàn (Walk-away point): Mức tối thiểu chấp nhận để trang trải cuộc sống. Giữ bí mật. Điểm Mục Tiêu (Target point): Mức xứng đáng và khiến bạn hạnh phúc. Điểm \u0026ldquo;Trong Mơ\u0026rdquo; (Dream point): Cao hơn thị trường một chút, dùng khi bạn ở thế cửa trên. 3. \u0026ldquo;Kho vũ khí\u0026rdquo; cho người chuyển ngành \u0026amp; fresher # \u0026ldquo;Kinh nghiệm cũ KHÔNG BAO GIỜ là vô nghĩa. Quan trọng là anh em có biết cách \u0026lsquo;PHIÊN DỊCH\u0026rsquo; nó sang ngôn ngữ BA hay không.\u0026rdquo;\nĐối với người chuyển ngành (tay ngang) # Marketing: Đừng kể chạy Ads. Hãy nói về \u0026ldquo;phân tích hành vi khách hàng\u0026rdquo;, \u0026ldquo;tìm Pain point\u0026rdquo; → User Research. Kế toán/Tài chính: Đừng nói chỉ biết nhập liệu. Hãy nhấn mạnh \u0026ldquo;tối ưu hóa quy trình báo cáo\u0026rdquo;, \u0026ldquo;tự động hóa bằng Excel\u0026rdquo; → Process Improvement. Sale/CSKH: Hãy nói bạn là \u0026ldquo;cầu nối\u0026rdquo;, lắng nghe khách hàng và \u0026ldquo;chuyển hóa feedback thành yêu cầu cải tiến sản phẩm\u0026rdquo;. Đối với sinh viên mới # Kinh nghiệm làm việc = 0? Lôi đồ án tốt nghiệp, dự án cá nhân (vẽ Wireframe, viết User Story), vai trò tổ chức sự kiện ra kể → chứng minh kỹ năng \u0026ldquo;Quản lý Stakeholder\u0026rdquo;, tư duy BA. Nhà tuyển dụng fresher đang mua tiềm năng. 4. Kịch bản thực chiến khi \u0026ldquo;con số\u0026rdquo; xuất hiện # Nguyên tắc vàng: Né ra giá trước # \u0026ldquo;Ai ra giá trước, người đó mất lợi thế \u0026lsquo;mỏ neo\u0026rsquo;.\u0026rdquo;\nKhéo léo: \u0026ldquo;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…\u0026rdquo; → đẩy bóng về phía HR. Nếu bị ép ra giá # Dùng khoảng lương (Range) đã chuẩn bị: \u0026ldquo;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…\u0026rdquo; Nếu họ trả thấp hơn kỳ vọng # Cảm ơn \u0026amp; Ghi nhận: \u0026ldquo;Em rất vui vì offer này…\u0026rdquo; Trình bày luận điểm (dùng data): \u0026ldquo;Tuy nhiên, theo nghiên cứu của em thì mặt bằng chung…\u0026rdquo; cộng với \u0026ldquo;Với kinh nghiệm X năm làm nghề cũ, em tin em có thể…\u0026rdquo; Đề nghị ngược (Counter-offer): Đưa con số ở giữa, hoặc chuyển hướng sang phúc lợi khác. Nhìn vào Tổng thu nhập (Total Package) # Lương cứng thấp nhưng có: thưởng dự án, bảo hiểm xịn, nguồn ngân sách học chứng chỉ ECBA miễn phí… → có thể lợi hơn vài triệu tiền lương. 5. Những cái bẫy \u0026ldquo;chết người\u0026rdquo; # Nói dối lương cũ: Tuyệt đối không – mất niềm tin là mất hết. Đưa lý do cá nhân: \u0026ldquo;Em cần tiền đóng trọ\u0026rdquo;, \u0026ldquo;Vợ em sắp đẻ\u0026rdquo; – nhà tuyển dụng không quan tâm, họ chỉ quan tâm bạn làm được gì cho họ. Chấp nhận offer ngay lập tức: Dù sướng đến mấy cũng phải \u0026ldquo;Xin phép suy nghĩ đến mai\u0026rdquo; để giữ giá trị và sự cẩn trọng. Thái độ \u0026ldquo;cửa trên\u0026rdquo;: Đàm phán là hợp tác, không phải cãi nhau. Kết luận: Deal lương cũng như 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 thắng-thắng. Sự tự tin đến từ sự chuẩn bị, không phải từ \u0026ldquo;chém gió\u0026rdquo;. Cầm file Excel phân tích lương trong tay, cuộc nói chuyện sẽ khác hẳn.\nHashtags bài viết: #BusinessAnalyst #ChuyenNganhBA #DealLuong #GocNhinThucChien\n📖 Xem thêm:\nXem thêm: Business Analyst là gì? ","date":"11 tháng 12, 2025","externalUrl":null,"permalink":"/posts/vai-kinh-nghiem-ve-chuyen-deal-luong-cho-ba-tay-ngang/","section":"Posts","summary":"Vài Kinh Nghiệm Về Chuyện Deal Lương Cho “BA Tay Ngang” # Nguồn: Quân làm BA – 11/12/2025\nBài viết chia sẻ chiến lược đàm phán lương thực chiến dành cho người chuyển ngành và fresher BA, xây dựng trên tư duy “dữ liệu và phân tích” đúng chất BA.\n1. Tư duy cốt lõi: Trao đổi giá trị, không 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Ị.”\n","title":"VÀI KINH NGHIỆM VỀ CHUYỆN DEAL LƯƠNG CHO \"BA TAY NGANG\"","type":"posts"},{"content":" BẠN LÀ \u0026ldquo;PHI CÔNG\u0026rdquo; HAY LÀ \u0026ldquo;THỢ MÁY\u0026rdquo;? # Chao-xìn anh iem…\nNay tranh thủ lúc boarding, làm kiểu ảnh check-in. Ngồi ngắm cái máy bay, bệnh nghề nghiệp lại tái phát. Hehe…\nAnh em thử tưởng tượng nhé. Ông phi công, ổng ngồi trong buồng lái kín bưng. Ổng đâu có nhìn thấy cái cánh quạt đang quay thế nào, đâu có thò đầu ra ngoài xem bánh xe đã thu lên chưa.\nThứ duy nhất ổng nhìn… là cái MÀN HÌNH ĐIỀU KHIỂN (Dashboard). Tốc độ gió, độ cao, nhiên liệu, nhiệt độ động cơ… tất cả gom về những con số xanh đỏ trước mặt.\n…\nNhìn lại nhiều anh chủ nhà máy (khách hàng của mình). Nhiều khi thấy các anh khổ quá. Mang tiếng là Tổng Giám đốc (Cơ trưởng), nhưng cứ phải chạy xuống xưởng (làm thợ máy) để xem \u0026ldquo;Hàng làm đến đâu rồi?\u0026rdquo;, \u0026ldquo;Máy này sao lại hỏng?\u0026rdquo;.\nTại sao? Tại vì không có dữ liệu. Hoặc có thì là dữ liệu \u0026ldquo;chết\u0026rdquo; từ tuần trước. Làm sao dám ngồi phòng máy lạnh mà điều hành khi dưới xưởng là một cái \u0026ldquo;hộp đen\u0026rdquo; mù mịt?\nChuyển đổi số trong sản xuất, nói cho vuông, là quá trình xây dựng cái Dashboard buồng lái đó cho doanh nghiệp.\nĐể người lãnh đạo thực sự được làm công việc của một Phi công: Nhìn dữ liệu – Ra quyết định – Và đưa con tàu đi đúng hướng. Chứ không phải là người chạy đi vặn từng con ốc.\nBay lên nào! ✈️\n📖 Xem thêm:\nXem thêm: BA trong nhà máy: 6 món võ ","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/posts/ban-la-phi-cong-hay-la-tho-may/","section":"Posts","summary":"BẠN LÀ “PHI CÔNG” HAY LÀ “THỢ MÁY”? # Chao-xìn anh iem…\nNay tranh thủ lúc boarding, làm kiểu ảnh check-in. Ngồi ngắm cái máy bay, bệnh nghề nghiệp lại tái phát. Hehe…\nAnh em thử tưởng tượng nhé. Ông phi công, ổng ngồi trong buồng lái kín bưng. Ổng đâu có nhìn thấy cái cánh quạt đang quay thế nào, đâu có thò đầu ra ngoài xem bánh xe đã thu lên chưa.\n","title":"BẠN LÀ \"PHI CÔNG\" HAY LÀ \"THỢ MÁY\"?","type":"posts"},{"content":"","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/tags/ceo/","section":"Tags","summary":"","title":"CEO","type":"tags"},{"content":"","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/tags/dashboard/","section":"Tags","summary":"","title":"Dashboard","type":"tags"},{"content":"","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/tags/digitaltransformation/","section":"Tags","summary":"","title":"DigitalTransformation","type":"tags"},{"content":"","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/tags/leadership/","section":"Tags","summary":"","title":"Leadership","type":"tags"},{"content":"","date":"2 tháng 12, 2025","externalUrl":null,"permalink":"/tags/mes/","section":"Tags","summary":"","title":"MES","type":"tags"},{"content":"","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/tags/chiemnghiemnghe/","section":"Tags","summary":"","title":"ChiemNghiemNghe","type":"tags"},{"content":"","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/tags/chuyenngheba/","section":"Tags","summary":"","title":"ChuyenNgheBA","type":"tags"},{"content":" CHUYỆN VỀ \u0026ldquo;CÁI NẾT\u0026rdquo; LÀM NGHỀ – Quân làm BA # Nguồn: Quân làm BA – blog post\nTác giả: Quân (Quanlamba)\nThể loại: Góc nhìn nghề BA (Business Analyst)\nBài viết dưới dạng tản mạn, chia sẻ những trăn trở của một BA có kinh nghiệm về tầm quan trọng của \u0026ldquo;cái nết\u0026rdquo; – tức các đặc điểm hành vi (Behavioral Characteristics) – hơn là các kỹ năng cứng (hard skills).\n1. Mở đầu: Nỗi lo của người làm nghề # Tác giả quan sát thấy nhiều bạn BA mới ra trường, thực tập thường hỏi:\n\u0026ldquo;Anh ơi học tool nào cho ngầu?\u0026rdquo;, \u0026ldquo;Anh ơi vẽ BPMN thế nào cho chuẩn?\u0026rdquo;, \u0026ldquo;Học Python hay PHP thì lương cao hơn?\u0026quot;…\nNhững câu hỏi đó khiến anh lo ngại, vì kỹ năng cứng như \u0026ldquo;thanh kiếm sắc\u0026rdquo; – muốn dùng đúng cần một nền tảng về thái độ, đạo đức nghề nghiệp. Anh gọi đó là \u0026ldquo;cái nết làm nghề\u0026rdquo; (theo BABOK là \u0026ldquo;Behavioral Characteristics\u0026rdquo;).\nThiết nghĩ, trước khi thành một chuyên gia, mình phải thành một con người \u0026ldquo;tử tế\u0026rdquo; cái đã.\n2. Ba trụ cột của \u0026ldquo;cái nết làm nghề\u0026rdquo; # 2.1. Đạo đức (Ethics) – Cái ranh giới mong manh # BA nắm trong tay dữ liệu sống còn, quy trình, bí mật kinh doanh của khách hàng. Dễ bị lung lay trước những tình huống như: \u0026ldquo;Em ơi, hay là mình \u0026lsquo;xào\u0026rsquo; lại cái số liệu này tí cho báo cáo nó đẹp?\u0026rdquo;\nHoặc phát hiện lỗ hổng quy trình mà thiên vị bên này, hại bên kia. Đạo đức không phải là làm từ thiện, mà là sự công bằng (Fairness):\nGiải pháp đề xuất phải tốt cho tổng thể doanh nghiệp, không phải vì thích/ghét cá nhân. Giữ vững điều đó mới \u0026ldquo;ngủ ngon được\u0026rdquo;. 2.2. Trách nhiệm cá nhân (Personal Accountability) – Đừng đổ tại \u0026ldquo;số\u0026rdquo; # Thói quen đổ thừa rất phổ biến:\nDự án chậm: \u0026ldquo;Tại ông Dev code chậm.\u0026rdquo; Requirement sai: \u0026ldquo;Tại khách hàng đổi ý liên tục.\u0026rdquo; Họp muộn: \u0026ldquo;Tại trời mưa tắc đường.\u0026rdquo; Trách nhiệm cá nhân là tính Làm chủ (Ownership):\nNhận việc gì, việc đó là \u0026ldquo;đứa con\u0026rdquo; của mình, thành bại do mình. Khách hàng thay đổi → clear lại scope; Dev chậm → hỗ trợ hoặc báo sớm. Không hứa suông, làm chưa xong phải thấy áy náy, thấy nhục, không coi là bình thường. Uy tín của một thằng đàn ông (và một người làm nghề) nó được xây bằng những hành động nhỏ nhặt thế thôi.\n2.3. Sự tin cậy (Trustworthiness) – Tài sản lớn nhất của BA # Khách hàng mở lòng chia sẻ nỗi đau không phải vì BA giỏi kỹ thuật, mà vì họ tin mình.\nĐể được tin:\nTrung thực: giải pháp rủi ro → nói thẳng; mình sai → nhận lỗi, sửa ngay; dự án có dấu hiệu \u0026ldquo;toang\u0026rdquo; → cảnh báo sớm. Không \u0026ldquo;lươn lẹo\u0026rdquo;, tránh giấu lỗi như \u0026ldquo;mèo giấu…\u0026rdquo;. Sự tin cậy nó giống như cái ly thuỷ tinh ấy. Xây thì lâu, mà đập vỡ thì chỉ cần một lần \u0026ldquo;lươn lẹo\u0026rdquo;.\nKhi stakeholder tin tưởng, BA trở thành điểm tựa vững chãi, nói gì họ cũng nghe. Mất niềm tin → vẽ quy trình đẹp đến mấy cũng bị vứt sọt rác.\n3. Kết luận # Nghề BA (và mọi nghề khác) suy cho cùng là giải quyết vấn đề cho con người, nên thái độ sống, cái nết quan trọng hơn bằng cấp. Kỹ năng thiếu có thể học bổ sung, nhưng đạo đức lệch, trách nhiệm thiếu, niềm tin mất thì không ai cứu nổi. Lời nhắn: \u0026ldquo;Chậm một chút cũng được, nhưng đi cho nó chắc.\u0026rdquo; Bài tiếp theo hứa hẹn sẽ \u0026ldquo;chém gió\u0026rdquo; về những kỹ năng hàn lâm hơn.\nTags: #BusinessAnalyst #ChuyenNgheBA #TamSu #QuanLamBA #ThaiDoLamViec\n📖 Xem thêm:\nXem thêm: Business Analyst là gì? ","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/posts/chuyen-ve-cai-net-lam-nghe/","section":"Posts","summary":"CHUYỆN VỀ “CÁI NẾT” LÀM NGHỀ – Quân làm BA # Nguồn: Quân làm BA – blog post\nTác giả: Quân (Quanlamba)\nThể loại: Góc nhìn nghề BA (Business Analyst)\nBài viết dưới dạng tản mạn, chia sẻ những trăn trở của một BA có kinh nghiệm về tầm quan trọng của “cái nết” – tức các đặc điểm hành vi (Behavioral Characteristics) – hơn là các kỹ năng cứng (hard skills).\n","title":"CHUYỆN VỀ \"CÁI NẾT\" LÀM NGHỀ","type":"posts"},{"content":"","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/tags/gocnhin/","section":"Tags","summary":"","title":"GocNhin","type":"tags"},{"content":"","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/tags/tamsu/","section":"Tags","summary":"","title":"TamSu","type":"tags"},{"content":"","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/tags/thaidolamviec/","section":"Tags","summary":"","title":"ThaiDoLamViec","type":"tags"},{"content":" Thế túm lại Business Analyst là gì nhuỷ? # Hôm nay ngồi cafe, nghe mấy anh em kháo nhau: \u0026ldquo;Làm BA (Business Analyst) sướng nhỉ, chỉ việc làm cái \u0026lsquo;cầu nối\u0026rsquo;, đi dịch tiếng người (Khách hàng) sang tiếng máy (Dev) là xong.\u0026rdquo;\nNghe xong… mình chỉ cười trừ ._.\nThấm thoát thoi đưa, hồi mới vào nghề, thú thật 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è là có lương.\nNhưng làm rồi mới thấy… đời nó không như mơ.\n1. Vốn dĩ, BA không phải là cái Chức danh, nó là Tư duy\nNhiều người cứ thần thánh hóa, nghĩ BA (Bít nit ana lít) là phải biết vẽ hươu vẽ vượn, phải rành SQL, API này nọ…\nNhưng Thiết nghĩ, bản chất của nghề BA nó đơn giản (và cũng chua chát) hơn nhiều: Đó là nhìn thấy một đống quy trình đang \u0026ldquo;lủng cà lủng củng\u0026rdquo; của doanh nghiệp, và tìm cách làm cho nó mượt mà hơn.\nQuy trình chuẩn của một ông BA thực thụ nó chạy \u0026ldquo;kiểu lày\u0026rdquo;: Nhìn thấy \u0026ldquo;Nỗi đau\u0026rdquo; (Problem) -\u0026gt; Xác định mục tiêu (Objective) -\u0026gt; Tìm giải pháp (Solution) -\u0026gt; Triển khai (Transition).\nNếu cái đích đến là \u0026ldquo;giải quyết vấn đề\u0026rdquo;, thì Solution không nhất thiết cứ phải là phần mềm xịn sò. Đôi khi, chỉ cần thay đổi thói quen, hoặc dùng một file Excel cùi bắp… miễn sao nó hiệu quả là được.\nCái quan trọng không phải là công cụ, mà là Tư duy giải quyết vấn đề.\n2. BA tồn tại ở mọi ngóc ngách (kể cả lúc… hết xăng)\nNói lý thuyết thì mông lung, lấy cái ví dụ này cho đời thường cả nhà nhé.\nĐang đi làm về… xe hết xăng. Lúc này cái \u0026ldquo;Business Objective\u0026rdquo; của anh em là gì ạ? Là \u0026ldquo;vác cái xác về nhà ăn cơm với vợ\u0026rdquo; đúng không?\nThế là cái đầu \u0026ldquo;ba\u0026rdquo; trong mình bắt đầu nảy số các Solution:\nLúc này, anh em phải cân nhắc các \u0026ldquo;Stakeholders\u0026rdquo; (Vợ đang chờ cơm, con đang khóc, hay thằng bạn đang rảnh…). Chọn phương án nào để các bên đều vui vẻ, hài lòng nhất… đấy chính là làm BA.\n3. Và túm lại…\nBiế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.\nĐó mới là cái \u0026ldquo;Lẽ sống\u0026rdquo; của nghề này. Chứ làm \u0026ldquo;cầu nối\u0026rdquo; không thôi thì … lắm nhỉ ^^\nAnh em làm BA thấy mình nói có đúng không?\n📖 Xem thêm:\nXem thêm: BA mới vào nghề: 5 cú sốc không ai nói trước\nXem thêm: Chuyện về \u0026ldquo;cái nết\u0026rdquo; làm nghề\n","date":"1 tháng 12, 2025","externalUrl":null,"permalink":"/posts/the-tum-lai-business-analyst-la-gi-nhuy/","section":"Posts","summary":"Thế túm lại Business Analyst là gì nhuỷ? # 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.”\nNghe xong… mình chỉ cười trừ ._.\nThấm thoát thoi đưa, hồi mới vào nghề, thú thật 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è là có lương.\n","title":"Thế túm lại Business Analyst là gì nhuỷ?","type":"posts"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"}]