PROCESS — Quy trình AS-IS / TO-BE — Giỏ hàng & Checkout (e-commerce)
|
|
| Version |
1.0 |
| Date |
2026-09-08 |
| Author |
BA (qua skill ba-2-analysis) |
| Status |
🟡 Draft |
| Approved by |
— |
| Profile |
screen · greenfield · standard (xem 00-index/PROFILE_e-commerce.md) |
| Source |
01-discovery/BRIEF_CartCheckout_v1.0.md · 01-discovery/RISK_CartCheckout_v1.0.md · 01-discovery/ELICITATION_CartCheckout_2026-09-08.md · e-commerce/docs/sections/06-luong-xu-ly.md §6.1.1, §6.3.1, §6.4 BR-01/BR-02/BR-15 (chỉ dùng làm tài liệu tham chiếu kỹ thuật, không chép nguyên văn thiết kế) · e-commerce/docs/sections/05-thiet-ke-du-lieu.md §5.2.3 (tham chiếu entity) |
| Scope |
Module Giỏ hàng & Checkout — RQ-001…RQ-004 (BRIEF_CartCheckout_v1.0.md) |
Change Log
| Version |
Date |
Người sửa |
Thay đổi |
CR |
| 1.0 |
2026-09-08 |
BA (qua skill ba-2-analysis) |
Bản đầu |
— |
⚠️ Ngoại lệ gate G1 — BRIEF_CartCheckout_v1.0.md tự chấm chưa đủ điều kiện ký chính
thức (3/6 tiêu chí G1 còn ☐: thiếu tên thật stakeholder, thiếu buổi làm việc trực tiếp,
KPI chưa có baseline số — xem mục "Tự chấm" cuối BRIEF). Tài liệu này được viết tiếp theo
xác nhận rõ ràng của người điều phối rằng vẫn muốn chạy GĐ2 trong khi chờ G1 ký chính
thức, cho mục đích đánh giá bộ skill BA. Xem DEC-02 ở 00-index/DECISION_e-commerce.md.
Toàn bộ nội dung dưới đây phải rà lại khi G1 được ký thật (đặc biệt phần A3–A5 và B3, vì
chúng dựa trên RISK/ASM chưa được PO xác nhận).
1. Phạm vi quy trình
|
|
| Tên quy trình |
Giỏ hàng đa seller → Checkout → Tách đơn theo seller → Thanh toán |
| Điểm bắt đầu |
Customer/Guest có ≥1 sản phẩm trong giỏ hàng và bấm "Đặt hàng" |
| Điểm kết thúc |
Đơn hàng cha (Order) và các đơn con theo seller (OrderSeller) đã được tạo, ở trạng thái pending_payment hoặc confirmed tuỳ phương thức thanh toán — bàn giao cho module Quản lý đơn hàng (FR-08/FR-19, ngoài phạm vi) |
| Tần suất |
Theo mỗi lượt checkout — chưa đo được (greenfield, chưa vận hành) |
| Khối lượng |
Chưa đo — quy mô mục tiêu "lớn" theo BRIEF §2 (hàng trăm nghìn–hàng triệu user, cao điểm hàng nghìn–chục nghìn concurrent mùa flash sale) |
| Vai trò tham gia |
Customer, Guest (không có vai trò nội bộ nào tham gia trực tiếp trong phạm vi RQ-001…RQ-004 — đây là luồng self-service) |
PHẦN A — AS-IS (hiện trạng)
0. Vì sao PHẦN A rút gọn còn A3–A5, và vì sao A3–A5 không mô tả "hiện trạng" theo nghĩa thông thường
Theo 00-index/PROFILE_e-commerce.md (LIFECYCLE = greenfield) và theo domain-profiles.md
§2, PHẦN A rút gọn còn A3 (điểm đau) · A4 (đường tắt) · A5 (ngoại lệ), bỏ A1/A2/A6. Lý do
bỏ A1/A2/A6: dự án là marketplace hoàn toàn mới, không có hệ thống hay quy trình thủ công
nào đang chạy để vẽ sơ đồ luồng/bảng bước cho việc "một khách mua từ nhiều seller trong một
giỏ hàng, hệ thống tự tách đơn" — xác nhận tại ELICITATION_CartCheckout_2026-09-08.md F7:
"Không có hệ thống cũ (ERP/kho/CRM) cần tích hợp hoặc migrate cho luồng giỏ hàng/checkout —
dự án hoàn toàn mới." Không có A1 (sơ đồ) thì cũng không có A2 (bảng bước) tương ứng để điền,
và A6 (hệ thống/dữ liệu đang dùng) không áp dụng vì chưa có hệ thống nào đang dùng.
🔴 Vì không có "hiện trạng" thật, A3–A5 dưới đây không phải điểm đau/đường tắt/ngoại lệ đã
quan sát được từ vận hành thật (không thể có, vì chưa vận hành). Thay vào đó, ba mục này
tổng hợp lại rủi ro và giả định đã ghi ở GĐ1 (RISK_CartCheckout_v1.0.md,
ELICITATION_CartCheckout_2026-09-08.md) dưới đúng hình thức "spec ẩn" mà A3–A5 được thiết kế
để bắt: chỗ nào TO-BE dễ bỏ sót nhất nếu không đối chiếu lại. Đây là cách diễn giải hợp lý
nhất của A3–A5 cho một luồng greenfield — không tự bịa thêm dữ liệu quan sát không có thật.
A3. Điểm đau (rủi ro tương đương — chưa có dữ liệu vận hành thật)
| ID |
Bước TO-BE liên quan |
Vấn đề dự kiến |
Tần suất |
Hậu quả đo được |
→ RQ |
| P1 |
B7 (xác nhận đơn COD) |
Giỏ hàng đa seller tách thành nhiều đơn COD độc lập; MVP chưa có giới hạn giá trị đơn COD (ASM-05, chưa xác minh) → khách có thể chỉ nhận một phần đơn, từ chối phần còn lại |
Chưa đo — RISK-01 đánh giá Khả năng: Cao, Tác động: Cao (🔴) |
Seller chịu phí vận chuyển hoàn hàng, tranh chấp seller–sàn hàng loạt ở quy mô lớn |
RQ-002, RQ-003 |
| P2 |
B8→D3 (chờ xác nhận thanh toán VNPay/Momo) |
Webhook xác nhận thanh toán chưa được xác minh khả thi gần thời gian thực (ASM-01) → đơn có thể bị trừ tiền nhưng hệ thống không nhận được xác nhận kịp thời |
Chưa đo — RISK-02 đánh giá Khả năng: Trung bình, Tác động: Cao (🔴) |
Đơn kẹt "chờ thanh toán" dù tiền đã được gateway ghi nhận, khiếu nại CSKH, sai lệch đối soát với Kế toán (STK-04) |
RQ-003 |
| P3 |
B3 (ước tính phí ship theo từng seller) |
Phí vận chuyển tính riêng cho từng đơn con theo seller có thể cao hơn đáng kể so với mua từ một seller |
Chưa đo — RISK-04 đánh giá Khả năng: Trung bình, Tác động: Trung bình (🟠) |
Khách bỏ giỏ hàng ở bước checkout, ảnh hưởng trực tiếp GOAL-01/GOAL-02 |
RQ-001, RQ-002 |
A4. Đường tắt dự kiến (suy luận — chưa có dữ liệu vận hành thật, đánh dấu rõ là giả định)
Vì chưa vận hành, không thể quan sát "người ta đang lách quy trình thế nào". Bảng dưới là suy
luận có nguồn (hành vi thị trường tương tự + rủi ro đã ghi ở GĐ1), không phải quan sát thật
— PO/Tech Lead cần xác nhận lại khi có dữ liệu soft-launch.
| # |
Ai làm |
Làm gì ngoài quy trình (dự đoán) |
Vì sao phải làm vậy |
Ẩn ý về yêu cầu |
| 1 |
Customer |
Đặt hàng riêng lẻ với từng seller qua kênh khác (mạng xã hội, điện thoại) thay vì dùng giỏ hàng đa seller |
Nếu tổng phí ship gộp hiển thị cao hoặc luồng checkout phức tạp, khách có thể quay lại cách mua cũ (nếu seller có kênh riêng) |
Cần hiển thị rõ, sớm phí ship theo từng seller trước khi khách cam kết đặt hàng (US-005), không để tới bước cuối mới lộ tổng chi phí thật |
| 2 |
CSKH (ngoài phạm vi module này, nhưng liên đới) |
Xác nhận thủ công qua điện thoại/email với khách khi đơn kẹt "chờ thanh toán" quá lâu (do RISK-02) |
Webhook thanh toán chưa được xác minh đáng tin cậy |
Module Thanh toán (GĐ3, có thể ngoài phạm vi US của module này) cần cơ chế đối soát bù tự động, không chỉ dựa vào webhook một lần — ghi nhận là phụ thuộc, xem IMPACT_CartCheckout_v1.0.md §1.5 |
A5. Ngoại lệ đã biết trước (từ tài liệu SAD, cần BA/PO xác nhận lại là spec chính thức của module này)
🔴 Các dòng dưới đây tham chiếu thiết kế kỹ thuật đã có ở
e-commerce/docs/sections/06-luong-xu-ly.md (tài liệu SAD, không phải quyết định BA/PO) — dùng
làm gợi ý ngoại lệ cần rà, không coi là spec đã chốt cho tới khi PO/Tech Lead xác nhận lại
trong phạm vi BA.
| # |
Ca ngoại lệ |
Tần suất |
Cách xử lý tham chiếu (SAD) |
Ai xử lý |
TO-BE của module này có xử lý? |
| E1 |
Không đủ tồn kho khi checkout (nhiều khách cùng mua sản phẩm sắp hết trong lúc flash sale) |
Chưa đo — dự kiến cao trong mùa flash sale (NFR-02) |
SAD §6.4 BR-02: giữ tồn kho (reserve) khi POST /checkout, trả lỗi nếu không đủ, yêu cầu điều chỉnh giỏ hàng |
Hệ thống |
✅ Có — US-004 (xem BR_CartCheckout_v1.0.md BR-CART-02) |
| E2 |
Giá/tồn kho hiển thị trong giỏ thay đổi giữa lúc thêm giỏ và lúc checkout |
Chưa đo (ASM-06, chưa xác minh) |
SAD chưa mô tả cơ chế khoá giá/tồn kho tạm thời (reservation) cho riêng trường hợp này ở mức UX |
Chưa xác định |
☐ Chưa xử lý — xem OQ-009 |
| E3 |
Không tạo được vận đơn qua GHN (timeout/lỗi) khi tính phí ship lúc checkout |
Chưa đo |
SAD §6.4 BR-15: fallback GHTK, nếu cả hai lỗi thì Ops xử lý thủ công |
Hệ thống/Ops |
➖ Ngoài phạm vi — BR-15 áp dụng ở bước tạo vận đơn sau khi đơn đã tồn tại (FR-26), không phải lúc ước tính phí ship trong checkout. Trong phạm vi module này, nếu GHN/GHTK không phản hồi lúc checkout thì chỉ ảnh hưởng tới việc hiển thị phí ước tính (xem ASM-02, chưa xác minh) |
| E4 |
Khách chọn thanh toán COD cho đơn giá trị lớn (không có giới hạn ở MVP theo ASM-05) |
Chưa đo |
Không có xử lý nào ở SAD — đây thuần là quyết định nghiệp vụ chưa chốt |
PO chưa chỉ định |
☐ Chưa xử lý — xem OQ-006 (đã mở từ GĐ1, nhắc lại vì chặn BR-CART-03 ở GĐ2) |
PHẦN B — TO-BE (đề xuất)
B1. Sơ đồ luồng
Đánh dấu 🆕 mọi bước vì không có AS-IS để so sánh (bỏ B4/B5 dạng "bước bị bỏ/bước cũ" —
xem giải thích ở §0 Phần A). ⚠️ P1'/P2' tham chiếu điểm đau P1/P2 ở A3.
B2. Bảng chi tiết từng bước
| # |
Bước |
Loại |
Ai làm |
Input |
Output |
Hệ thống |
⏱ Dự kiến |
US |
| B1 |
Xem giỏ hàng nhóm theo seller |
🆕 |
Customer/Guest |
Danh sách CartItem trong Cart |
Giỏ hàng hiển thị nhóm theo seller_id kèm tổng tiền từng nhóm |
Cart & Order Service (nội bộ) |
Đích NFR-01: phản hồi màn hình < 2 giây |
US-002 |
| B2 |
Chọn/nhập địa chỉ giao hàng |
🆕 |
Customer/Guest |
Địa chỉ đã lưu (Customer) hoặc nhập mới (Guest) |
Địa chỉ giao hàng gắn với phiên checkout |
Identity & Access Service (đọc customer_address, nếu có tài khoản) |
Chưa ước lượng — phụ thuộc UX GĐ3 |
US-005 |
| B3 |
Ước tính phí ship theo từng seller |
🆕 |
Hệ thống |
Địa chỉ giao hàng + danh sách seller trong giỏ |
Phí ship ước tính theo từng đơn con (nếu ASM-02 đúng) |
GHN/GHTK (bên ngoài, ASM-02 chưa xác minh) |
Chưa ước lượng — phụ thuộc SLA API GHN/GHTK |
US-005 |
| B4 |
Báo lỗi không đủ tồn kho |
🆕 |
Hệ thống |
Kết quả kiểm tra inventory_stock |
Thông báo lỗi, giữ nguyên giỏ hàng để khách điều chỉnh |
Catalog & Inventory Service |
Tức thời (đồng bộ, trong luồng checkout) |
US-004 |
| B5 |
Tách giỏ hàng thành đơn con theo seller |
🆕 |
Hệ thống |
Cart + CartItem đã nhóm theo seller_id |
Order (cha) + nhiều OrderSeller (con) + OrderItem |
Cart & Order Service (nội bộ) |
Đích NFR-01: hoàn tất checkout < 3 giây (cả B1–B5) |
US-004 |
| B6 |
Chọn phương thức thanh toán |
🆕 |
Customer/Guest |
Danh sách phương thức khả dụng (COD/VNPay/Momo) |
Phương thức đã chọn gắn với Order |
Cart & Order Service |
Chưa ước lượng |
US-007, US-008 |
| B7 |
Xác nhận đơn COD |
🆕 |
Hệ thống |
Order + phương thức = COD |
OrderSeller.status chuyển theo BR-CART-07/BR-CART-03 (chờ PO chốt giới hạn COD) |
Cart & Order Service |
Tức thời |
US-007 |
| B8 |
Chuyển hướng cổng thanh toán, chờ xác nhận |
🆕 |
Hệ thống + VNPay/Momo |
Order + phương thức = VNPay/Momo |
Redirect URL, sau đó webhook xác nhận |
Payment Service + VNPay/Momo (bên ngoài) |
Phụ thuộc SLA cổng thanh toán (ASM-01 chưa xác minh) |
US-008 |
| B9 |
Giữ đơn pending_payment, chờ đối soát bù |
⚠️ |
Hệ thống |
Không nhận được webhook đúng hạn |
Đơn ở trạng thái chờ, cần cơ chế đối soát bù (ngoài phạm vi thiết kế chi tiết US module này) |
Payment Service |
Chưa xác định — phụ thuộc RISK-02 |
Ghi nhận, không có US riêng trong module này |
Tổng thời gian dự kiến: B1→B5 (đến khi tạo đơn) phải đạt < 3 giây theo NFR-01; không có
AS-IS để so sánh (xem §0 Phần A).
B3. Đối chiếu điểm đau → cách xử lý
| Điểm đau |
Bước TO-BE xử lý |
Cách xử lý |
Hiệu quả kỳ vọng |
Nếu không xử lý: lý do |
P1 (COD bùng đơn một phần, RISK-01) |
B7 |
Chưa xử lý triệt để — BR-CART-03 (giới hạn giá trị đơn COD) đang chờ PO chốt (OQ-006, đã mở từ GĐ1). B7 chỉ tạo đơn theo phương thức đã chọn, chưa có bước chặn/giới hạn |
Nếu PO chốt giới hạn: giảm rủi ro seller chịu phí hoàn hàng |
Nếu PO không chốt giới hạn: rủi ro tồn tại nguyên vẹn trong TO-BE — đây là khoảng trống đã biết, không phải bỏ sót, ghi rõ trong IMPACT §0 |
P2 (webhook trễ, RISK-02) |
B9 |
Ghi nhận trạng thái chờ; cơ chế đối soát bù (reconciliation job) là đề xuất của GĐ1 (RISK-02), thuộc thiết kế chi tiết của module Thanh toán ở GĐ3, không phải một US của module Giỏ hàng & Checkout (RQ-001…004 không bao gồm vận hành đối soát) |
Giảm số đơn kẹt lâu, giảm khiếu nại CSKH |
Nếu không xây cơ chế đối soát bù ở GĐ3: đơn có thể kẹt vô thời hạn — ghi nhận là phụ thuộc bắt buộc, xem IMPACT §1.5 |
P3 (phí ship cao khiến bỏ giỏ, RISK-04) |
B3 |
Hiển thị phí ước tính sớm (ngay sau khi nhập địa chỉ, trước khi khách xác nhận thanh toán) để minh bạch hoá — không giải quyết triệt để việc phí cao, chỉ giảm bất ngờ |
Giảm tỷ lệ bỏ giỏ do "phí ẩn xuất hiện cuối cùng"; không giảm được tổng phí |
Việc giảm phí ship (VD trợ giá) là quyết định thương mại của PO, ngoài phạm vi BA — xem RISK-04 phương án đề xuất |
B4. Bước bị bỏ — ai làm thay
Không có — không có AS-IS Phần A1/A2 để so sánh (giải thích ở §0 Phần A, greenfield không có
quy trình cũ nào bị thay thế bởi module này).
B5. Bước mới — ai có thời gian làm
| Bước mới |
Ai làm |
Thêm bao nhiêu thời gian/ngày |
Đã hỏi người đó chưa |
| B1–B8 (toàn bộ luồng) |
Customer/Guest tự thao tác (self-service qua giao diện); không có vai trò nội bộ nào phải làm thêm việc thủ công trong phạm vi RQ-001…004 |
0 — không phát sinh việc thủ công cho nhân sự nội bộ, vì đây là luồng tự phục vụ hoàn toàn |
N/A |
| B9 (giữ đơn chờ đối soát) |
Nếu cần CSKH can thiệp thủ công (theo A4 mục 2) |
Chưa ước lượng — phụ thuộc tần suất webhook trễ thực tế (chưa đo) |
☐ Chưa hỏi — CSKH (STK ngoài phạm vi stakeholder module này) chưa được phỏng vấn |
B6. Thay đổi với người dùng
| Vai trò |
Trước |
Sau |
Cần đào tạo gì |
Mức kháng cự dự kiến |
| Customer/Guest |
Không có trải nghiệm nào (sản phẩm/thị trường hoàn toàn mới) |
Trải nghiệm mua từ nhiều seller trong một giỏ, một lần thanh toán |
Hướng dẫn UX tại chỗ (onboarding/tooltip) — chi tiết thuộc WF/UICONV ở GĐ3, ngoài phạm vi tài liệu này |
Thấp (không có thói quen cũ để phá vỡ) — nhưng cần đo thật ở soft-launch theo GOAL-01 |
2. Open Questions
| ID |
Câu hỏi |
Hỏi ai |
Từ ngày |
Chặn gì |
| OQ-006 |
(đã mở từ GĐ1, nhắc lại) Chính sách giới hạn giá trị đơn COD là gì? |
PO sàn, Kế toán đối soát |
2026-09-08 |
BR-CART-03, bước B7 |
| OQ-009 |
Khi giá/tồn kho thay đổi giữa lúc thêm giỏ và lúc checkout (ASM-06), hệ thống tự động cập nhật giá mới và thông báo, hay chặn checkout yêu cầu khách xác nhận lại? |
PO + Tech Lead |
2026-09-08 |
Bước B3/B5, AC của US-004/US-005 ở GĐ3 |
| OQ-010 |
Xác nhận khả thi kỹ thuật ASM-01 (webhook VNPay/Momo gần thời gian thực) |
Tech Lead |
2026-09-08 |
Bước B8/D3, BR-CART-06, US-008 |
3. Ngoài phạm vi
- Thiết kế màn hình chi tiết (bố cục, field) → GĐ3
SRS/WF
- Chi tiết business rule (công thức, ví dụ đúng/sai) →
BR_CartCheckout_v1.0.md
- Ma trận phân quyền →
RBAC_CartCheckout_v1.0.md
- Luồng sau khi đơn đã tạo (đóng gói, giao hàng, đổi trả, khiếu nại — FR-08, FR-09, FR-19,
FR-25, FR-26) → module Quản lý đơn hàng, chạy GĐ1/GĐ2 riêng
- Cơ chế đối soát bù thanh toán (bước B9) → thiết kế chi tiết ở GĐ3 của module Thanh toán,
không phải một US của module này
