Practice: Case Study — E-commerce Platform

Mở đầu — vì sao bài này quan trọng

Suốt chín bài trước, bạn đã học từng mảnh ghép riêng lẻ của nghề BA: Business Analysis là gì, phân loại requirements, phân tích stakeholder, các kỹ thuật elicitation, cách viết User Story, PRD/BRD, vẽ Process Flow, và làm việc với Jira/Confluence. Mỗi mảnh ghép đều quan trọng, nhưng trong thực tế, không ai trả lương cho bạn để làm từng kỹ thuật một cách rời rạc. Người ta trả lương để bạn giải quyết trọn vẹn một bài toán nghiệp vụ — từ lúc khách hàng nói "tôi muốn làm cái này" cho tới lúc đội dev có đủ thông tin để bắt tay vào code.

Bài này là bài thực hành tổng hợp. Chúng ta sẽ cùng đi qua một case study xuyên suốt: Công ty bán lẻ XYZ muốn xây dựng một nền tảng e-commerce. Đây là kiểu dự án bạn gần như chắc chắn sẽ gặp ở Việt Nam — nơi hàng triệu shop đang bán hàng qua Facebook và Zalo, quản lý đơn bằng Excel, và đến một ngày họ nhận ra mô hình thủ công đã chạm trần. Khi đó họ tìm đến một BA.

Mục tiêu của bài không phải dạy bạn thêm khái niệm mới, mà là rèn phản xạ áp dụng: nhìn một tình huống mơ hồ, biết nên dùng kỹ thuật nào trước, đặt câu hỏi gì, viết ra output gì, và bàn giao cho ai. Hãy coi đây như một buổi đi thực địa cùng mentor, thay vì đọc lý thuyết.

Khái niệm cốt lõi

Tư duy "end-to-end" của một BA

Điểm khác biệt giữa BA giỏi và BA mới vào nghề không nằm ở việc biết nhiều kỹ thuật, mà ở việc biết xâu chuỗi chúng. Một dòng chảy điển hình của dự án trông như sau:

• Hiểu bối cảnh & mục tiêu kinh doanh — vì sao công ty muốn làm dự án này, họ đo thành công bằng gì.
• Xác định stakeholder — ai liên quan, ai quyết định, ai bị ảnh hưởng.
• Elicitation — thu thập yêu cầu bằng phỏng vấn, workshop, phân tích tài liệu/dữ liệu hiện có.
• Phân tích & mô hình hóa — biến mớ thông tin thô thành process flow, user story, scope rõ ràng.
• Documentation — viết ra tài liệu để cả business lẫn dev cùng hiểu.
• Xác nhận & bàn giao — playback cho stakeholder, đưa vào backlog Jira cho team.

Trong case study XYZ, bạn sẽ thấy sáu bước này không tách rời mà gối đầu lên nhau.

Bối cảnh case study: Công ty bán lẻ XYZ

XYZ là một thương hiệu thời trang nữ tầm trung ở TP.HCM, thành lập 2019. Hiện trạng:

• Kênh bán: Fanpage Facebook (180.000 follower) và Zalo OA. Khách inbox, nhân viên chốt đơn thủ công.
• Quản lý đơn: Một file Excel dùng chung trên Google Sheets, 6 nhân viên cùng nhập tay.
• Tồn kho: Đếm tay cuối ngày, thường xuyên lệch — bán trùng món đã hết hàng khoảng 8-10 đơn/tuần.
• Thanh toán: Chuyển khoản hoặc COD, đối soát thủ công với sao kê ngân hàng.
• Doanh thu: ~2,5 tỷ/tháng, ~1.500 đơn/tháng, đang tăng nhưng "nghẽn cổ chai" vì quy trình tay.

Ban giám đốc XYZ nói một câu rất quen thuộc: "Chị muốn có một website bán hàng cho chuyên nghiệp, kiểu như Shopee ấy." Đây chính là cái bẫy đầu tiên — yêu cầu mơ hồ, tham chiếu một sản phẩm khổng lồ, và chưa nói rõ vấn đề thực sự cần giải. Nhiệm vụ của BA là bóc tách câu nói đó thành requirements khả thi.

Phân biệt "vấn đề" và "giải pháp"

Khách hàng thường đến với bạn bằng một giải pháp ("làm website giống Shopee"), trong khi việc của BA là tìm ra vấn đề đằng sau ("đơn hàng thất thoát vì quản lý tay", "không scale được khi đơn tăng"). Nếu bạn nhảy thẳng vào việc nhận yêu cầu làm website mà không hỏi "vấn đề gốc là gì", bạn sẽ build sai thứ. Đây là tinh thần xuyên suốt cả bài.

Tình huống thực tế

Ví dụ 1 — Buổi kickoff: bóc tách yêu cầu mơ hồ thành mục tiêu đo được

BA tên Linh được giao dự án XYZ. Thay vì hỏi "chị muốn website có chức năng gì", Linh dùng kỹ thuật 5 Whys đã học để đào vấn đề:

• "Vì sao chị muốn làm website?" → "Vì bán qua Facebook mệt quá, nhân viên không quản nổi."
• "Không quản nổi cụ thể là ở khâu nào?" → "Chốt đơn trùng, hết hàng vẫn bán, đối soát tiền lâu."
• "Mỗi tháng thiệt hại bao nhiêu vì mấy lỗi đó?" → Sau khi cùng nhau ước tính: ~30 đơn hủy/tháng do hết hàng + ~15 giờ/tuần đối soát thủ công.

Đến đây, "làm website giống Shopee" đã biến thành ba mục tiêu kinh doanh đo được:

• Giảm đơn hủy do sai tồn kho từ 30 xuống dưới 5/tháng.
• Tự động đối soát thanh toán, giảm 15 giờ/tuần xuống dưới 3 giờ.
• Cho phép khách tự đặt hàng, giảm tải cho 6 nhân viên chốt đơn.

Bài học: Một câu nói mơ hồ của sếp, sau khi qua tay BA, trở thành ba success metric rõ ràng. Đây là nền tảng để sau này đo dự án thành công hay thất bại — và để cắt scope khi cần.

Ví dụ 2 — Workshop scope: chống "bệnh muốn làm hết mọi thứ"

Sau khi phỏng vấn, Linh tổ chức một requirements workshop nửa ngày với giám đốc, trưởng kho, trưởng nhóm chăm sóc khách hàng, và kế toán. Mỗi người mang theo một "danh sách mơ ước": giám đốc muốn có app loyalty tích điểm, trưởng kho muốn tích hợp luôn phần mềm kế toán MISA, kế toán muốn xuất hóa đơn điện tử tự động, CSKH muốn live chat AI.

Nếu nhận hết, dự án sẽ phình từ 3 tháng thành 12 tháng. Linh dùng kỹ thuật MoSCoW để phân loại ngay tại workshop, dán giấy note lên tường thành bốn cột:

• Must have: Catalog sản phẩm, giỏ hàng, đặt hàng, quản lý tồn kho real-time, tích hợp cổng thanh toán (VNPay/MoMo), trang quản trị đơn.
• Should have: Đồng bộ tồn kho với kênh Facebook/Zalo, báo cáo doanh thu cơ bản.
• Could have: Tích điểm loyalty, live chat.
• Won't have (phase 1): Tích hợp MISA, hóa đơn điện tử, live chat AI.

Bốn nhóm Won't-have không bị vứt đi — chúng được ghi vào "Product Backlog phase 2" trong Confluence để stakeholder yên tâm là không bị bỏ quên.

Bài học: Scope không phải do BA tự cắt, mà là dẫn dắt stakeholder cùng đồng thuận cắt. Khi mọi người tự tay dán món của mình vào cột "Won't have phase 1", họ sở hữu quyết định đó — và không quay lại trách bạn sau này.

Ví dụ 3 — Process flow phơi bày một requirement bị bỏ sót

Khi vẽ process flow cho luồng "Khách đặt hàng → Xác nhận → Đóng gói → Giao", Linh ngồi cùng trưởng kho và phát hiện một nhánh chưa ai nhắc tới trong các buổi phỏng vấn: xử lý đơn hoàn/đổi trả. Ở mô hình Facebook hiện tại, khách đổi trả qua inbox, nhân viên xử lý "linh hoạt" — không có quy trình.

Linh hỏi: "Mỗi tháng có bao nhiêu đơn đổi trả?" Trưởng kho trả lời khoảng 5-7%, tức ~90 đơn/tháng. Một con số đủ lớn để website bắt buộc phải có chức năng quản lý đổi trả, hoàn tiền, và cập nhật lại tồn kho khi hàng về. Nếu bỏ qua, sau khi launch, đội vận hành sẽ "vỡ trận" với hàng trăm ca đổi trả mỗi tháng mà hệ thống không hỗ trợ.

Bài học: Process flow không chỉ là tài liệu mô tả — nó là công cụ phát hiện requirement bị bỏ sót. Khi bạn buộc phải vẽ từng mũi tên, những nhánh "ai cũng làm nhưng không ai nói" sẽ tự lộ ra. Đây là lý do mô hình hóa quan trọng hơn phỏng vấn đơn thuần.

Hướng dẫn từng bước

Dưới đây là quy trình bạn có thể áp dụng cho bất kỳ case study tương tự, minh họa bằng XYZ:

Bước 1 — Lập bản đồ bối cảnh (context). Viết một trang tóm tắt: công ty làm gì, hiện trạng quy trình, con số chính (doanh thu, số đơn, số nhân sự), và "nỗi đau" được nêu ra. Với XYZ: bán hàng qua FB/Zalo, quản lý Excel, 1.500 đơn/tháng, đau ở tồn kho và đối soát.

Bước 2 — Xác định và phân loại stakeholder. Liệt kê: giám đốc (decision maker), trưởng kho, kế toán, CSKH (end user nội bộ), và khách hàng cuối (end user ngoài). Đánh dấu ai cần phỏng vấn sâu, ai chỉ cần thông báo.

Bước 3 — Đào vấn đề gốc trước khi nhận giải pháp. Dùng 5 Whys, biến "muốn làm website" thành các mục tiêu kinh doanh đo được. Đừng bao giờ bỏ qua bước này.

Bước 4 — Elicitation đa kênh. Kết hợp phỏng vấn 1-1 (chiều sâu), workshop nhóm (đồng thuận scope), và phân tích dữ liệu hiện có (mở file Excel của XYZ để xem cấu trúc đơn, danh mục sản phẩm, tần suất đổi trả — dữ liệu thật quý hơn lời kể).

Bước 5 — Mô hình hóa. Vẽ process flow cho các luồng chính: đặt hàng, quản lý tồn kho, đối soát thanh toán, đổi trả. Mỗi luồng giúp lộ ra requirement ẩn.

Bước 6 — Ưu tiên scope. Dùng MoSCoW. Chốt phase 1 gọn nhất có thể để launch sớm, đẩy phần còn lại sang backlog phase 2.

Bước 7 — Documentation. Viết User Story cho từng chức năng Must-have. Ví dụ: "Là một khách hàng, tôi muốn xem được số lượng tồn kho còn lại của sản phẩm, để tôi không đặt nhầm món đã hết hàng." Kèm acceptance criteria rõ ràng. Gom các story chính vào một PRD ngắn.

Bước 8 — Đưa vào Jira & playback. Tạo Epic ("Order Management", "Inventory", "Payment") và break thành story trong Jira. Sau đó họp playback với stakeholder: chiếu lại toàn bộ scope, process flow, và backlog để họ ký xác nhận (sign-off) trước khi dev bắt đầu.

Bước 9 — Bàn giao cho team. Walkthrough backlog với dev lead và designer, trả lời câu hỏi, và giữ vai trò "người gác cổng requirement" trong suốt sprint.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhận giải pháp thay vì vấn đề. Bắt tay làm "website giống Shopee" ngay lập tức là sai lầm phổ biến nhất. Mẹo: với mỗi yêu cầu, luôn hỏi thêm một câu "để làm gì?" cho đến khi chạm tới mục tiêu kinh doanh.

Lỗi 2 — Scope creep không kiểm soát. Gật đầu với mọi mong muốn của stakeholder. Mẹo: dùng MoSCoW công khai trong workshop, và luôn có một "kho phase 2" để cất những thứ chưa làm — vừa giữ scope gọn, vừa khiến stakeholder yên tâm.

Lỗi 3 — Bỏ qua dữ liệu hiện có. BA mới hay chỉ phỏng vấn rồi viết requirement theo lời kể. Nhưng file Excel của XYZ chứa sự thật: sản phẩm nào bán chạy, đơn nào hay đổi trả, cấu trúc dữ liệu thực tế. Mẹo: luôn xin "tài liệu/hệ thống đang dùng" và phân tích trước khi tin vào lời nói.

Lỗi 4 — Quên các "happy-path exception". Chỉ vẽ luồng thuận lợi, quên đổi trả, hủy đơn, hết hàng giữa chừng, thanh toán thất bại. Mẹo: với mỗi process flow, tự hỏi "nếu bước này thất bại thì sao?".

Lỗi 5 — Không playback trước khi code. Viết xong tài liệu rồi quăng cho dev. Mẹo: luôn họp playback và lấy sign-off bằng văn bản — nó bảo vệ bạn khi có tranh cãi "tôi đâu có yêu cầu cái này".

Mẹo vàng: Một BA giỏi để lại "dấu vết truy xuất" — mỗi user story đều nối ngược về được một mục tiêu kinh doanh ở Bước 3. Nếu một story không phục vụ mục tiêu nào, hãy nghi ngờ nó.

Bài tập thực hành

Hãy tự mình đóng vai BA cho XYZ và hoàn thành các nhiệm vụ sau (dành ~90 phút):

• Stakeholder map: Liệt kê tối thiểu 5 stakeholder của dự án XYZ, phân loại theo mức độ ảnh hưởng và quan tâm (Power/Interest grid). Ghi rõ bạn sẽ phỏng vấn ai trước.

• 5 Whys: Viết ra một chuỗi 5 Whys bắt đầu từ câu "Tôi muốn khách tự thanh toán online", và kết thúc bằng một mục tiêu kinh doanh đo được.

• MoSCoW: Cho danh sách 10 chức năng mong muốn (tự thêm vào danh sách trong bài), hãy phân loại Must/Should/Could/Won't và viết một câu lý do cho mỗi quyết định Won't-have.

• Process flow: Vẽ luồng "Khách đặt hàng và thanh toán online" cho XYZ, bao gồm ít nhất 2 nhánh exception (ví dụ: hết hàng, thanh toán thất bại).

• User Story + Acceptance Criteria: Viết 3 user story cho nhóm chức năng "Quản lý tồn kho", mỗi story kèm 2-3 acceptance criteria theo định dạng Given/When/Then.

• Thử thách nâng cao: Chuẩn bị dàn ý 1 trang cho buổi playback với giám đốc XYZ — bạn sẽ trình bày scope phase 1, lý do cắt phase 2, và các metric thành công như thế nào trong 15 phút?

Hãy lưu kết quả lại; ở bài Capstone cuối khóa bạn sẽ làm một mini project tương tự nhưng trong lĩnh vực ngân hàng, và quy trình bạn rèn ở đây sẽ tái sử dụng gần như nguyên vẹn.

Tóm tắt

• Bài thực hành này xâu chuỗi toàn bộ kiến thức 9 bài đầu thành một dòng chảy end-to-end: bối cảnh → stakeholder → đào vấn đề → elicitation → mô hình hóa → ưu tiên scope → documentation → playback → bàn giao.
• Khách hàng đến với bạn bằng giải pháp ("làm website giống Shopee"); việc của BA là tìm ra vấn đề gốc và biến nó thành mục tiêu kinh doanh đo được.
• 5 Whys giúp bóc tách yêu cầu mơ hồ; MoSCoW giúp kiểm soát scope creep một cách đồng thuận; Process flow giúp phát hiện requirement bị bỏ sót (như luồng đổi trả của XYZ).
• Luôn phân tích dữ liệu hiện có (file Excel, hệ thống đang dùng) — nó chứa sự thật mà lời kể không có.
• Đừng quên các nhánh exception (hết hàng, hủy đơn, thanh toán lỗi, đổi trả) và luôn playback + sign-off trước khi dev viết dòng code đầu tiên.
• Quy trình này lặp lại được cho mọi dự án. Khi bạn thành thạo nó với XYZ, bạn đã sẵn sàng cho bất kỳ case study thật nào ngoài kia.