Asia Business Builders — Merchant Banking Kiến trúc SIXDO Data Hub Trình BOD 23/09 · cập nhật 25/09/2026

SIXDO × Asia Business Builders · 23/09/2026 · số đo cập nhật 25/09/2026

Nền dữ liệu làm trung tâm

Một kho dùng chung, nhiều bên tiêu thụ — đã chạy thật, và giới hạn của nó ở đâu

Dữ liệu bán hàng của SIXDO mỗi đêm tự chảy từ hệ thống nguồn vào một kho dùng chung, được kiểm chất lượng, rồi phục vụ báo cáo. Tài liệu này giải thích cái đã mua được, cái chưa có, và hai hạn chót đang chạy.

2,0trđơn hàng trong kho
5,15trdòng hàng bán
13nguồn dữ liệu đã nạp
0cửa sổ nạp lỗi

Phần 01

Hai đồng hồ đang chạy — cả hai đều không nằm trong tay đội dự án

Đặt ngay đầu tài liệu vì mọi thứ phía sau phụ thuộc vào hai việc này.


15ngày (tính từ 25/09) tới khi chứng chỉ bảo mật của hệ nguồn hết hạn — 10/10/2026
~1tháng tới khi máy được bàn giao sang máy chủ

Chứng chỉ bảo mật hết hạn 10/10/2026

Hết hạn là luồng nạp dữ liệu dừng hẳn. Kho vẫn phục vụ được số đã có, nhưng không có gì mới. Đội dự án không tắt kiểm chứng chỉ để lách trong bất kỳ trường hợp nào — làm vậy là mở đường cho việc giả mạo máy chủ, và đó là loại rủi ro không đáng đổi lấy vài ngày dữ liệu.

Việc cần: phòng CNTT xác nhận ngày gia hạn bằng văn bản. Đây là một email, và nó đang là việc chưa làm. Đọc lại chứng chỉ ngày 25/09 (có kiểm chứng chỉ): vẫn hết hạn 10/10/2026 — chưa được gia hạn.

Bàn giao sang máy chủ

Hệ thống đang chạy trên một máy cá nhân, và tác vụ nền hiện chỉ chạy khi có người đăng nhập. Trên máy chủ phải đổi cách chạy và chứng minh nó sống sót sau một lần khởi động lại thật — không phải bằng đọc cấu hình, mà bằng quan sát một lần chạy.

Đã tiến được một bước (23/09): kho tự bật lại sau khi máy khởi động, và bản sao lưu đầu tiên đã chạy được. Chưa được: máy vẫn ngủ qua đêm — hai đêm liền lượt đồng bộ 01:00 bị lỡ và chỉ chạy bù khi máy thức (05:55 ngày 24/09, 02:04 ngày 25/09).

Hai hạn chót này rơi vào cùng một khoảng thời gian, và cả hai hiện chưa có ngày do người chịu trách nhiệm xác nhận.

Phần 02

Kiến trúc trong một hình

Nguyên tắc nền: một kho dùng chung ở giữa. Hệ nguồn chỉ nói chuyện với kho; mọi thứ khác — báo cáo, bản tin, chatbot, và sau này là các ứng dụng vệ tinh — đều đọc từ kho, không ai nối thẳng vào hệ bán hàng.


Luồng dữ liệu SIXDO Data Hub Hệ nguồn FAST đi một chiều qua lớp nạp vào kho Postgres gồm bốn tầng, rồi phục vụ ba bên tiêu thụ. FAST ERP Hệ bán hàng · gốc 94 cửa hàng · 12 kênh CHỈ ĐỌC · một chiều đêm Lớp nạp chạy lại không nhân đôi dữ liệu 01:00 mỗi đêm Kho dùng chung PostgreSQL · chỉ nghe nội bộ máy Dữ liệu thô nguyên văn từ nguồn, không sửa Lớp làm sạch chuẩn hoá mã, kiểu dữ liệu Lớp phục vụ báo cáo định nghĩa doanh thu nằm ở đây Cổng chất lượng 20 cổng · 3 đang đỏ có chủ đích Báo cáo Power BI 5 trang · 52 biểu đồ chạy 100% trong máy Bản tin Teams 07:00 · 3 thẻ vào 3 kênh chỉ số tổng hợp Chatbot · CDP · ứng dụng chatbot: có plan, chưa dựng không nối thẳng vào hệ nguồn Ranh giới dữ liệu cá nhân — giữ bằng cấu trúc quyền, không bằng lời dặn Báo cáo trên máy này đọc bằng một tài khoản THẤY dữ liệu cá nhân. Bản tin Teams và chatbot đọc bằng tài khoản KHÁC, không thấy tên, SĐT, email khách — cơ sở dữ liệu từ chối, không phải phần mềm tự kiềm chế.

Vì sao kiến trúc này quan trọng hơn bản thân cái dashboard: khi kho đứng ở giữa, thêm một bên tiêu thụ mới — một chatbot, một ứng dụng chăm sóc khách hàng — không phải xin quyền vào hệ bán hàng lần nữa, không làm tăng tải cho 94 cửa hàng, và không tạo thêm một định nghĩa "doanh thu" thứ hai. Đó là thứ đang được mua ở giai đoạn này.

Phụ lục 1 · Kiến trúc Bản tin Teams — dành cho đội kỹ thuật: bản tin chạy thế nào, quyết định gửi ra sao, và khi hỏng thì kênh nhìn thấy gì. Phụ lục cũng làm rõ hai câu của trang này về bản tin, ở mục 3.4 và 3.5. Mở phụ lục →

Phụ lục 2 · Kiến trúc Chatbot doanh số — chatbot của mốc P2.10, đã dựng và nghiệm thu (cập nhật 08/10): hỏi ở đâu, một câu hỏi đi qua NetBird tới kho trên PC, chatbot thấy gì và cái gì rời máy, mười một phép nghiệm thu. Chatbot đọc dữ liệu từng dòng (người dùng chọn 25/09, hai người dùng), còn tên, SĐT, email khách vẫn bị cơ sở dữ liệu chặn. Mở phụ lục 2 →

Phụ lục 3 · Các vai trong Postgres — vì sao cơ sở dữ liệu có 19 vai mà chỉ 5 là của dự án: vai nào được ghi, vai nào chỉ đọc số, vai nào thấy tên và số điện thoại khách, chatbot thấy gì, mật khẩu từng vai nằm đâu và lộ thì mất gì. Đo ngày 26/09/2026, sau khi tạo vai của chatbot. Mở phụ lục 3 →

Phụ lục 4 · Kiến trúc dbt đang chạy — lượt đồng bộ đêm 01:00 chạy thế nào: đọc FAST, dựng lại 46 model dbt từ đầu, kiểm rồi báo sức khoẻ; thời gian đo được 18–26/09; mỗi ngày chứng từ chỉ được đọc lại hai lần; và kết quả so lại 90 ngày với FAST. Đo ngày 26/09/2026. Mở phụ lục 4 →

Phụ lục 5 · Kênh bán & doanh thu KPI — vì sao bản tin nhặt nhầm POS và ECOM (hub chia theo nguồn bill, FAST chia theo cửa hàng), quy tắc mới người dùng chốt ngày 26/09: kho ECOM là online, miền Bắc / Nam theo mã cửa hàng, bỏ phí ship, doanh thu chưa VAT; và phép đối soát với báo cáo FAST 01–25/09. Mở phụ lục 5 →

Phụ lục 6 · Sổ câu hỏi chatbot doanh số — 44 câu của phiếu bước 5.2 mà người dùng đã hỏi chatbot ngày 27/09/2026, kèm bảng chatbot đã đọc và kết quả chấm từng câu; thêm 40 câu mở rộng theo các chiều phân tích hub có, chia 5 nhóm và 4 hạng khó, nhấn vào các câu phải nối nhiều bảng. Dùng để huấn luyện CEO và làm từ điển hỏi cho người dùng kinh doanh. Mở phụ lục 6 →

Phụ lục 7 · Kiến trúc kho dùng chung — mở "kho dùng chung ở giữa" ra thành tám lớp, từ FAST tới người đọc: nguồn, nạp, thô, làm sạch, phục vụ, chất lượng, quyền, bên tiêu thụ. Mỗi lớp chứa gì, ai ghi, ai đọc, lớn bao nhiêu, hỏng thì thấy gì; cộng máy, lịch và đường code bao quanh. Đo trên kho PROD ở PC ngày 08/10/2026. Mở phụ lục 7 →

Phần 03

Năm thứ đã mua được

Không phải tính năng nhìn thấy trên màn hình — là những thứ quyết định số liệu có tin được không. Mỗi cái nói bằng ngôn ngữ nghiệp vụ trước, số đo sau.

3.1Chạy lại không nhân đôi
3.2Không âm thầm mất một ngày doanh thu
3.3Kết nối nguồn kiểm nghiêm
3.4Dữ liệu cá nhân chặn ở tầng dưới cùng
3.5Một định nghĩa doanh thu duy nhất

Phần 03 · chi tiết

Từng cái, và điều gì hỏng nếu không có nó


3.1 · Nạp lại cùng một ngày bao nhiêu lần cũng ra cùng một kết quả

Nếu không có: mỗi lần chạy lại sau sự cố sẽ cộng thêm doanh thu ảo. Sau vài lần khắc phục, không ai còn biết con số nào thật.

Đo được: hệ thống cố ý nạp chồng hai ngày mỗi đêm để bắt các chứng từ đóng muộn — và số đơn vẫn bằng đúng số đơn không trùng lặp. Tính chất này được kiểm tự động mỗi đêm, không phải tin vào thiết kế.

3.2 · Nguồn trả thiếu thì hệ thống báo động, chứ không lặng lẽ xoá

Hệ nguồn có thể rút lại một chứng từ đã phát hành, hoặc phát hành lại nó với số mới. Kho phải phản ánh đúng — nhưng một lần đọc bị cụt cũng trông giống hệt như "cả ngày hôm đó bị rút".

Chốt an toàn: nếu một ngày sắp bị đánh dấu rút quá 10% và quá 20 đơn, hệ thống không đánh dấu gì cả và báo động. Nếu không có chốt này, một lần mạng chập có thể xoá một ngày doanh thu khỏi báo cáo mà không ai biết — và tuần sau không còn cách nào truy ngược.

3.3 · Kết nối tới hệ nguồn kiểm chứng chỉ nghiêm, và không có đường tắt

Bắt buộc mã hoá, bắt buộc đúng tên máy chủ, và có thể ghim đúng một chứng chỉ cụ thể. Ghim sai thì ngắt hẳn và không thử lại — coi là sự cố an ninh, không phải trục trặc mạng.

Hệ quả phải chấp nhận: khi chứng chỉ hết hạn ngày 10/10, luồng nạp sẽ dừng. Đó là lựa chọn có chủ đích, không phải thiếu sót.

3.4 · Dữ liệu cá nhân chặn ở tầng cơ sở dữ liệu, không phải ở lời dặn

Kho giữ thông tin cá nhân thật của 385.833 khách hàng. Ranh giới được dựng bằng ba tài khoản riêng: một tài khoản cho báo cáo trên máy này (thấy), một tài khoản cho mọi thứ có thể gửi dữ liệu ra ngoài (không thấy), và một tài khoản trung gian không ai đăng nhập được.

Vì sao phải là cấu trúc: nếu chỉ dựa vào lời dặn "đừng truy vấn bảng khách", thì một câu hỏi vô hại như "cho xem 20 khách mua nhiều nhất" sẽ đẩy 20 họ tên thật ra một dịch vụ bên ngoài, và không thu hồi được. Với cách hiện tại, cơ sở dữ liệu từ chối trước khi điều đó kịp xảy ra.

Đã chứng minh bằng đăng nhập thật, không phải bằng đọc bảng phân quyền — vì hàm kiểm quyền của hệ quản trị có thể trả "được phép" trong khi thực tế không đọc được.

Cập nhật 25/09 — chatbot (mốc P2.10, chưa dựng): người dùng chọn cho chatbot đọc cùng vùng với bản tin, tức dữ liệu từng dòng, vì chỉ có hai người dùng. Tên, SĐT, email, địa chỉ khách vẫn bị chặn như trên. Cái giá phải nói rõ: câu "20 khách mua nhiều nhất" khi đó trả về 20 mã khách kèm phường và hạng thẻ, và các dòng đó đi lên dịch vụ AI. Chi tiết ở Phụ lục 2.

3.5 · Một định nghĩa "doanh thu", không phải mỗi công cụ một kiểu

Mọi phép tính nằm ở lớp phục vụ báo cáo trong kho. Power BI và bản tin Teams không tự tính lại — chúng đọc cùng một định nghĩa. Đã đối chiếu khớp tới từng chữ số trên mười chỉ tiêu (22/09), và bản tin mới 3 thẻ khớp bản cũ trên 38 con số ở 5 kỳ (25/09).

Nếu không có luật này: dashboard nói một số, bản tin nói số khác, và cuộc họp chuyển từ bàn về kinh doanh sang bàn xem số nào đúng.

Phần 04

Một cổng chất lượng cố tình để đỏ

Trong 20 cổng chặn (12 cổng chất lượng, 5 cổng đồng bộ, 3 cổng của lớp bản tin mới), có ba cổng đang đỏ — cả ba thuộc nhóm chất lượng. Đây là điều nên biết trước khi ai đó nhìn thấy nó trên báo cáo và tưởng hệ thống hỏng.


Chuyện gì đang xảy ra, nói bằng ngôn ngữ nghiệp vụ

Từ tháng 9/2025, các cửa hàng bắt đầu bán thẻ trả trước: khách nạp tiền vào thẻ, rồi dùng thẻ mua hàng. Khi khách tiêu thẻ, chứng từ ghi hàng xuất ở giá 0đ còn phần thanh toán ghi bằng thẻ.

Cổng đối chiếu của hệ thống so tiền của dòng hàng với tiền đã thu. Với nhóm này hai vế lệch nhau — 755 chứng từ, 6.426.646.640đ (≈6,43 tỷ), 100% qua cửa hàng, bắt đầu từ 18/09/2025. (Đo 25/09/2026, dữ liệu tới 24/09 — con số này lớn dần mỗi đêm; ngày 23/09 là 751 chứng từ / 6,38 tỷ. Luôn đọc kèm ngày đo.)

CổngĐo đượcNghĩa là
Lệch theo tháng12 / 72 tháng vượt ngưỡngCổng chặn — đỏ
Lệch theo cửa hàng11 / 97 cửa hàng vượt ngưỡngCổng chặn — đỏ
Cùng phép đo, bỏ riêng nhóm thẻ trả trước ra0 / 72 tháng · 0 / 97 cửa hàngPhần còn lại sạch hoàn toàn

Hai dòng cuối cùng nói lên toàn bộ vấn đề: nhóm thẻ trả trước giải thích 100% số lần vượt ngưỡng. Kế toán đã xác nhận doanh thu được ghi nhận lúc khách nạp thẻ, ở một phân hệ mà kho không đọc tới — nên chênh lệch này là do phạm vi dữ liệu, không phải do đo sai.

Vì sao không "sửa cho xanh"

Có ba cách làm nó xanh trong mười phút: nới ngưỡng, đổi mẫu số, hoặc lọc bớt dữ liệu trong báo cáo. Cả ba đều bị cấm — vì cả ba đều biến một phát hiện nghiệp vụ thật thành một con số đẹp.
Thay vào đó, hệ thống thêm chỉ số tham chiếu tách riêng nhóm thẻ trả trước — để thấy phần còn lại sạch — mà giữ nguyên cổng chặn. Cổng vẫn đỏ, và cái đỏ đó được in thẳng lên báo cáo.
Còn một câu chưa ai trả lời: voucher, thẻ quà tặng và điểm tích luỹ có cùng cơ chế này không. Nếu có, con số sẽ lớn hơn.
Mới (24–25/09): đối soát kho với báo cáo của hệ nguồn tháng 1–6/2026 cho thấy tiền nạp thẻ không xuất hiện ở cả hai phía. Đề nghị hỏi lại kế toán: doanh thu lúc nạp thẻ nằm ở phân hệ nào, và có xuất ra được không.

Một cổng đỏ thứ ba, và nó là loại khác: một cổng đếm đang đỏ vì lý do kỹ thuật có chủ đích (kho thêm các dòng tổng hợp cho những mã khách không có trong danh mục). Rủi ro thật nằm ở đây: một cổng đỏ vĩnh viễn sẽ thành "đỏ quen" — và ngày nó đỏ vì một lý do thật, sẽ không ai nhận ra. Đây là việc phải xử lý trước bàn giao.

Phần 05

Cái nền này chưa có

Viết ra để không ai kỳ vọng nhầm. Hai loại: thứ nguồn không trả về (không sửa được bằng công sức), và thứ chưa dựng (sửa được, cần thời gian).


Nguồn không có — đã chứng minh bằng đo

Đo trực tiếp dữ liệu thô: hệ nguồn trả về 14 trường ở đầu chứng từ và 7 trường ở mỗi dòng hàng. Trong 7 trường đó không có giá vốn.

Ban lãnh đạo thường hỏiDashboard có?Vì sao
Biên lợi nhuận, giá vốnKhôngNguồn không trả về trường giá vốn
Tồn kho, tỉ lệ bán hếtKhôngKhông endpoint nào trả tồn
Phần trăm đạt chỉ tiêuKhôngChỉ tiêu là số kế hoạch — không tồn tại trong hệ ERP, và sẽ mãi là dữ liệu do người nhập
Cây tổ chức vùng miềnKhôngDanh mục chỉ trả 94 cửa hàng bán lẻ, không có cấp trên
CouponKhôngChưa có trong kho
Sổ điểm tích luỹMột phầnĐính chính 25/09: bản trước ghi "nguồn không trả về" — sai. Điểm có trong dữ liệu nguồn và trong hồ sơ khách (97.876 khách định danh có điểm tích luỹ lớn hơn 0, đo 23/09), nhưng chưa được dựng thành sổ điểm. Điểm có phải một khoản phải trả như thẻ trả trước không là câu hỏi cho kế toán

Đường đi tiếp rẻ nhất: xin phòng CNTT xuất danh mục bảng và cột của hệ nguồn — vài MB, không chứa dữ liệu cá nhân, chi phí gần bằng không. Không có danh mục đó thì mọi yêu cầu gửi nhà cung cấp đều là đoán tên bảng.

Chưa dựng — và đây là thứ quyết định có sang giai đoạn sau được không

ThiếuHệ quả cụ thể
Giám sát chưa nhìn thấy đúng những kiểu hỏng đã xảy raCó ba điểm mù độc lập trong cùng một bộ canh gác, cả ba đã đo, chưa cái nào được vá. Dự án đã ghi nhận 5 lần "báo xanh khi đang hỏng". Thêm người tiêu thụ vào một đường ống như vậy là nhân rộng vùng ảnh hưởng
Tầng phục vụ mới có một phầnLớp báo cáo là một khung nhìn tính lại mỗi lần đọc trên 5,15 triệu dòng, không có chỉ mục nào (đo lại 25/09). Bản tin cũ mất 14,2 giây và tràn ~890 MB ra đĩa với một người đọc. Từ 24/09 đã có lớp tổng hợp đầu tiên cho bản tin: bản tin mới chạy 2,8–4,3 giây. Nhưng chatbot (nếu dựng theo đường A) sẽ đọc thẳng khung nhìn lớn
Định danh khách chưa giải quyết xongCòn khoảng 5.800 mã khách chưa rõ bản chất, 35 mã trùng nhau do hoa/thường, và 5 mã kênh chưa có tên hiển thị — trong đó một mã chiếm 7,4% số đơn. Thêm: một tài khoản gộp của sàn Shopee đang được tính là "khách định danh" — tách nó ra thì tỉ trọng doanh thu từ khách định danh toàn thời gian đi từ 90,13% xuống 87,53% (đo 23/09). Không thể dựng phân khúc khách hàng trên một tập định danh chưa biết là gì
Định nghĩa doanh thu chưa chốt với kế toánĐối soát tháng 1–6/2026 (24–25/09): 175.927 / 175.927 chứng từ của hệ nguồn có trong kho, và phần chênh doanh thu đúng bằng phí giao hàng (kho tính vào doanh thu, báo cáo hệ nguồn loại ra). Nhưng lộ 6 định nghĩa mức cao chưa chốt — phí giao hàng, số đơn có tính phiếu trả, số lượng bán, tỉ lệ trả, thẻ trả trước, tài khoản gộp — đang chờ người nghiệp vụ trả lời
Không có lớp giao tiếp cho ứng dụng khácHiện chưa có đường nào để một ứng dụng vệ tinh đọc dữ liệu ngoài việc nối thẳng vào cơ sở dữ liệu. Chatbot P2.10 sẽ là đường đầu tiên — và chỉ cho Claude chạy trên chính máy này
Tất cả chạy trên một máyMột kho, một bộ lịch, một ổ đĩa đang vơi dần (134,97 GB ngày 25/09; 141,3 GB ngày 23/09), và tài liệu dựng lại đầy đủ trên máy mới chưa viết — hướng dẫn bàn giao mới có phần bản tin

Phần 06

Đề nghị

Nền dữ liệu đã đủ vững để phục vụ báo cáo. Nó chưa đủ vững để gánh thêm nhiều bên tiêu thụ. Khoảng cách giữa hai trạng thái đó không nằm ở dữ liệu — nằm ở vận hành.

0vấn đề chặn nằm trong lớp nạp hoặc lớp biến đổi
12vấn đề chặn còn mở ở vận hành, giám sát, bí mật, câu hỏi nghiệp vụ — 10 trong 11 của ngày 23/09, cộng 2 mức cao phát hiện sau (máy ngủ qua đêm; định nghĩa doanh thu chưa chốt)
Đề nghị 01

Hai email gửi trong tuần này

Một gửi phòng CNTT xin xác nhận bằng văn bản ngày gia hạn chứng chỉ — còn 15 ngày tính từ 25/09, và độ trễ nằm ở phía người khác chứ không phải phía đội dự án. Một gửi xin danh mục bảng và cột của hệ nguồn. Cả hai gần như không tốn chi phí, và cả hai đang là việc chưa làm.

Đề nghị 02

Hoàn tất bàn giao trước khi mở rộng

Viết tài liệu dựng lại trên máy mới, chuyển tác vụ nền sang chạy không cần đăng nhập và chứng minh bằng một lần khởi động lại thật, và vá ba điểm mù của bộ canh gác. Đây là phần kém hấp dẫn nhất của dự án và là phần duy nhất không bỏ được: nếu luồng dữ liệu dừng hoặc người kế nhiệm không dựng lại được thì mọi thứ xây thêm đều không có dữ liệu để chạy.

Đã làm từ 23/09: kho tự bật lại sau khởi động · bản sao lưu đầu tiên chạy được · thẻ báo lỗi của bản tin tách sang kênh vận hành. Chưa làm: tài liệu dựng lại, chạy không cần đăng nhập, ba điểm mù của bộ canh gác, máy ngủ qua đêm.

Đề nghị 03

Một câu hỏi cần ban lãnh đạo trả lời

Báo cáo đã được nghiệm thu là đọc được. Chưa được chứng minh là nó trả lời đúng câu hỏi mà người dùng thật sẽ hỏi — vì cả năm câu hỏi nghiệm thu đều do đội dự án soạn sẵn. Đề nghị: một người dùng nghiệp vụ tự viết ra ba câu hỏi họ thật sự cần trả lời mỗi tuần, trước khi nhìn báo cáo. Ba câu đó là thước đo thật, và cũng là đặc tả cho giai đoạn sau.

Cập nhật 25/09: plan chatbot P2.10 lấy đúng việc này làm điều kiện nghiệm thu — chủ dự án và CEO viết ít nhất sáu câu trước khi xem từ điển dữ liệu, và chatbot phải trả lời đúng cả tiền lẫn số đếm.