Mở đầu — vì sao bài này quan trọng
Nếu bạn đang chuyển từ Marketing sang BA, e-commerce gần như chắc chắn là một trong những domain bạn sẽ va vào sớm nhất. Lý do rất đơn giản: thị trường Việt Nam đang bùng nổ với Shopee, Lazada, Tiki, TikTok Shop, và hàng nghìn website bán hàng nhỏ chạy trên Haravan, Sapo, KiotViet. Hầu hết tin tuyển dụng BA Junior tại các công ty product hoặc agency đều ưu tiên người "hiểu e-commerce". Và đây là tin vui cho bạn: nền tảng Marketing cho bạn một lợi thế cực lớn ở domain này, bởi vì e-commerce chính là nơi marketing và công nghệ giao nhau.
Tuy nhiên, "hiểu e-commerce như một marketer" và "hiểu e-commerce như một BA" là hai chuyện khác nhau. Marketer nhìn vào conversion rate, CAC, ROAS. BA phải nhìn xuyên qua giao diện để thấy hệ thống bên dưới: catalog được tổ chức thế nào, cart và checkout vận hành ra sao, đơn hàng đi qua những trạng thái nào, tồn kho được trừ ở đâu, payment gateway tích hợp kiểu gì. Khi bạn viết requirement cho một tính năng e-commerce, bạn buộc phải biết tính năng đó "đụng" vào những module nào, nếu không bạn sẽ bỏ sót và gây ra sự cố production.
Bài này sẽ đưa bạn đi sâu vào kiến trúc một hệ thống e-commerce điển hình — đủ chi tiết để bạn tự tin ngồi vào một dự án thật, đọc hiểu hệ thống, và đặt đúng câu hỏi khi elicit requirement.
Khái niệm cốt lõi
Một hệ thống e-commerce, dù lớn hay nhỏ, thường được phân tách thành các tầng (architectural layers) sau. Hãy hình dung như các phòng ban trong một siêu thị: quầy trưng bày, kho hàng, quầy thanh toán, bộ phận giao hàng.
1. Storefront (mặt tiền)
Đây là tầng người mua nhìn thấy: website responsive, mobile web, native app (iOS/Android). Storefront chịu trách nhiệm hiển thị sản phẩm, tìm kiếm, lọc, và dẫn dắt người dùng qua hành trình mua. Với tư cách BA, bạn cần phân biệt rõ: cùng một logic nghiệp vụ nhưng phải hoạt động nhất quán trên cả ba kênh (web, mobile web, app). Một requirement như "ẩn sản phẩm hết hàng" phải được làm rõ là áp dụng cho kênh nào, vì app thường gọi API riêng và có thể cache khác với web.
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 bị rối nhất. Bạn phải nắm vững bốn khái niệm:
- Product: thực thể khái niệm, ví dụ "Áo thun Uniqlo Airism".
- SKU (Stock Keeping Unit): đơn vị tồn kho cụ thể, ví dụ "Áo thun Airism — màu Đen — size L". Một product có thể có nhiều SKU.
- Variant: tổ hợp các thuộc tính (màu, size, dung lượng...) tạo ra các SKU khác nhau. "Đen/L" và "Trắng/M" là hai variant.
- Inventory: số lượng tồn của từng SKU, thường gắn với kho (warehouse). Một SKU có thể có tồn ở nhiều kho khác nhau.
3. Cart (giỏ hàng)
Cart giữ tạm các SKU người dùng định mua. Điểm tinh tế mà BA hay bỏ qua: cart chưa trừ tồn kho. Việc một SKU nằm trong giỏ của bạn không có nghĩa nó được "giữ chỗ". Đây là nguồn gốc của tình huống "thêm vào giỏ thành công nhưng đến lúc thanh toán báo hết hàng". Bạn cần làm rõ chính sách: hệ thống kiểm tra tồn ở thời điểm nào — lúc add to cart, lúc vào checkout, hay lúc đặt hàng (place order)? Câu trả lời ảnh hưởng trực tiếp đến trải nghiệm và đến logic kỹ thuật.
4. Checkout & Order (thanh toán & đơn hàng)
Checkout là luồng thu thập địa chỉ giao hàng, phương thức vận chuyển, mã giảm giá, và phương thức thanh toán. Kết thúc checkout là khoảnh khắc tạo Order — và đây mới là lúc tồn kho thường được trừ (hoặc giữ chỗ — reserve).
Order có vòng đời trạng thái (order lifecycle/state machine), điển hình tại Việt Nam:
Pending (chờ xác nhận) → Confirmed (đã xác nhận) → Packed/Ready to ship (đã đóng gói) → Shipping (đang giao) → Delivered (đã giao) → Completed (hoàn tất). Các nhánh phụ: Cancelled (hủy), Returned/Refunded (trả/hoàn tiền). BA phải vẽ được sơ đồ trạng thái này và xác định: ai được phép chuyển trạng thái nào, điều kiện chuyển, và side-effect đi kèm (trừ kho, ghi nhận doanh thu, gửi thông báo).
5. Payment (thanh toán)
Tầng tích hợp với cổng thanh toán: VNPay, MoMo, ZaloPay, thẻ quốc tế qua Stripe/2C2P, và đặc biệt tại VN là COD (Cash on Delivery) — chiếm tỷ trọng rất lớn. Mỗi phương thức có luồng khác nhau. COD thì tiền chỉ về sau khi giao thành công, nên trạng thái thanh toán (payment_status) phải tách biệt với trạng thái đơn hàng (order_status). Đây là một phân tách quan trọng mà BA cần ghi rõ trong tài liệu.
6. Fulfillment & Logistics (hoàn tất đơn & vận chuyển)
Tầng kết nối với đơn vị vận chuyển: GHN, GHTK, Viettel Post, J&T, Ninja Van. Hệ thống tạo vận đơn (waybill), nhận webhook cập nhật trạng thái giao hàng, và đối soát (reconciliation) tiền COD. BA cần hiểu khái niệm webhook (đơn vị vận chuyển "gọi ngược" về hệ thống để báo cập nhật) vì rất nhiều requirement liên quan đến đồng bộ trạng thái nằm ở đây.
7. Promotion & Pricing (khuyến mãi & định giá)
Đây là sân nhà của marketer chuyển sang BA. Voucher, flash sale, combo, free-ship, tích điểm loyalty. Thử thách của BA là biến những campaign marketing thành business rules rõ ràng: điều kiện áp dụng (đơn tối thiểu, sản phẩm áp dụng), thứ tự áp dụng nhiều khuyến mãi (stacking), và giới hạn (mỗi user dùng mấy lần). Bài học riêng về business rules sẽ đào sâu, ở đây bạn chỉ cần biết promotion là một module độc lập, "cắm" vào cart/checkout.
Tình huống thực tế
Ví dụ 1: Tiki và bài toán "oversell" mùa cao điểm
Một sàn TMĐT lớn tại VN (tương tự Tiki) trong dịp 11/11 gặp tình trạng "oversell": nhiều khách đặt thành công cùng một SKU iPhone đang sale sốc, nhưng tồn thực tế chỉ còn 50 chiếc, trong khi hệ thống ghi nhận 80 đơn. Nguyên nhân: tồn kho chỉ được kiểm tra ở bước add-to-cart, không kiểm tra lại ở bước place order, và không có cơ chế "giữ chỗ" (reservation). Khi 80 người cùng bấm đặt trong vài giây, hệ thống cho qua hết.
BA của dự án sau sự cố đã phải đặc tả lại luồng: thêm bước reserve inventory ngay khi vào checkout với thời gian giữ chỗ 15 phút, dùng kiểm tra tồn theo cơ chế atomic (trừ tồn an toàn khi đồng thời nhiều người đặt). Bài học rút ra: với e-commerce, BA phải luôn hỏi "điều gì xảy ra khi nhiều người cùng thao tác một lúc?" — concurrency là vấn đề sống còn, không phải edge case hiếm gặp.
Ví dụ 2: Một shop trên Haravan và sự nhầm lẫn Product vs SKU
Một thương hiệu thời trang dùng nền tảng Haravan muốn làm tính năng "mua 2 tặng 1". BA đầu tiên viết rule ở cấp product: mua 2 sản phẩm "Áo sơ mi" tặng 1. Khi triển khai, khách mua 1 áo size S và 1 áo size M (hai SKU khác nhau của cùng product) thì hệ thống xử lý không nhất quán, có lúc tính, có lúc không, vì engine khuyến mãi đếm theo SKU. Kết quả là khách phàn nàn loạn trên fanpage.
BA phải viết lại requirement, làm rõ: điều kiện "2" được đếm theo số lượng SKU trong cùng nhóm product, và quà tặng được cấp ở cấp nào. Bài học: trước khi viết bất kỳ rule khuyến mãi nào, hãy xác định chính xác đơn vị tính là Product hay SKU. Đây đúng là loại lỗi mà marketer-mới-thành-BA dễ mắc vì quen tư duy "sản phẩm" chứ chưa quen tư duy "đơn vị tồn kho".
Ví dụ 3: Shopee-style — tách payment_status khỏi order_status với COD
Một sàn vận hành mô hình giống Shopee xử lý phần lớn đơn qua COD. Ban đầu hệ thống chỉ có một trường trạng thái duy nhất, nên khi đơn ở trạng thái "Đang giao" thì không biết tiền đã thu hay chưa, và bộ phận kế toán không đối soát được với GHN. Doanh thu bị ghi nhận sai thời điểm.
Đội BA tái thiết kế: tách thành hai chiều trạng thái độc lập — order_status (Pending → Shipping → Delivered) và payment_status (Unpaid → Paid → Refunded). Với COD, payment_status chỉ chuyển sang Paid khi nhận webhook "giao thành công" và tiền được đối soát từ đơn vị vận chuyển. Bài học: một đơn hàng có nhiều "chiều" trạng thái song song, và việc gộp chúng làm một là sai lầm thiết kế khiến hệ thống không mở rộng được.
Hướng dẫn từng bước
Khi bạn được giao một dự án (hoặc một tính năng) e-commerce, hãy theo trình tự sau để nắm domain và khai thác requirement:
Bước 1 — Vẽ bản đồ các tầng (layer map). Liệt kê 7 tầng ở trên và đánh dấu tính năng bạn đang làm "chạm" vào những tầng nào. Ví dụ tính năng "flash sale" chạm vào: Catalog (giá sale), Promotion (rule), Cart (áp giá), Inventory (giới hạn số lượng sale), Storefront (badge hiển thị).
Bước 2 — Dựng sơ đồ vòng đời đơn hàng (order state diagram). Đây là tài liệu nền tảng nhất. Vẽ tất cả trạng thái, các phép chuyển hợp lệ, điều kiện và side-effect. Đính kèm bảng phân quyền: actor nào (khách, seller, admin, hệ thống) được kích hoạt phép chuyển nào.
Bước 3 — Làm rõ thời điểm tác động tồn kho. Đặt rõ ba câu hỏi: kiểm tra tồn ở bước nào? Giữ chỗ (reserve) hay không? Trừ tồn thật (deduct) ở thời điểm nào? Trả tồn về (release) khi hủy/hết hạn giữ chỗ ra sao?
Bước 4 — Phân tách các chiều trạng thái. Tối thiểu tách order_status và payment_status. Với hàng có vận chuyển, cân nhắc thêm shipping_status và fulfillment_status.
Bước 5 — Xác định các điểm tích hợp (integration points). Liệt kê payment gateway, shipping partner, và cách giao tiếp (gọi API đồng bộ hay nhận webhook bất đồng bộ). Với mỗi tích hợp, hỏi: thất bại thì sao? Timeout thì sao? Có cơ chế retry/đối soát không?
Bước 6 — Đặc tả business rules của promotion riêng biệt. Đừng nhét rule khuyến mãi vào mô tả tính năng chung. Tách bảng rule: điều kiện, đơn vị tính (product/SKU), stacking, giới hạn theo user/đơn/thời gian.
Bước 7 — Rà soát edge case theo checklist. Hết hàng giữa chừng, hủy đơn sau khi đã trừ tồn, hoàn tiền một phần, đơn đa người bán (multi-seller tách thành nhiều đơn con), khách đổi địa chỉ sau khi đã đóng gói.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm Product với SKU. Như ví dụ Haravan ở trên. Mẹo: mỗi khi viết requirement có từ "sản phẩm", tự hỏi lại "ý mình là product khái niệm hay SKU cụ thể?". Khi không chắc, mặc định nghiêng về SKU vì giá, tồn, mã vạch đều ở cấp SKU.
Lỗi 2: Coi cart như đã giữ chỗ tồn kho. Cart không trừ tồn. Đừng hứa với stakeholder điều mà hệ thống không làm.
Lỗi 3: Gộp mọi trạng thái vào một trường. Tách order_status và payment_status ngay từ đầu, kẻo về sau phải migrate dữ liệu rất đau.
Lỗi 4: Quên đường về của tồn kho. Ai cũng nhớ trừ tồn khi đặt hàng, nhưng quên trả tồn khi đơn bị hủy, hết hạn giữ chỗ, hoặc thanh toán thất bại. Luôn đặc tả luồng "release".
Lỗi 5: Bỏ qua kịch bản thất bại của tích hợp. Payment gateway báo "thành công" nhưng webhook không về thì đơn ở trạng thái nào? Luôn có cơ chế đối soát (reconciliation) và truy vấn lại trạng thái (query transaction).
Mẹo tận dụng nền Marketing: Bạn vốn hiểu funnel mua hàng và hành vi người dùng — hãy dùng nó để phát hiện các "khoảng trống" trong luồng nghiệp vụ. Marketer giỏi biết người dùng sẽ bỏ giỏ ở đâu; BA giỏi biết hệ thống nên xử lý abandoned cart thế nào (gửi remarketing, giải phóng tồn giữ chỗ). Đây là cây cầu tự nhiên giữa hai vai trò.
Mẹo công cụ: Khi học một hệ thống lạ, hãy tự tạo một đơn hàng test đi hết luồng (place order → pay → ship → deliver) và quan sát từng thay đổi trạng thái trong admin. Trải nghiệm trực tiếp dạy bạn nhanh hơn mọi tài liệu.
Bài tập thực hành
- Vẽ sơ đồ trạng thái đơn hàng cho một sàn TMĐT VN có hỗ trợ cả COD và thanh toán online (VNPay). Tách rõ
order_statusvàpayment_status, chỉ ra với COD thì payment_status chuyển sang Paid ở thời điểm nào.
- Đặc tả luồng tồn kho cho tính năng flash sale giới hạn 100 suất: viết rõ thời điểm kiểm tra tồn, có giữ chỗ hay không, thời gian giữ chỗ, và điều kiện trả tồn về kho. Liệt kê 3 edge case bạn nghĩ tới.
- Phân tích một tính năng thật: vào Shopee hoặc Tiki, chọn một sản phẩm có nhiều biến thể (màu/size), và viết ra quan hệ Product–Variant–SKU bạn quan sát được, kèm nhận xét giá được gắn ở cấp nào.
- Viết business rule khuyến mãi: đặc tả rule "mua từ 500k freeship" với đầy đủ điều kiện, đơn vị tính, cách xử lý khi đơn có nhiều người bán, và giới hạn áp dụng.
Tóm tắt
E-commerce là một trong những domain "đáng tiền" nhất để một BA xuất thân Marketing đầu tư, vì nó vừa gần với hiểu biết sẵn có của bạn vừa mở ra cánh cửa vào product. Hãy ghi nhớ bảy tầng kiến trúc: Storefront, Catalog, Cart, Checkout/Order, Payment, Fulfillment/Logistics, và Promotion/Pricing. Bốn khái niệm nền tảng bạn không được nhầm lẫn là Product, SKU, Variant, Inventory. Hai trục tư duy quan trọng nhất khi đặc tả là vòng đời trạng thái đơn hàng (với nhiều chiều trạng thái song song như order_status và payment_status) và thời điểm tác động tồn kho (kiểm tra, giữ chỗ, trừ, trả về).
Các sự cố thực tế — oversell mùa sale, nhầm product/SKU trong khuyến mãi, gộp trạng thái với COD — đều bắt nguồn từ việc BA không hỏi đủ sâu về concurrency, đơn vị tính, và các chiều trạng thái. Nếu bạn nắm chắc những điều này và luôn truy vấn các kịch bản thất bại của tích hợp, bạn sẽ viết requirement e-commerce vững vàng hơn nhiều BA chỉ nhìn bề mặt giao diện. Và lợi thế Marketing của bạn — hiểu funnel, hiểu hành vi mua — chính là thứ giúp bạn phát hiện những khoảng trống nghiệp vụ mà người thuần kỹ thuật dễ bỏ qua.