Tài liệu Phân tích Nghiệp vụ (BA)
Tích hợp toàn hệ thống — Cơ sở đào tạo pha chế

1.Giới thiệu & phạm vi

1.1 Mục đích tài liệu

Tài liệu này tường minh hóa bản đặc tả tích hợp sơ khởi của khách hàng thành tài liệu phân tích nghiệp vụ đầy đủ: luồng dữ liệu, hợp đồng tích hợp (webhook/API), mô hình lưu trữ, quy tắc nghiệp vụ, báo cáo, yêu cầu phi chức năng. Mỗi điểm chưa rõ được gắn mã Q-xx (câu hỏi mở), A-xx (giả định) hoặc R-xx (rủi ro) để rà soát cùng khách hàng trong buổi làm việc tiếp theo.

1.2 Mục tiêu nghiệp vụ

• Một khách hàng — một hồ sơ duy nhất xuyên suốt mọi kênh (web, mạng xã hội, walk-in, cửa hàng online, tổng đài, thi cử).
• Sale mở hồ sơ khách trên dotB thấy được toàn cảnh 360°: tổng chi tiêu, hạng khách, lịch sử gọi, tình trạng thi — mà không bao giờ nhìn thấy PII đầy đủ (SĐT, email được che).
• Không phụ thuộc nhà cung cấp: dữ liệu gốc luôn nằm ở Dataverse do khách hàng sở hữu; thay bất kỳ hệ vệ tinh nào cũng không mất dữ liệu.
• Báo cáo quản trị (Power BI) lấy từ một nguồn số liệu duy nhất, nhất quán giữa mọi báo cáo.

1.3 Phạm vi

2.Bối cảnh & kiến trúc tổng thể

2.1 Chiều dữ liệu

2.2 Power Automate làm gì — trách nhiệm & danh sách flow cần xây

Power Automate không lưu dữ liệu — nó là tầng điều phối (orchestration). Mọi flow đều theo cùng một khung xử lý 6 bước:

Danh mục flow đề xuất (bám theo các luồng L1–L6, mục 5)

Lưu ý triển khai: danh mục trên là mức đề xuất để ước lượng khối lượng — số flow thực tế có thể gộp/tách khi thiết kế chi tiết. Các connector (Haravan, VoIP24H, App Exam, dotB) đều đứng tên tenant của khách hàng (mục 9). Chi phí license premium connector tính theo danh mục này — Q-15.

3.Các bên liên quan & hệ thống

3.1 Vai trò con người

3.2 Hệ thống

4.Mô hình định danh khách hàng (Identity Model)

Đây là nền móng của toàn bộ tích hợp: mọi bảng dữ liệu, mọi luồng, mọi kịch bản kiểm tra đều quy về mô hình khóa 3 lớp.

4.1 Ba lớp khóa

4.2 Định dạng CusID

CUST-<sequence>-<checksum>        ví dụ: CUST-1001-M

sequence : số tăng dần do Dataverse cấp
checksum : ≥1 ký tự = f(sequence + SecretSalt), thuật toán GIỮ KÍN
           → checksum hiển thị công khai, thuật toán + salt bảo mật
           → record từ hệ vệ tinh về SAI checksum ⇒ từ chối ghi + cờ fraud

4.3 Vòng đời định danh — 2 giai đoạn

4.4 Vòng đời trạng thái hồ sơ

Cần bổ sung: đặc tả gốc chỉ có 3 trạng thái Lead / Qualified / Customer. Đề xuất khách hàng cân nhắc thêm Inactive/Churned (ngưng tương tác) và Merged (hồ sơ bị gộp) để báo cáo chính xác — Q-20.

5.Luồng dữ liệu chi tiết

Mỗi luồng được mô tả theo mẫu: trigger → payload → xử lý → lưu trữ → hiển thị → xử lý lỗi. Payload dưới đây là kỳ vọng từ đặc tả gốc, cần xác minh với từng nhà cung cấp (mục 14).

5.1 Luồng L1 — Lead intake (Web form / Facebook / Zalo / TikTok / Walk-in)

Chi tiết kỹ thuật từng bước (JSON mẫu, cấu hình trigger, code WordPress CF7/Elementor, checklist test end-to-end): xem tài liệu riêng "Hướng dẫn triển khai Website Form → Power Automate → Dataverse → dotB" (07/07/2026).

5.2 Luồng L2 — Đơn hàng Haravan → total_spend & tier

5.3 Luồng L3 — Cuộc gọi VoIP24H → Call_Log → timeline dotB

5.4 Luồng L4 — Kết quả thi App Exam → Exam_Result → dotB

5.5 Luồng L5 — Đồng bộ hiển thị Dataverse → dotB (masked)

Đây là luồng "ra" duy nhất, gom mọi kết quả từ L1–L4:

• Nội dung đẩy: hồ sơ khách (tên, phone masked 09xx***567, email masked a***@gmail.com), total_spend, tier, tóm tắt lịch sử gọi, exam_status, lịch sử học legacy (kèm nhãn "dữ liệu cũ, chưa kiểm chứng").
• Cơ chế: Power Automate ghi vào trường tùy chỉnh + activity timeline của dotB qua API.
• Tính chất: các trường chỉ số là chỉ đọc với Sale; masking là bất biến, không có màn hình nào "mở khóa".

5.6 Luồng L6 — Onboarding dữ liệu cũ (Legacy, một lần trước go-live)

6.Mô hình dữ liệu — Schema Dataverse

6.1 Customer (bảng master — một dòng / một người)

6.2 Order (từ Haravan + Course — append)

Đề xuất bổ sung cột: order_status (paid/cancelled/refunded) và paid_amount để xử lý hủy/hoàn (Q-26); line_items chi tiết nếu cần báo cáo theo sản phẩm.

6.3 Call_Log (từ VoIP24H — immutable append)

call_id (PK) · CusID (FK) · sale_id · call_started_at · duration_sec · voip_result · direction (in/out) — đề xuất thêm recording_ref (con trỏ tới file ghi âm trong kho riêng) và who_hung_up nếu VoIP24H hỗ trợ.

6.4 Exam_Result (từ App Exam — append)

exam_id (PK) · CusID (FK) · course_code · exam_date · score · result (Pass/Fail) · attempt_no

6.5 Course_History (ghi danh + legacy)

Đặc tả gốc nhắc đến ở kịch bản khách cũ: CusID (FK) · course_code · năm học (ước lượng) · source (LEGACY_MIGRATION / hệ thống) · confidence (verified / unverified_legacy). Cần chuẩn hóa đầy đủ khi thiết kế chi tiết — hiện đặc tả gốc chưa định nghĩa bảng ghi danh khóa học cho luồng mới (Q-27).

6.6 Legacy_Records (số hóa một lần)

Dữ liệu 3 năm cũ, tra cứu theo tên + SĐT + khoảng thời gian. Cấu trúc chi tiết thuộc spec riêng "Số hóa dữ liệu cũ" — tối thiểu: legacy_id · full_name · phone · course · year · spend_amount · evidence (có/không hóa đơn) · digitized_by · digitized_at.

6.7 Merge_Audit (immutable)

6.8 Quan hệ tổng thể

7.Khớp trùng & hợp nhất hồ sơ (Identity Resolution)

Chạy tại Dataverse mỗi khi có bản ghi mới từ bất kỳ nguồn nào. Thứ tự ưu tiên 4 bước:

function resolveIdentity(new_record):
    # B1 — khớp phone chuẩn hóa (bỏ +84, khoảng trắng, về 10 số)
    match = Customer where normalized(phone) == normalized(new.phone)
    if match: return match.CusID

    # B2 — phone không khớp → thử email (lowercase)
    match = Customer where lower(email) == lower(new.email)
    if match: return match.CusID          # nghi phone sai → cờ PHONE_MISMATCH_REVIEW

    # B3 — khớp mờ: tên + một phần phone/email → hàng chờ Sale xác nhận
    candidates = fuzzyMatch(name, partial_phone, email)
    if candidates: return REVIEW_QUEUE(candidates)

    # B4 — không khớp → khách mới, cấp CusID mới
    return createNewCustomer(new_record)

7.1 Quy tắc cần làm rõ thêm với khách hàng

8.Kịch bản nghiệp vụ (Use case) — 5 câu hỏi kiểm tra của khách hàng

Khách hàng đưa 5 "câu hỏi kiểm tra" làm tiêu chí nghiệm thu. Mỗi kịch bản dưới đây gồm: tình huống → xử lý → tiêu chí chấp nhận (Acceptance Criteria).

8.1 UC-1 — Web lead + Walk-in, khách đọc SAI số điện thoại

Tình huống: khách để lead trên web (phone 0901234567). Đến trường, Sale nhập lại nhưng khách đọc nhầm 0901234568. Sale "nghi trùng" nhưng phone không khớp.

Ba cơ chế "sửa không cần thấy" (ưu tiên từ tốt nhất)

1. Khách tự xác thực (tốt nhất): gửi OTP/Zalo tới số khách vừa đọc → khách nhập OTP → hệ thống tự xác nhận và merge. Sale không chạm số nào.
2. Xác nhận bằng 4 số cuối: cảnh báo chỉ hiện "số hệ thống …567 · số vừa nhập …568 — xác nhận số nào đúng?". Đủ phân biệt, không đủ để chép mang đi.
3. Ghi đè mù (blind overwrite): màn hình luôn hiện 09xx***567; Sale gõ số MỚI vào ô cập nhật, không cần thấy số cũ; backend chuẩn hóa, đối chiếu.

Luồng xử lý

8.2 UC-2 — Tổng chi tiêu & thứ hạng (gồm Haravan)

Yêu cầu: màn hình dotB hiển thị tổng chi tiêu (khóa học + Haravan) và thứ hạng. Luồng chi tiết tại mục 5.2.

8.3 UC-3 — Lịch sử cuộc gọi

Yêu cầu: dotB hiển thị đã gọi bao nhiêu cuộc, thời điểm nào. Luồng chi tiết tại mục 5.3.

8.4 UC-4 — Tình trạng học viên (đậu/rớt từ App Exam)

Yêu cầu: dotB hiển thị tình trạng thi Pass / Fail / Chưa thi + điểm, ngày, lần thi. Luồng chi tiết tại mục 5.4.

8.5 UC-5 — Học viên cũ (3 năm trước, thời chưa có hệ thống) quay lại đăng ký

Cốt lõi: tách "lịch sử học" khỏi "tích lũy chi tiêu" — lịch sử học nạp ngay, chi tiêu cũ nạp theo chính sách.

Kịch bản 6 bước

Chính sách chi tiêu cũ — cần khách hàng QUYẾT ĐỊNH (Q-09)

9.Bảo mật, masking & phân quyền

9.1 Điểm bảo mật cần bổ sung ngoài đặc tả gốc

• Bảo mật webhook: xác thực chữ ký/secret của webhook Haravan, VoIP24H, App Exam (HMAC, IP allowlist) — chưa được đặc tả — Q-37.
• Ai được xem PII đầy đủ ở backend: danh sách vai trò admin Dataverse + cơ chế log truy cập — Q-13.
• Tuân thủ pháp lý: Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân — cần sự đồng ý của khách khi thu thập, quyền xóa dữ liệu; quy trình "khách yêu cầu xóa" chưa có — Q-38.
• OTP/Zalo: chọn nhà cung cấp OTP, chi phí/tin, phương án khi khách không dùng Zalo — Q-39.

10.Báo cáo & đo lường (Power BI — read-only trên Dataverse)

Mọi báo cáo lấy từ một nguồn Dataverse duy nhất → số liệu nhất quán giữa mọi báo cáo.

Cần chốt thêm: tần suất refresh Power BI, ai được cấp license xem (Q-14); dữ liệu trên Power BI có cần masked như dotB không (đề xuất: có, trừ nhóm được duyệt) — Q-44.

11.Vận hành: đồng bộ, đối soát & xử lý lỗi

11.1 Chế độ đồng bộ

• Near-real-time: mọi luồng webhook (L1–L5) chạy tức thời qua Power Automate.
• Đối soát đêm (nightly reconciliation): job so tổng Haravan vs tổng Order Dataverse phòng webhook rớt. Đề xuất mở rộng đối soát cho VoIP (đếm cuộc) và App Exam (đếm bài thi) — Q-45.

11.2 Ma trận xử lý lỗi (đề xuất — đặc tả gốc chưa có, cần khách xác nhận)

12.Yêu cầu phi chức năng (NFR) — đề xuất để khách chốt

13.Lộ trình triển khai & khối lượng ước tính & chi phí

13.1 Ước tính khối lượng công việc (man-day)

GĐ 0 — số hóa dữ liệu cũ (tính riêng, không phải việc dev): chưa ước tính được vì phụ thuộc khối lượng bản ghi (Q-30). Công thức tham khảo: nhập tay từ sổ ≈ 1–2 phút/bản ghi → 5.000 bản ghi ≈ 10–20 ngày công nhập liệu (nhân với số bản ghi thực tế); cộng thêm 3–5 MD dev để dựng bảng Legacy_Records + form nhập + kiểm tra chất lượng.

13.2 Thời gian dự kiến (lịch)

Đường găng (critical path): ① câu trả lời API của dotB (Q-01…Q-03) — nên gửi câu hỏi ngay tuần này, trước khi ký kế hoạch; ② GĐ 1 + GĐ 3 (nền định danh) chặn mọi giai đoạn sau; ③ số hóa dữ liệu cũ phải xong trước go-live để UC-5 chạy được.

14.Câu hỏi mở — cần khách hàng / nhà cung cấp trả lời CHỜ CHỐT

14.0 Kết quả xác minh dotB — cập nhật 07/07/2026 ĐÃ CÓ TRẢ LỜI

dotB đã trả lời checklist xác minh (bảng Q&A của nhà cung cấp, mục 35–42). Tóm tắt và hệ quả với thiết kế:

14.1 Nhóm A — Xác minh nhà cung cấp (chặn build, hỏi sớm nhất)

14.2 Nhóm B — Quyết định kinh doanh (khách hàng chốt)

14.3 Nhóm C — Chi tiết kỹ thuật / vận hành (chốt trong thiết kế chi tiết)

15.Giả định & Rủi ro

15.1 Giả định (Assumptions)

15.2 Rủi ro (Risks)

16.Thuật ngữ (Glossary)

Tài liệu do đội kỹ thuật soạn dựa trên "Đặc tả tích hợp v1.0" của khách hàng. Các mục đánh dấu Q-xx / A-xx / R-xx là điểm cần thống nhất trong buổi làm việc kế tiếp; sau khi chốt sẽ nâng phiên bản 1.0.