Mở đầu — vì sao bài này quan trọng
Trong hành trình chuyển từ Developer sang BA, có một sự thật ít ai nói thẳng với bạn: kỹ năng phân tích của bạn chỉ đáng giá khi nó gắn vào một domain cụ thể. Một BA giỏi kỹ thuật nhưng không hiểu domain sẽ luôn phải chạy theo phía business để hỏi "cái này để làm gì", trong khi một BA hiểu domain có thể chủ động đề xuất giải pháp và nói cùng ngôn ngữ với stakeholder ngay từ buổi họp đầu tiên.
E-commerce (thương mại điện tử) là một trong những domain "dễ vào, khó thạo" nhất, và đặc biệt hấp dẫn với người có nền Developer. Vì sao? Vì hầu như tuyển dụng BA tại Việt Nam năm 2026 — từ Shopee, Tiki, Lazada, các công ty làm nền tảng cho Nhật/Mỹ, đến vô số startup retail-tech — đều cần người hiểu e-commerce. Thị trường thương mại điện tử Việt Nam đã vượt mốc 25 tỷ USD, và mỗi doanh nghiệp bán lẻ truyền thống đều đang số hóa. Nhu cầu BA am hiểu domain này rất lớn.
Lợi thế của bạn — người từng code — là cực lớn ở đây. E-commerce là domain có kiến trúc kỹ thuật phức tạp bậc nhất: hàng chục hệ thống tích hợp với nhau, xử lý concurrency khi flash sale, đồng bộ tồn kho real-time, thanh toán qua nhiều cổng. Bạn đã từng đụng vào những vấn đề này ở góc độ kỹ thuật. Bài học hôm nay giúp bạn tái diễn giải kiến thức đó thành ngôn ngữ business và bản đồ domain mà một BA cần nắm vững.
Khái niệm cốt lõi
Hãy nhìn e-commerce như một hệ thống phân lớp (layered architecture). Với tư duy của developer, bạn sẽ thấy quen thuộc — nhưng điểm khác biệt là mỗi lớp không chỉ là "module code" mà còn là một khu vực nghiệp vụ (business capability) với các stakeholder, quy tắc và KPI riêng.
Lớp 1 — Storefront (mặt tiền)
Đây là nơi khách hàng nhìn thấy: website, mobile app, và ngày càng nhiều là app trên nền tảng khác (mini-app trên Zalo, gian hàng trên Shopee/TikTok Shop). Với vai trò BA, bạn quan tâm đến các nghiệp vụ: hiển thị sản phẩm, tìm kiếm (search), gợi ý (recommendation), personalization, và conversion funnel — tức chuỗi bước từ lúc khách vào trang đến lúc bấm mua. Một chỉ số cốt lõi ở đây là conversion rate (tỷ lệ chuyển đổi) và bounce rate (tỷ lệ thoát).
Lớp 2 — Catalog (danh mục sản phẩm)
Đây là "trái tim dữ liệu" của e-commerce và là nơi nhiều BA mới vấp ngã vì không phân biệt được các khái niệm. Bạn cần nắm rõ:
- Product (sản phẩm): thực thể khái niệm, ví dụ "Áo thun cổ tròn Coolmate".
- SKU (Stock Keeping Unit): đơn vị tồn kho cụ thể, ví dụ "Áo thun cổ tròn Coolmate — Đen — Size L". Đây là thứ thực sự được đếm tồn và bán ra.
- Variant (biến thể): tổ hợp các thuộc tính (màu, size, dung lượng...) tạo ra các SKU khác nhau từ một product.
- Inventory (tồn kho): số lượng khả dụng của mỗi SKU, thường được quản lý theo từng kho (warehouse) và có khái niệm available-to-promise (số lượng thực sự có thể hứa bán sau khi trừ đơn đang giữ chỗ).
Lớp 3 — Cart & Checkout (giỏ hàng và thanh toán)
Đây là lớp chuyển đổi doanh thu. Các nghiệp vụ quan trọng: thêm/xóa giỏ hàng, áp dụng khuyến mãi (promotion, voucher, coupon), tính phí ship, tính thuế, chọn phương thức thanh toán, và đặc biệt là giữ chỗ tồn kho (inventory reservation) trong lúc khách đang thanh toán. Đây chính là chỗ dev-turned-BA tỏa sáng: bạn hiểu race condition, hiểu vì sao hai người cùng mua món hàng cuối cùng có thể gây oversell, và bạn có thể viết business rule chặt chẽ để xử lý tình huống đó.
Lớp 4 — Order Management (OMS — quản lý đơn hàng)
Sau khi checkout, đơn hàng đi vào vòng đời của nó: created → confirmed → picked → packed → shipped → delivered → completed, với các nhánh cancelled, returned, refunded. Đây là một state machine — khái niệm bạn đã quá quen. BA giỏi vẽ được sơ đồ trạng thái này và định nghĩa rõ điều kiện chuyển trạng thái cùng ai được phép kích hoạt (khách, CSKH, hệ thống tự động).
Lớp 5 — Payment (thanh toán)
Tích hợp với các cổng thanh toán: VNPay, MoMo, ZaloPay, thẻ quốc tế (qua Stripe/2C2P), COD (thanh toán khi nhận hàng — vẫn cực phổ biến ở Việt Nam). BA cần hiểu vòng đời giao dịch: authorize → capture → settle → refund, khái niệm idempotency (một request thanh toán lặp lại không được trừ tiền hai lần), và xử lý reconciliation (đối soát) với đối tác.
Lớp 6 — Fulfillment & Logistics (giao vận)
Kết nối với đơn vị vận chuyển (GHN, GHTK, Viettel Post, J&T), quản lý kho, in vận đơn, tracking. Nghiệp vụ: chọn đơn vị ship tối ưu theo chi phí/thời gian, split đơn khi hàng ở nhiều kho, xử lý giao thất bại và hoàn hàng.
Lớp 7 — Post-purchase (sau bán)
Đổi trả (returns), hoàn tiền (refund), đánh giá (review), chăm sóc khách hàng, loyalty/điểm thưởng. Đây là lớp giữ chân khách hàng và thường bị bỏ quên trong dự án MVP nhưng cực kỳ quan trọng về mặt vận hành.
Bao trùm tất cả là các hệ thống cắt ngang (cross-cutting): Promotion Engine (công cụ khuyến mãi), Pricing (định giá), CRM/CDP (dữ liệu khách hàng), Analytics và Search/Recommendation. Đây là những "microservice" mà một dev-turned-BA cần nhận diện vì chúng thường là nơi requirement phức tạp nhất.
Tình huống thực tế
Ví dụ 1 — Oversell trong flash sale tại một sàn TMĐT
Một sàn thương mại điện tử tầm trung ở TP.HCM (giả định là "MuaNhanh") tổ chức flash sale sản phẩm iPhone giá sốc, chỉ có 50 máy. Trong 3 giây đầu, hệ thống nhận 4.200 request. Kết quả: 137 khách checkout thành công dù chỉ có 50 máy — oversell. Bộ phận CSKH phải gọi hủy 87 đơn, khách phẫn nộ, lên mạng bóc phốt.
BA cũ (nền business thuần) viết requirement chỉ ghi: "Hệ thống phải trừ tồn kho khi khách đặt hàng." Quá mơ hồ. Khi một BA có nền developer vào dự án, người này viết lại business rule rất cụ thể: tồn kho phải được giữ chỗ (reserve) ngay tại bước thêm vào giỏ với TTL 10 phút, dùng cơ chế atomic decrement, và định nghĩa rõ hành vi khi hết chỗ giữ (hiển thị "Hết hàng" thay vì cho vào giỏ). BA còn bổ sung một non-functional requirement: hệ thống phải chịu được 5.000 request/giây ở bước reserve.
Bài học: Trong e-commerce, requirement về tồn kho và concurrency phải cực kỳ tường minh. Lợi thế dev giúp bạn biết nơi nào sẽ vỡ và viết rule bịt kín trước khi dev hỏi.
Ví dụ 2 — Promotion chồng chéo tại một retailer thời trang
Một chuỗi thời trang (giả định "Zenith Fashion") có 80 cửa hàng và một website. Marketing tung nhiều chương trình cùng lúc: giảm 20% toàn bộ, freeship đơn trên 500k, voucher sinh nhật 100k, và combo mua 2 tặng 1. Một khách thông minh áp cả bốn cùng lúc, và hóa đơn 600k biến thành... 90k. Doanh nghiệp lỗ nặng trên hàng nghìn đơn trước khi phát hiện.
Vấn đề gốc: không có promotion stacking rules (quy tắc chồng khuyến mãi). BA phụ trách đã ngồi lại với marketing và finance, xây một ma trận quy định rõ: khuyến mãi nào loại trừ nhau (mutually exclusive), thứ tự áp dụng (áp % trước hay trừ tiền cố định trước), và trần giảm giá tối đa (maximum discount cap) trên mỗi đơn là 40%. Đây là bài toán business rules thuần túy — tách logic khuyến mãi ra khỏi code cứng, cho phép marketing tự cấu hình mà không cần deploy.
Bài học: Promotion Engine là nơi requirement phức tạp và rủi ro tài chính cao nhất trong e-commerce. Một dev-turned-BA cần đặc biệt tỉnh táo về thứ tự áp dụng và điều kiện loại trừ — vì đây là logic mà chính bạn từng phải code và biết nó dễ sai đến mức nào.
Ví dụ 3 — Đồng bộ tồn kho omni-channel tại một nhà bán lẻ nội thất
Một nhà bán lẻ nội thất (giả định "NhaViet Home") bán đồng thời trên website riêng, Shopee, Lazada và 12 showroom vật lý. Cùng một chiếc ghế có tồn kho hiển thị khác nhau trên mỗi kênh vì mỗi kênh giữ một con số riêng, cập nhật chậm. Khách mua online chiếc ghế cuối cùng, nhưng showroom cũng vừa bán chiếc đó cho khách vãng lai — dẫn đến hủy đơn và mất uy tín.
BA vào cuộc, đề xuất mô hình single source of truth cho inventory: một hệ thống trung tâm quản lý tồn kho thực, các kênh chỉ đăng ký nhận (subscribe) và được đồng bộ qua event khi có thay đổi. BA vẽ sequence diagram thể hiện luồng: showroom bán → phát event stock.decremented → inventory service cập nhật → publish sang các kênh. Đồng thời định nghĩa cơ chế buffer stock (giữ lại một phần tồn không bán online) cho những SKU có độ trễ đồng bộ cao.
Bài học: Bán đa kênh (omni-channel) là xu hướng chủ đạo ở Việt Nam 2026, và bài toán đồng bộ tồn kho là "đặc sản" mà BA e-commerce nào cũng phải giải. Kỹ năng vẽ sequence diagram và tư duy event-driven của bạn là vũ khí trực tiếp.
Hướng dẫn từng bước
Khi bạn được giao phân tích một tính năng trong dự án e-commerce, hãy đi theo quy trình sau:
- Định vị tính năng trên bản đồ 7 lớp. Tính năng này thuộc lớp nào (Catalog? Checkout? Fulfillment?) và chạm vào những lớp nào khác? Ví dụ "áp voucher" nằm ở Cart nhưng phụ thuộc Promotion Engine và Pricing.
- Xác định các thực thể dữ liệu cốt lõi. Product, SKU, Order, Payment, Shipment... Vẽ nhanh một domain model để chắc chắn bạn và stakeholder dùng chung một ngôn ngữ. Đừng bao giờ nhầm Product với SKU.
- Vẽ vòng đời trạng thái (state machine). Với đơn hàng, thanh toán, hoàn trả — xác định các trạng thái, điều kiện chuyển và tác nhân kích hoạt. Đây là kỹ năng bạn đã có sẵn từ nền dev.
- Xác định business rules và edge case. Điều gì xảy ra khi hết hàng lúc checkout? Khi thanh toán thành công nhưng tồn kho đã bị người khác lấy? Khi khách hủy sau khi đã ship? Liệt kê thẳng thắn — đây là nơi bạn thêm giá trị lớn nhất.
- Xác định điểm tích hợp (integration points). Cổng thanh toán, đơn vị vận chuyển, ERP, kênh marketplace. Với mỗi điểm, làm rõ: đồng bộ hay bất đồng bộ, cơ chế retry, xử lý khi đối tác timeout.
- Gắn KPI business vào requirement. Conversion rate, cart abandonment rate (tỷ lệ bỏ giỏ), average order value (AOV), tỷ lệ giao thành công. Một tính năng tốt phải cải thiện một chỉ số cụ thể — hãy hỏi "tính năng này nhằm dịch chuyển KPI nào".
- Viết non-functional requirement cho tình huống tải cao. Flash sale, ngày đôi (11.11, 12.12), lễ Tết. Định nghĩa rõ throughput, latency mục tiêu.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm Product và SKU. Đây là lỗi kinh điển của BA e-commerce mới. Mẹo: mỗi khi viết "sản phẩm", tự hỏi "cái này đếm tồn theo màu/size không?". Nếu có, bạn đang nói về SKU.
Lỗi 2 — Coi thanh toán là một bước đơn giản. Thanh toán có nhiều trạng thái trung gian (authorized, pending, failed, refunded) và các callback bất đồng bộ. Đừng viết "khách thanh toán xong thì tạo đơn" — hãy làm rõ hành vi khi callback đến muộn hoặc không đến.
Lỗi 3 — Bỏ qua kịch bản hoàn/hủy. Team thường dồn sức cho luồng "mua thành công" (happy path) và quên đổi trả — vốn chiếm tỷ lệ lớn trong vận hành thực. Luôn dành thời gian cho reverse flow.
Lỗi 4 — Lạm dụng ngôn ngữ kỹ thuật với stakeholder business. Bạn có nền dev nên dễ nói "atomic transaction", "eventual consistency" với người làm marketing. Hãy dịch: "hệ thống đảm bảo không bán quá số hàng có". Giữ thuật ngữ kỹ thuật cho tài liệu dành cho dev.
Mẹo vàng: Tự đi mua một món hàng thật trên Shopee, Tiki, và một website nhỏ. Quan sát từng bước, từng email xác nhận, từng trạng thái đơn. Bạn sẽ học domain nhanh hơn đọc mười tài liệu. Đây là kỹ thuật elicitation qua trải nghiệm trực tiếp.
Bài tập thực hành
Bài tập 1 — Bản đồ domain. Chọn một website e-commerce Việt Nam bạn hay dùng (Tiki, Coolmate, Bách Hóa Xanh...). Vẽ lại kiến trúc theo 7 lớp ở trên, ghi chú tính năng bạn quan sát được ở mỗi lớp. Nêu ít nhất một điểm tích hợp bên thứ ba cho mỗi lớp phù hợp.
Bài tập 2 — State machine đơn hàng. Vẽ sơ đồ trạng thái đầy đủ cho một đơn hàng có thanh toán COD, bao gồm cả nhánh khách từ chối nhận hàng và hoàn về kho. Ghi rõ điều kiện chuyển và tác nhân cho mỗi mũi tên.
Bài tập 3 — Business rules khuyến mãi. Viết một bộ 6 business rule cho tình huống ở Ví dụ 2 (Zenith Fashion): định nghĩa khuyến mãi nào loại trừ nhau, thứ tự áp dụng, và trần giảm giá. Trình bày dưới dạng bảng dễ đọc cho đội marketing.
Bài tập 4 — Edge case checkout. Liệt kê tối thiểu 8 edge case ở bước checkout và với mỗi cái, đề xuất hành vi hệ thống mong muốn. Gợi ý: hết hàng giữa chừng, voucher hết hạn khi đang thanh toán, thanh toán timeout, khách bấm mua hai lần.
Tóm tắt
E-commerce là domain lý tưởng cho dev-turned-BA vì nó vừa giàu logic kỹ thuật vừa gắn chặt với business. Hãy ghi nhớ mô hình 7 lớp — Storefront, Catalog, Cart & Checkout, Order Management, Payment, Fulfillment, Post-purchase — cùng các hệ thống cắt ngang như Promotion Engine và Inventory. Ba vùng dễ sai và giá trị cao nhất mà bạn nên đầu tư nắm vững là: (1) mô hình dữ liệu Product/SKU/Variant/Inventory, (2) concurrency và giữ chỗ tồn kho trong flash sale, (3) logic khuyến mãi chồng chéo. Lợi thế dev của bạn — hiểu state machine, race condition, event-driven, idempotency — không chỉ giúp bạn viết requirement chặt hơn mà còn giúp bạn nói chuyện tự tin với cả team dev lẫn stakeholder business. Cách học nhanh nhất vẫn là trải nghiệm mua hàng thật và vẽ lại domain bằng chính con mắt phân tích của bạn.