tôi muốn hoàn thành chương 4 chương 5 chương 6 tro...
Creato il: 8 maggio 2026
Risposto usando GPT-5.5 Thinking da Chat01
Domanda
Sơ Lược Báo Cáo Đồ Án Cuối Kỳ - AI SCM (1).pdf
tôi muốn hoàn thành chương 4 chương 5 chương 6 trong tài liệu này , hãy viết dài và đẩy đủ tất cả những thứ cần thiét và nên viết
Pensiero
Risposta
Dưới đây là bản viết mở rộng, dài và đầy đủ cho Chương 4, Chương 5, Chương 6 dựa trên nội dung hiện có trong tài liệu của bạn. Nội dung này phát triển tiếp từ phần kiến trúc 3 tầng, workflow dự báo, database/data pipeline và quy trình triển khai đã có trong bản thảo hiện tại (Sơ Lược Báo Cáo Đồ Án Cuối Kỳ - AI SCM (1).pdf).
CHƯƠNG 4: THIẾT KẾ HỆ THỐNG
4.1. Tổng quan thiết kế hệ thống
Hệ thống quản trị chuỗi cung ứng thông minh AI-SCM được thiết kế nhằm hỗ trợ mô hình kinh doanh cá nhân trong việc quản lý bán hàng, tồn kho, dự báo nhu cầu và ra quyết định nhập hàng. Điểm cốt lõi của hệ thống không chỉ nằm ở việc lưu trữ dữ liệu giao dịch, mà còn ở khả năng biến dữ liệu bán hàng thành thông tin hỗ trợ quyết định.
Trong mô hình kinh doanh cá nhân, chủ shop thường phải xử lý nhiều công việc cùng lúc như quản lý sản phẩm, theo dõi tồn kho, kiểm tra đơn hàng, nhập hàng, làm việc với nhà cung cấp và đánh giá hiệu quả kinh doanh. Nếu các tác vụ này được thực hiện thủ công, người kinh doanh rất dễ gặp phải tình trạng nhập quá nhiều hàng bán chậm hoặc không kịp bổ sung hàng bán chạy. Vì vậy, hệ thống AI-SCM được thiết kế theo hướng tự động hóa các nghiệp vụ quan trọng và cung cấp gợi ý thông minh dựa trên dữ liệu.
Về mặt tổng thể, hệ thống được chia thành ba nhóm chức năng chính:
Thứ nhất là nhóm chức năng thương mại điện tử, bao gồm quản lý sản phẩm, danh mục, giỏ hàng, đơn hàng, thanh toán và lịch sử mua hàng. Đây là phần giao tiếp trực tiếp với khách hàng cuối.
Thứ hai là nhóm chức năng quản trị vận hành, bao gồm quản lý kho, theo dõi nhập xuất tồn, quản lý nhà cung cấp, quản lý đơn nhập hàng và báo cáo doanh thu.
Thứ ba là nhóm chức năng trí tuệ nhân tạo và phân tích dữ liệu, bao gồm dự báo nhu cầu, phân loại sản phẩm ABC-XYZ, tính toán điểm đặt hàng lại, phát hiện nguy cơ hết hàng, cảnh báo hàng tồn chậm luân chuyển và hỗ trợ sinh đơn nhập hàng thông minh.
Thiết kế hệ thống hướng đến bốn mục tiêu quan trọng: dễ mở rộng, dễ bảo trì, đảm bảo tính toàn vẹn dữ liệu và có khả năng tích hợp AI độc lập với hệ thống nghiệp vụ chính.
4.2. Kiến trúc phân tầng của hệ thống
Hệ thống được thiết kế theo kiến trúc phân tầng kết hợp với định hướng microservices. Việc phân tách thành nhiều tầng giúp mỗi thành phần đảm nhận một nhiệm vụ riêng, tránh phụ thuộc quá chặt và thuận tiện cho việc phát triển, kiểm thử cũng như triển khai thực tế.
4.2.1. Tầng hiển thị
Tầng hiển thị được xây dựng bằng ReactJS, đóng vai trò là giao diện tương tác giữa người dùng và hệ thống. Tầng này phục vụ hai nhóm người dùng chính: khách hàng mua sắm và chủ shop/quản trị viên.
Đối với khách hàng, giao diện cung cấp các chức năng như xem danh sách sản phẩm, tìm kiếm sản phẩm, lọc theo danh mục, xem chi tiết sản phẩm, thêm sản phẩm vào giỏ hàng, đặt hàng và theo dõi trạng thái đơn hàng.
Đối với chủ shop, giao diện Dashboard hiển thị các chỉ số quan trọng như doanh thu, số lượng đơn hàng, số lượng sản phẩm tồn kho, danh sách sản phẩm sắp hết hàng, danh sách hàng tồn chậm luân chuyển, biểu đồ dự báo nhu cầu và các đơn nhập hàng cần phê duyệt.
ReactJS phù hợp với tầng hiển thị vì có khả năng xây dựng giao diện động, phản hồi nhanh và dễ kết hợp với các thư viện biểu đồ như Chart.js, Recharts hoặc ECharts. Điều này rất cần thiết đối với Dashboard quản trị, nơi dữ liệu cần được trực quan hóa rõ ràng để người dùng có thể nhanh chóng nắm bắt tình hình kinh doanh.
4.2.2. Tầng xử lý nghiệp vụ
Tầng xử lý nghiệp vụ là trung tâm điều hành của hệ thống. Thành phần chính của tầng này là Spring Boot Backend. Spring Boot chịu trách nhiệm xử lý các nghiệp vụ cốt lõi như quản lý người dùng, phân quyền, quản lý sản phẩm, quản lý đơn hàng, trừ tồn kho, tạo phiếu nhập hàng và lưu trữ các thay đổi vào cơ sở dữ liệu.
Spring Boot được lựa chọn vì có khả năng xây dựng hệ thống backend ổn định, hỗ trợ tốt mô hình REST API, dễ tích hợp với cơ sở dữ liệu MySQL và có hệ sinh thái bảo mật mạnh thông qua Spring Security. Những nghiệp vụ như đặt hàng, thanh toán, cập nhật tồn kho và phê duyệt đơn nhập hàng đòi hỏi tính nhất quán dữ liệu cao, vì vậy cần được xử lý bởi một backend có khả năng kiểm soát giao dịch tốt.
Bên cạnh Spring Boot, hệ thống sử dụng FastAPI để triển khai các dịch vụ AI. Việc tách AI Service thành một dịch vụ độc lập giúp hệ thống linh hoạt hơn. Các mô hình như Prophet, LSTM hoặc thuật toán Moving Average có thể được xây dựng bằng Python mà không ảnh hưởng đến hệ thống nghiệp vụ Java. Khi cần dự báo, Spring Boot hoặc Airflow có thể gọi API từ FastAPI để nhận kết quả dự báo.
Ngoài ra, Apache Airflow đóng vai trò điều phối các tác vụ tự động theo lịch trình. Airflow đảm nhiệm việc thu thập dữ liệu, làm sạch dữ liệu, kích hoạt mô hình dự báo, lưu kết quả dự báo và kiểm tra điều kiện tái huấn luyện mô hình.
4.2.3. Tầng dữ liệu
Tầng dữ liệu là nơi lưu trữ toàn bộ thông tin cần thiết cho hệ thống. MySQL được sử dụng làm cơ sở dữ liệu quan hệ chính, lưu trữ các bảng như người dùng, sản phẩm, danh mục, đơn hàng, chi tiết đơn hàng, tồn kho, nhà cung cấp, đơn nhập hàng, kết quả dự báo và lịch sử cảnh báo.
MySQL đóng vai trò là nguồn dữ liệu chính, đảm bảo dữ liệu có cấu trúc, dễ truy vấn và hỗ trợ tốt các quan hệ giữa bảng. Các thông tin như đơn hàng, sản phẩm, tồn kho và nhà cung cấp cần được lưu trữ lâu dài, chính xác và có khả năng truy vết.
Redis được sử dụng như bộ nhớ đệm để tăng tốc độ truy xuất dữ liệu. Các dữ liệu thường xuyên được đọc như kết quả dự báo mới nhất, KPI Dashboard, danh sách sản phẩm cảnh báo hoặc dữ liệu thống kê ngắn hạn có thể được lưu trong Redis để giảm tải cho MySQL.
Ngoài dữ liệu nội bộ, hệ thống còn có thể thu thập dữ liệu từ các nguồn bên ngoài như sàn thương mại điện tử, dữ liệu xu hướng sản phẩm, chương trình khuyến mãi hoặc các sự kiện đặc biệt. Những dữ liệu này được đưa vào pipeline xử lý trước khi lưu vào hệ thống.
4.3. Thiết kế kiến trúc logic
Về mặt logic, hệ thống AI-SCM gồm các phân hệ chính sau:
4.3.1. Phân hệ quản lý người dùng và phân quyền
Phân hệ này chịu trách nhiệm quản lý tài khoản người dùng, bao gồm khách hàng, chủ shop, nhân viên và quản trị viên hệ thống. Mỗi nhóm người dùng có quyền truy cập khác nhau.
Khách hàng có quyền đăng ký tài khoản, đăng nhập, xem sản phẩm, đặt hàng và theo dõi đơn hàng.
Chủ shop có quyền quản lý sản phẩm, xem Dashboard, duyệt đơn nhập hàng, xem cảnh báo tồn kho và theo dõi báo cáo kinh doanh.
Nhân viên có thể được phân quyền xử lý đơn hàng, cập nhật sản phẩm hoặc quản lý kho tùy theo vai trò.
Quản trị viên hệ thống có quyền cao nhất, bao gồm cấu hình hệ thống, quản lý tài khoản, giám sát pipeline dữ liệu và kiểm tra trạng thái mô hình AI.
Phân quyền được triển khai thông qua JWT kết hợp với Role-Based Access Control. Sau khi đăng nhập thành công, người dùng nhận được token xác thực. Mỗi request gửi đến backend đều cần kèm token để hệ thống kiểm tra quyền truy cập.
4.3.2. Phân hệ quản lý sản phẩm
Phân hệ quản lý sản phẩm cho phép thêm, sửa, xóa và tìm kiếm sản phẩm. Mỗi sản phẩm bao gồm các thông tin như tên sản phẩm, mô tả, giá bán, giá nhập, danh mục, hình ảnh, nhà cung cấp, trạng thái kinh doanh và số lượng tồn kho hiện tại.
Thông tin sản phẩm không chỉ phục vụ cho giao diện bán hàng mà còn là đầu vào quan trọng cho các phân hệ AI-SCM. Ví dụ, dữ liệu giá nhập và giá bán được sử dụng để tính giá trị tiêu thụ trong phân loại ABC. Dữ liệu tồn kho được dùng để tính toán điểm đặt hàng lại. Lịch sử bán của từng sản phẩm được dùng để huấn luyện mô hình dự báo nhu cầu.
4.3.3. Phân hệ quản lý đơn hàng
Phân hệ quản lý đơn hàng xử lý toàn bộ vòng đời của một đơn hàng, từ khi khách hàng tạo đơn đến khi đơn hàng hoàn tất. Khi khách hàng đặt hàng, hệ thống kiểm tra tồn kho, ghi nhận thông tin đơn hàng, tạo chi tiết đơn hàng và cập nhật số lượng tồn kho.
Trạng thái đơn hàng có thể bao gồm: chờ xác nhận, đã xác nhận, đang chuẩn bị hàng, đang giao hàng, hoàn tất hoặc đã hủy. Mỗi thay đổi trạng thái đều được lưu lại để phục vụ truy vết.
Dữ liệu đơn hàng là nguồn dữ liệu quan trọng nhất cho hệ thống dự báo. Thông qua lịch sử bán hàng theo ngày, hệ thống có thể xác định sản phẩm nào có nhu cầu tăng, sản phẩm nào giảm, sản phẩm nào có tính mùa vụ và sản phẩm nào có nguy cơ tồn kho.
4.3.4. Phân hệ quản lý kho thông minh
Phân hệ quản lý kho thông minh theo dõi số lượng nhập, xuất và tồn của từng sản phẩm. Khi có đơn hàng được xác nhận, hệ thống tự động trừ tồn kho. Khi có đơn nhập hàng được hoàn tất, hệ thống cộng tồn kho.
Ngoài việc lưu số lượng, phân hệ này còn tính toán các chỉ số quan trọng như tồn kho an toàn, điểm đặt hàng lại, tốc độ bán trung bình, số ngày tồn kho dự kiến và trạng thái cảnh báo.
Nếu số lượng tồn kho hiện tại nhỏ hơn hoặc bằng điểm đặt hàng lại, hệ thống tạo cảnh báo sắp hết hàng. Nếu số lượng tồn kho cao nhưng tốc độ bán thấp, hệ thống tạo cảnh báo hàng tồn chậm luân chuyển hoặc nguy cơ deadstock.
4.3.5. Phân hệ dự báo nhu cầu
Phân hệ dự báo nhu cầu được triển khai trong AI Service bằng FastAPI. Dữ liệu đầu vào là lịch sử bán hàng theo ngày, dữ liệu sự kiện khuyến mãi, ngày lễ, flash sale và xu hướng thị trường nếu có.
Hệ thống có thể sử dụng nhiều mô hình dự báo khác nhau. Prophet phù hợp với dữ liệu có yếu tố mùa vụ, ngày lễ và xu hướng rõ ràng. LSTM phù hợp với dữ liệu chuỗi thời gian phức tạp, có quan hệ phi tuyến. Trong trường hợp dữ liệu ít hoặc sản phẩm mới, hệ thống có thể sử dụng Moving Average để đảm bảo dự báo ổn định hơn.
Kết quả dự báo được lưu vào bảng forecast_results và được sử dụng bởi các phân hệ khác như quản lý kho, cảnh báo tồn kho và sinh đơn nhập hàng thông minh.
4.3.6. Phân hệ Smart Purchase Order
Phân hệ Smart Purchase Order có nhiệm vụ tạo gợi ý nhập hàng tự động. Hệ thống kết hợp dữ liệu tồn kho hiện tại, điểm đặt hàng lại, kết quả dự báo nhu cầu và thông tin nhà cung cấp để đề xuất số lượng cần nhập.
Đơn nhập hàng do hệ thống tạo ban đầu có trạng thái bản nháp. Chủ shop có thể xem, chỉnh sửa số lượng, thay đổi nhà cung cấp hoặc hủy đề xuất. Sau khi chủ shop phê duyệt, đơn nhập hàng chuyển sang trạng thái đã duyệt và được gửi đến nhà cung cấp.
Cơ chế này đảm bảo AI chỉ đóng vai trò hỗ trợ ra quyết định, còn quyền quyết định cuối cùng vẫn thuộc về con người.
4.4. Sơ đồ luồng xử lý tổng thể
Luồng xử lý tổng thể của hệ thống có thể mô tả như sau:
Khách hàng truy cập website, tìm kiếm sản phẩm và đặt hàng. Sau khi đơn hàng được tạo, Spring Boot Backend ghi nhận đơn hàng vào MySQL và cập nhật tồn kho. Dữ liệu bán hàng này đồng thời trở thành dữ liệu đầu vào cho hệ thống phân tích.
Theo lịch trình định sẵn, Airflow kích hoạt các tác vụ ETL. Hệ thống lấy dữ liệu bán hàng từ MySQL, làm sạch dữ liệu, chuẩn hóa theo định dạng chuỗi thời gian và gửi sang AI Service. AI Service chạy mô hình dự báo nhu cầu cho 30 ngày tiếp theo, sau đó trả kết quả về để lưu vào bảng forecast_results.
Tiếp theo, hệ thống so sánh kết quả dự báo với tồn kho hiện tại và điểm đặt hàng lại. Nếu tồn kho có nguy cơ không đủ đáp ứng nhu cầu, hệ thống tạo cảnh báo và sinh gợi ý nhập hàng. Chủ shop xem các gợi ý này trên Dashboard, sau đó phê duyệt hoặc điều chỉnh.
Khi nhà cung cấp giao hàng, nhân viên hoặc chủ shop xác nhận nhập kho. Hệ thống cập nhật lại số lượng tồn kho. Dữ liệu nhập hàng và dữ liệu bán hàng tiếp tục được lưu lại để phục vụ các chu kỳ dự báo sau. Đây là một vòng lặp dữ liệu khép kín, giúp hệ thống ngày càng có nhiều dữ liệu và đưa ra gợi ý chính xác hơn.
4.5. Thiết kế workflow dự báo và tái huấn luyện
Workflow dự báo được thiết kế theo dạng tự động, chạy định kỳ mỗi ngày. Mục tiêu của workflow là tạo ra kết quả dự báo mới nhất, đánh giá độ chính xác của mô hình và quyết định có cần tái huấn luyện hay không.
Quy trình gồm các bước chính:
Bước đầu tiên, Airflow kích hoạt DAG dự báo theo lịch, ví dụ vào 0 giờ mỗi ngày. DAG truy xuất dữ liệu bán hàng từ bảng sales_logs hoặc order_items.
Bước thứ hai, hệ thống làm sạch dữ liệu. Các bản ghi bị thiếu, sai định dạng hoặc bất thường được xử lý trước khi đưa vào mô hình. Dữ liệu có thể được tổng hợp theo ngày để phù hợp với bài toán dự báo chuỗi thời gian.
Bước thứ ba, dữ liệu được gửi đến AI Service. Tại đây, mô hình Prophet hoặc LSTM tiến hành dự báo nhu cầu cho 30 ngày tiếp theo.
Bước thứ tư, kết quả dự báo được lưu vào cơ sở dữ liệu. Đồng thời, một bản kết quả mới nhất có thể được lưu vào Redis để Dashboard truy xuất nhanh hơn.
Bước thứ năm, hệ thống so sánh doanh số thực tế với doanh số đã dự báo ở các chu kỳ trước. Nếu sai số vượt ngưỡng cho phép, ví dụ MAPE lớn hơn 20%, hệ thống đánh dấu mô hình cần được tái huấn luyện.
Bước cuối cùng, nếu cần tái huấn luyện, Airflow kích hoạt pipeline retraining. Mô hình mới sau khi huấn luyện được đánh giá lại. Nếu mô hình mới tốt hơn mô hình cũ, hệ thống cập nhật phiên bản mô hình. Nếu mô hình mới không tốt hơn, hệ thống giữ nguyên phiên bản hiện tại.
4.6. Thiết kế bảo mật hệ thống
Bảo mật là yêu cầu quan trọng vì hệ thống lưu trữ nhiều dữ liệu nhạy cảm như thông tin khách hàng, doanh thu, đơn hàng, tồn kho và chiến lược nhập hàng.
Hệ thống áp dụng các cơ chế bảo mật sau:
Cơ chế xác thực được triển khai bằng JWT. Người dùng phải đăng nhập để nhận token. Token được gửi kèm trong các request để xác minh danh tính.
Cơ chế phân quyền được triển khai theo vai trò. Khách hàng không thể truy cập Dashboard quản trị. Nhân viên chỉ được truy cập các chức năng được phân công. Chủ shop và quản trị viên có quyền xem báo cáo và phê duyệt đơn nhập hàng.
Dữ liệu mật khẩu được mã hóa bằng thuật toán băm như BCrypt trước khi lưu vào cơ sở dữ liệu. Hệ thống không lưu mật khẩu dạng văn bản thuần.
Các API quan trọng như tạo đơn hàng, cập nhật tồn kho, phê duyệt PO và cấu hình mô hình AI cần được kiểm tra quyền nghiêm ngặt.
Ngoài ra, hệ thống cần ghi log các hành động quan trọng như đăng nhập, thay đổi giá sản phẩm, cập nhật tồn kho, phê duyệt đơn nhập hàng và thay đổi cấu hình hệ thống để phục vụ kiểm tra khi có sự cố.
4.7. Thiết kế triển khai hệ thống
Hệ thống được đóng gói bằng Docker để đảm bảo mỗi thành phần có môi trường chạy độc lập. Các dịch vụ chính bao gồm:
Frontend React chạy trong container riêng.
Spring Boot Backend chạy trong container riêng.
FastAPI AI Service chạy trong container riêng.
MySQL chạy trong container cơ sở dữ liệu.
Redis chạy trong container bộ nhớ đệm.
Apache Airflow gồm các thành phần webserver, scheduler và worker.
Trong môi trường phát triển, có thể sử dụng Docker Compose để khởi chạy toàn bộ hệ thống. Trong môi trường triển khai thực tế, có thể sử dụng Kubernetes để quản lý nhiều container, tự động khởi động lại khi lỗi và mở rộng tài nguyên khi lượng truy cập tăng.
Hệ thống cũng cần có cơ chế giám sát bằng Prometheus và Grafana. Prometheus thu thập chỉ số như CPU, RAM, thời gian phản hồi API, số lượng request, số job Airflow thành công/thất bại. Grafana hiển thị các chỉ số này dưới dạng Dashboard để quản trị viên dễ theo dõi.
4.8. Kết luận chương 4
Chương 4 đã trình bày thiết kế tổng thể của hệ thống AI-SCM theo kiến trúc phân tầng kết hợp microservices. Hệ thống được chia thành tầng hiển thị, tầng xử lý nghiệp vụ và tầng dữ liệu. Bên cạnh đó, các phân hệ quan trọng như quản lý sản phẩm, quản lý đơn hàng, quản lý kho, dự báo nhu cầu và Smart Purchase Order cũng được thiết kế rõ ràng.
Thiết kế này giúp hệ thống có khả năng mở rộng, dễ bảo trì và phù hợp với bài toán thực tế của mô hình kinh doanh cá nhân. Đặc biệt, việc tách AI Service và Airflow ra khỏi backend nghiệp vụ giúp hệ thống vừa đảm bảo tính ổn định trong xử lý giao dịch, vừa có khả năng phân tích dữ liệu và đưa ra gợi ý thông minh.
CHƯƠNG 5: HỆ THỐNG CƠ SỞ DỮ LIỆU VÀ DATA PIPELINE
5.1. Vai trò của cơ sở dữ liệu trong hệ thống AI-SCM
Cơ sở dữ liệu là thành phần trung tâm của hệ thống AI-SCM. Toàn bộ hoạt động của hệ thống như bán hàng, quản lý sản phẩm, quản lý tồn kho, dự báo nhu cầu, đánh giá nhà cung cấp và tạo đơn nhập hàng đều phụ thuộc vào dữ liệu.
Trong hệ thống truyền thống, nhiều chủ shop thường sử dụng Excel để ghi nhận số lượng hàng hóa, doanh thu và đơn hàng. Cách làm này phù hợp với quy mô nhỏ nhưng dễ xảy ra sai sót khi dữ liệu tăng lên. Người dùng có thể nhập sai số lượng, quên cập nhật tồn kho hoặc không kịp tổng hợp dữ liệu để ra quyết định.
Vì vậy, hệ thống AI-SCM sử dụng MySQL làm cơ sở dữ liệu quan hệ chính. MySQL lưu trữ dữ liệu có cấu trúc, hỗ trợ quan hệ giữa các bảng và đảm bảo tính toàn vẹn thông qua khóa chính, khóa ngoại và ràng buộc dữ liệu.
Ngoài MySQL, hệ thống sử dụng Redis để lưu trữ dữ liệu tạm thời có tần suất truy cập cao. Việc kết hợp MySQL và Redis giúp hệ thống vừa đảm bảo tính chính xác của dữ liệu dài hạn, vừa cải thiện tốc độ phản hồi của Dashboard.
5.2. Nguyên tắc thiết kế cơ sở dữ liệu
Cơ sở dữ liệu được thiết kế theo các nguyên tắc sau:
Thứ nhất, dữ liệu phải được chuẩn hóa để giảm trùng lặp. Ví dụ, thông tin danh mục sản phẩm được lưu trong bảng categories, còn sản phẩm chỉ tham chiếu đến danh mục thông qua category_id.
Thứ hai, các bảng phải có quan hệ rõ ràng. Một đơn hàng có thể có nhiều dòng chi tiết đơn hàng. Một sản phẩm có thể xuất hiện trong nhiều đơn hàng. Một nhà cung cấp có thể cung cấp nhiều sản phẩm.
Thứ ba, dữ liệu nghiệp vụ quan trọng cần có trạng thái rõ ràng. Ví dụ, đơn hàng có trạng thái pending, confirmed, shipping, completed hoặc cancelled. Đơn nhập hàng có trạng thái draft, approved, sent, received hoặc cancelled.
Thứ tư, hệ thống cần lưu lịch sử thay đổi để phục vụ truy vết. Các thay đổi về tồn kho, đơn hàng, phiếu nhập hàng và cảnh báo cần được ghi nhận theo thời gian.
Thứ năm, dữ liệu phục vụ AI phải được tổ chức theo dạng có thể truy vấn và tổng hợp dễ dàng. Dữ liệu bán hàng cần có product_id, ngày bán, số lượng bán và doanh thu để phục vụ mô hình dự báo.
5.3. Thiết kế các bảng dữ liệu chính
5.3.1. Bảng users
Bảng users lưu thông tin tài khoản người dùng trong hệ thống. Các trường chính gồm id, full_name, email, password_hash, phone, address, role và status.
Trường role dùng để phân biệt khách hàng, nhân viên, chủ shop và quản trị viên. Trường status cho biết tài khoản đang hoạt động, bị khóa hoặc đã bị xóa mềm.
Bảng này phục vụ các chức năng đăng ký, đăng nhập, phân quyền, đặt hàng và quản trị người dùng.
5.3.2. Bảng categories
Bảng categories lưu thông tin danh mục sản phẩm. Mỗi danh mục có id, name, description, parent_id và status.
Trường parent_id cho phép xây dựng danh mục nhiều cấp. Ví dụ, danh mục “Đồ dùng cá nhân” có thể có danh mục con là “Chăm sóc da”, “Chăm sóc tóc”, “Phụ kiện cá nhân”.
5.3.3. Bảng products
Bảng products lưu thông tin sản phẩm. Các trường chính gồm id, category_id, supplier_id, name, sku, description, selling_price, import_price, image_url, status và created_at.
Trường sku là mã định danh sản phẩm, giúp quản lý kho dễ dàng hơn. Trường supplier_id cho biết nhà cung cấp chính của sản phẩm. Trường selling_price và import_price được sử dụng trong tính toán doanh thu, lợi nhuận và phân loại ABC.
5.3.4. Bảng inventory_balances
Bảng inventory_balances lưu số lượng tồn kho hiện tại của từng sản phẩm. Các trường chính gồm id, product_id, current_stock, safety_stock, reorder_point, reserved_stock, warehouse_location và updated_at.
current_stock là số lượng tồn thực tế. reserved_stock là số lượng đã được giữ cho các đơn hàng đang chờ xử lý. safety_stock là tồn kho an toàn. reorder_point là điểm đặt hàng lại.
Bảng này là nguồn dữ liệu quan trọng để hệ thống phát hiện sản phẩm sắp hết hàng hoặc tồn kho quá mức.
5.3.5. Bảng inventory_logs
Bảng inventory_logs lưu lịch sử biến động kho. Mỗi khi có nhập hàng, xuất hàng, hủy đơn hoặc điều chỉnh kho, hệ thống tạo một bản ghi mới.
Các trường gồm id, product_id, change_type, quantity_change, before_quantity, after_quantity, reference_type, reference_id, note và created_at.
Ví dụ, khi khách hàng đặt mua 3 sản phẩm A, hệ thống tạo log với change_type là OUTBOUND và quantity_change là -3. Khi nhận hàng từ nhà cung cấp, hệ thống tạo log với change_type là INBOUND.
5.3.6. Bảng orders
Bảng orders lưu thông tin đơn hàng của khách hàng. Các trường chính gồm id, customer_id, order_code, total_amount, payment_method, payment_status, order_status, shipping_address và created_at.
Trạng thái đơn hàng được quản lý theo vòng đời. Khi đơn hàng mới được tạo, trạng thái là pending. Sau khi được xác nhận, trạng thái chuyển thành confirmed. Khi giao hàng thành công, trạng thái chuyển thành completed.
5.3.7. Bảng order_items
Bảng order_items lưu chi tiết từng sản phẩm trong đơn hàng. Các trường gồm id, order_id, product_id, quantity, unit_price, discount và subtotal.
Bảng này rất quan trọng đối với hệ thống AI vì nó cho biết mỗi sản phẩm bán được bao nhiêu trong từng đơn hàng. Từ bảng này, hệ thống có thể tổng hợp doanh số theo ngày để huấn luyện mô hình dự báo.
5.3.8. Bảng suppliers
Bảng suppliers lưu thông tin nhà cung cấp. Các trường chính gồm id, name, contact_name, phone, email, address, average_lead_time, reliability_score, price_score, delivery_score và status.
reliability_score là điểm uy tín tổng hợp. Điểm này có thể được tính dựa trên tốc độ giao hàng, độ ổn định giá, tỷ lệ giao đúng số lượng và lịch sử hợp tác.
5.3.9. Bảng purchase_orders
Bảng purchase_orders lưu thông tin đơn nhập hàng. Các trường gồm id, po_code, supplier_id, status, total_amount, created_by, approved_by, created_at và approved_at.
Đơn nhập hàng có thể được tạo thủ công hoặc do hệ thống AI đề xuất. Khi AI tạo đơn, trạng thái ban đầu là draft. Sau khi chủ shop duyệt, trạng thái chuyển thành approved.
5.3.10. Bảng purchase_order_items
Bảng purchase_order_items lưu chi tiết sản phẩm trong đơn nhập hàng. Các trường gồm id, purchase_order_id, product_id, suggested_quantity, approved_quantity, unit_cost và subtotal.
suggested_quantity là số lượng AI đề xuất. approved_quantity là số lượng thực tế được chủ shop phê duyệt. Việc lưu cả hai giá trị giúp hệ thống học được sự điều chỉnh của con người, từ đó cải thiện gợi ý trong tương lai.
5.3.11. Bảng sales_logs
Bảng sales_logs lưu dữ liệu bán hàng đã được tổng hợp theo ngày. Các trường gồm id, product_id, sale_date, quantity_sold, revenue, promotion_flag và event_tag.
Bảng này giúp AI Service truy xuất dữ liệu nhanh hơn thay vì phải tính toán lại từ orders và order_items mỗi lần chạy mô hình. promotion_flag cho biết ngày bán hàng có chương trình khuyến mãi hay không. event_tag có thể lưu các sự kiện như flash sale, 11/11, 12/12 hoặc payday.
5.3.12. Bảng forecast_results
Bảng forecast_results lưu kết quả dự báo nhu cầu. Các trường gồm id, product_id, forecast_date, predicted_quantity, lower_bound, upper_bound, model_name, model_version và created_at.
lower_bound và upper_bound thể hiện khoảng dự báo. Điều này giúp chủ shop hiểu rằng dự báo không phải là một con số tuyệt đối mà là một khoảng có độ tin cậy nhất định.
5.3.13. Bảng ai_models
Bảng ai_models lưu thông tin phiên bản mô hình AI. Các trường gồm id, model_name, model_version, training_date, mae, rmse, mape, status và file_path.
Bảng này hỗ trợ quản lý vòng đời mô hình. Khi có mô hình mới được huấn luyện, hệ thống có thể so sánh chỉ số lỗi với mô hình hiện tại trước khi quyết định sử dụng.
5.3.14. Bảng alerts
Bảng alerts lưu các cảnh báo do hệ thống tạo ra. Các trường gồm id, product_id, alert_type, severity, message, status, created_at và resolved_at.
alert_type có thể là OUT_OF_STOCK_RISK, DEADSTOCK_RISK, HIGH_DEMAND, LOW_SUPPLIER_SCORE hoặc MODEL_ERROR. severity có thể là low, medium, high hoặc critical.
5.4. Mối quan hệ giữa các bảng
Một người dùng có thể tạo nhiều đơn hàng, vì vậy users có quan hệ một-nhiều với orders.
Một đơn hàng có nhiều sản phẩm, vì vậy orders có quan hệ một-nhiều với order_items.
Một sản phẩm có thể xuất hiện trong nhiều chi tiết đơn hàng, vì vậy products có quan hệ một-nhiều với order_items.
Một sản phẩm thuộc một danh mục, vì vậy categories có quan hệ một-nhiều với products.
Một nhà cung cấp có thể cung cấp nhiều sản phẩm, vì vậy suppliers có quan hệ một-nhiều với products.
Một nhà cung cấp có thể có nhiều đơn nhập hàng, vì vậy suppliers có quan hệ một-nhiều với purchase_orders.
Một đơn nhập hàng có nhiều sản phẩm, vì vậy purchase_orders có quan hệ một-nhiều với purchase_order_items.
Một sản phẩm có một bản ghi tồn kho hiện tại trong inventory_balances nhưng có nhiều lịch sử biến động trong inventory_logs.
Một sản phẩm có nhiều kết quả dự báo theo từng ngày trong forecast_results.
Một sản phẩm có thể phát sinh nhiều cảnh báo trong alerts.
Các quan hệ này đảm bảo dữ liệu được tổ chức nhất quán, có khả năng truy vết và hỗ trợ tốt cho các truy vấn phân tích.
5.5. Thiết kế Data Pipeline
Data Pipeline là chuỗi xử lý dữ liệu tự động từ lúc dữ liệu được thu thập đến lúc dữ liệu được sử dụng cho AI và Dashboard. Trong hệ thống AI-SCM, Data Pipeline được điều phối bởi Apache Airflow.
Airflow cho phép định nghĩa các workflow dưới dạng DAG. Mỗi DAG gồm nhiều task nhỏ, mỗi task đảm nhận một công việc cụ thể như lấy dữ liệu, làm sạch dữ liệu, tổng hợp dữ liệu, chạy mô hình hoặc lưu kết quả.
Data Pipeline giúp hệ thống không phụ thuộc vào thao tác thủ công. Thay vì chủ shop phải tự tải dữ liệu, tính toán và nhập vào Excel, hệ thống tự động thực hiện các bước này theo lịch.
5.6. Pipeline đồng bộ dữ liệu bán hàng
Pipeline đồng bộ dữ liệu bán hàng có nhiệm vụ lấy dữ liệu từ hệ thống đơn hàng nội bộ hoặc từ các sàn thương mại điện tử.
Quy trình gồm các bước:
Bước một, Airflow kích hoạt job theo lịch. Job có thể chạy mỗi giờ hoặc mỗi ngày tùy nhu cầu.
Bước hai, hệ thống gọi API để lấy dữ liệu đơn hàng mới. Nếu dữ liệu đến từ sàn thương mại điện tử, hệ thống cần API Key hợp lệ.
Bước ba, dữ liệu thô được lưu tạm vào vùng staging. Việc lưu dữ liệu thô giúp hệ thống có thể kiểm tra lại khi có lỗi xử lý.
Bước bốn, dữ liệu được làm sạch. Các bản ghi thiếu mã sản phẩm, thiếu số lượng, sai định dạng ngày hoặc trùng lặp sẽ được xử lý.
Bước năm, dữ liệu được chuẩn hóa và ghi vào các bảng chính như orders, order_items và sales_logs.
Bước sáu, hệ thống ghi log kết quả pipeline. Nếu thành công, trạng thái là success. Nếu thất bại, trạng thái là failed và Airflow có thể tự động retry.
5.7. Pipeline dự báo nhu cầu
Pipeline dự báo nhu cầu là một trong những pipeline quan trọng nhất của hệ thống.
Quy trình gồm các bước:
Đầu tiên, Airflow lấy dữ liệu bán hàng từ sales_logs trong khoảng thời gian gần nhất. Đối với sản phẩm có dữ liệu đủ dài, hệ thống sử dụng lịch sử bán hàng từ 30 đến 90 ngày hoặc nhiều hơn.
Tiếp theo, dữ liệu được xử lý thành dạng chuỗi thời gian. Mỗi dòng dữ liệu gồm ngày bán và số lượng bán. Nếu có ngày không phát sinh đơn hàng, hệ thống vẫn cần tạo bản ghi với số lượng bằng 0 để chuỗi thời gian không bị đứt đoạn.
Sau đó, hệ thống bổ sung các biến sự kiện như ngày lễ, flash sale hoặc chương trình khuyến mãi. Những yếu tố này có thể ảnh hưởng lớn đến nhu cầu mua hàng.
Dữ liệu sau xử lý được gửi đến FastAPI AI Service. AI Service chạy mô hình Prophet, LSTM hoặc Moving Average tùy theo đặc điểm dữ liệu. Nếu dữ liệu đủ dài và có tính mùa vụ, Prophet được ưu tiên. Nếu dữ liệu phức tạp và có nhiều biến động phi tuyến, LSTM có thể được sử dụng. Nếu dữ liệu quá ít, Moving Average được dùng để tránh mô hình hóa quá mức.
Kết quả dự báo được lưu vào forecast_results. Đồng thời, kết quả mới nhất được lưu vào Redis để Dashboard có thể truy cập nhanh.
5.8. Pipeline phân loại ABC-XYZ
Phân loại ABC-XYZ giúp chủ shop biết sản phẩm nào quan trọng về mặt giá trị và sản phẩm nào ổn định về mặt nhu cầu.
Phân loại ABC dựa trên giá trị tiêu thụ. Giá trị tiêu thụ có thể được tính bằng số lượng bán nhân với giá bán hoặc lợi nhuận. Nhóm A là nhóm sản phẩm đóng góp giá trị cao nhất, thường chiếm tỷ trọng doanh thu lớn. Nhóm B có giá trị trung bình. Nhóm C có giá trị thấp.
Phân loại XYZ dựa trên mức độ ổn định của nhu cầu. Nhóm X là nhóm có nhu cầu ổn định. Nhóm Y có nhu cầu biến động vừa phải. Nhóm Z có nhu cầu biến động mạnh và khó dự báo.
Khi kết hợp hai phương pháp này, hệ thống có thể tạo ra các nhóm như AX, AY, AZ, BX, BY, BZ, CX, CY và CZ.
Sản phẩm nhóm AX là sản phẩm có giá trị cao và nhu cầu ổn định, cần được ưu tiên đảm bảo tồn kho. Sản phẩm nhóm AZ có giá trị cao nhưng nhu cầu biến động mạnh, cần theo dõi sát và tránh nhập quá nhiều. Sản phẩm nhóm CZ có giá trị thấp và nhu cầu khó đoán, nên hạn chế tồn kho.
Pipeline ABC-XYZ chạy định kỳ, ví dụ mỗi tuần một lần. Kết quả phân loại được lưu vào bảng product_segments hoặc trực tiếp cập nhật vào bảng products.
5.9. Pipeline cảnh báo tồn kho
Pipeline cảnh báo tồn kho có nhiệm vụ phát hiện các rủi ro vận hành.
Đối với cảnh báo sắp hết hàng, hệ thống so sánh current_stock với reorder_point. Nếu current_stock nhỏ hơn hoặc bằng reorder_point, hệ thống tạo cảnh báo OUT_OF_STOCK_RISK.
Đối với cảnh báo tồn kho chậm luân chuyển, hệ thống kiểm tra số lượng tồn kho, tốc độ bán trung bình và số ngày không phát sinh bán hàng. Nếu sản phẩm có tồn kho cao nhưng bán chậm, hệ thống tạo cảnh báo DEADSTOCK_RISK.
Đối với cảnh báo nhu cầu tăng bất thường, hệ thống so sánh doanh số thực tế gần đây với doanh số trung bình. Nếu nhu cầu tăng mạnh, hệ thống tạo cảnh báo HIGH_DEMAND để chủ shop chuẩn bị nhập hàng.
Các cảnh báo được hiển thị trên Dashboard, đồng thời lưu vào bảng alerts để theo dõi trạng thái xử lý.
5.10. Pipeline đánh giá nhà cung cấp
Pipeline đánh giá nhà cung cấp giúp hệ thống chọn nhà cung cấp phù hợp khi tạo Smart PO.
Các tiêu chí đánh giá có thể gồm:
Thời gian giao hàng trung bình.
Tỷ lệ giao đúng hạn.
Tỷ lệ giao đủ số lượng.
Mức độ ổn định giá.
Số lần phát sinh lỗi trong đơn hàng.
Điểm nhà cung cấp được tính theo trọng số. Ví dụ, delivery_score chiếm 40%, price_score chiếm 30%, reliability_score chiếm 30%. Nhà cung cấp có điểm tổng cao sẽ được ưu tiên đề xuất.
Kết quả đánh giá được cập nhật định kỳ vào bảng suppliers. Khi hệ thống sinh đơn nhập hàng, những nhà cung cấp có điểm thấp hoặc trạng thái không khả dụng sẽ không được ưu tiên.
5.11. Cơ chế xử lý lỗi trong Data Pipeline
Trong môi trường thực tế, pipeline dữ liệu có thể gặp nhiều lỗi như mất kết nối API, dữ liệu trả về sai định dạng, server chậm phản hồi hoặc dữ liệu bị thiếu. Vì vậy, hệ thống cần có cơ chế xử lý lỗi rõ ràng.
Airflow hỗ trợ retry tự động. Nếu một task thất bại, hệ thống có thể thử lại một số lần nhất định trước khi đánh dấu lỗi.
Nếu API sàn thương mại điện tử không phản hồi, hệ thống ghi log lỗi và thử lại sau một khoảng thời gian.
Nếu dữ liệu bị thiếu hoặc sai định dạng, hệ thống đưa bản ghi vào danh sách dữ liệu lỗi để kiểm tra sau, thay vì làm hỏng toàn bộ pipeline.
Nếu mô hình AI không thể chạy do dữ liệu quá ít, hệ thống chuyển sang phương pháp dự báo đơn giản hơn như Moving Average.
Nếu Dashboard không thể tải dữ liệu mới nhất, hệ thống hiển thị dữ liệu gần nhất đã được cache trong Redis và thông báo rằng dữ liệu đang được cập nhật.
5.12. Kết luận chương 5
Chương 5 đã trình bày thiết kế cơ sở dữ liệu và Data Pipeline cho hệ thống AI-SCM. Cơ sở dữ liệu MySQL đóng vai trò lưu trữ dữ liệu chính, Redis hỗ trợ tăng tốc truy xuất, còn Apache Airflow điều phối các pipeline tự động.
Các bảng dữ liệu được thiết kế xoay quanh các nghiệp vụ chính như người dùng, sản phẩm, đơn hàng, tồn kho, nhà cung cấp, đơn nhập hàng, dự báo và cảnh báo. Data Pipeline giúp hệ thống tự động đồng bộ dữ liệu, xử lý dữ liệu, dự báo nhu cầu, phân loại sản phẩm và tạo cảnh báo vận hành.
Nhờ thiết kế này, hệ thống có thể thay thế cách quản lý thủ công bằng một nền tảng dữ liệu tập trung, tự động và có khả năng hỗ trợ ra quyết định thông minh.
CHƯƠNG 6: CHI TIẾT TRIỂN KHAI
6.1. Tổng quan triển khai hệ thống
Sau khi hoàn thành thiết kế kiến trúc và cơ sở dữ liệu, hệ thống AI-SCM được triển khai theo từng giai đoạn. Mục tiêu của quá trình triển khai là xây dựng được một hệ thống có thể vận hành thực tế, bao gồm giao diện người dùng, backend nghiệp vụ, cơ sở dữ liệu, AI Service và Data Pipeline.
Việc triển khai được chia thành các nhóm công việc chính:
Triển khai cơ sở dữ liệu MySQL và Redis.
Triển khai backend Spring Boot.
Triển khai frontend ReactJS.
Triển khai AI Service bằng FastAPI.
Triển khai Apache Airflow để điều phối pipeline.
Triển khai các thuật toán dự báo, phân loại và gợi ý nhập hàng.
Triển khai Dashboard quản trị.
Kiểm thử, giám sát và tối ưu hệ thống.
Cách triển khai theo từng module giúp nhóm phát triển dễ kiểm soát tiến độ, giảm rủi ro và có thể kiểm thử từng thành phần trước khi tích hợp toàn bộ.
6.2. Triển khai môi trường hệ thống
Môi trường phát triển được xây dựng bằng Docker để đảm bảo các thành phần có thể chạy độc lập nhưng vẫn giao tiếp được với nhau.
Các container chính gồm:
Container frontend chạy ứng dụng React.
Container backend chạy ứng dụng Spring Boot.
Container ai-service chạy FastAPI.
Container mysql chạy cơ sở dữ liệu MySQL.
Container redis chạy bộ nhớ đệm.
Container airflow-webserver để quản lý DAG.
Container airflow-scheduler để lập lịch pipeline.
Container airflow-worker để thực thi các task.
Các service được cấu hình chung trong Docker Compose. Backend kết nối đến MySQL thông qua biến môi trường như database host, username và password. FastAPI cũng kết nối đến MySQL để lấy dữ liệu phục vụ mô hình AI hoặc nhận dữ liệu từ Airflow. Redis được dùng để lưu cache kết quả dự báo và chỉ số Dashboard.
Trong môi trường thực tế, hệ thống có thể triển khai lên máy chủ cloud. Khi cần mở rộng, các container có thể được quản lý bằng Kubernetes để tự động scale và đảm bảo tính sẵn sàng.
6.3. Triển khai backend Spring Boot
Backend Spring Boot được tổ chức theo mô hình nhiều lớp gồm Controller, Service, Repository và Entity.
Lớp Controller tiếp nhận request từ frontend và trả response về cho người dùng.
Lớp Service xử lý logic nghiệp vụ như tạo đơn hàng, kiểm tra tồn kho, phê duyệt đơn nhập hàng hoặc tính toán trạng thái cảnh báo.
Lớp Repository giao tiếp với cơ sở dữ liệu thông qua Spring Data JPA.
Lớp Entity ánh xạ các bảng trong MySQL thành các đối tượng Java.
Các module backend chính gồm:
Module Authentication xử lý đăng ký, đăng nhập, cấp JWT và phân quyền.
Module Product xử lý sản phẩm, danh mục, hình ảnh và trạng thái kinh doanh.
Module Order xử lý giỏ hàng, đặt hàng, cập nhật trạng thái đơn hàng và lịch sử mua hàng.
Module Inventory xử lý tồn kho, nhập xuất kho, cảnh báo tồn kho và lịch sử biến động kho.
Module Supplier xử lý hồ sơ nhà cung cấp, điểm đánh giá và trạng thái hợp tác.
Module Purchase Order xử lý đơn nhập hàng, duyệt đơn nhập hàng và xác nhận nhận hàng.
Module Dashboard tổng hợp dữ liệu doanh thu, đơn hàng, tồn kho, cảnh báo và kết quả dự báo.
Module AI Integration gọi API từ FastAPI để lấy kết quả dự báo hoặc kích hoạt tính toán theo yêu cầu.
6.4. Triển khai frontend ReactJS
Frontend ReactJS được chia thành hai phần: giao diện khách hàng và giao diện quản trị.
Giao diện khách hàng gồm các trang chính như trang chủ, danh sách sản phẩm, chi tiết sản phẩm, giỏ hàng, thanh toán, đăng nhập, đăng ký và lịch sử đơn hàng.
Giao diện quản trị gồm các trang như Dashboard tổng quan, quản lý sản phẩm, quản lý đơn hàng, quản lý tồn kho, quản lý nhà cung cấp, quản lý đơn nhập hàng, cảnh báo AI và báo cáo thống kê.
Dashboard quản trị cần hiển thị dữ liệu trực quan bằng biểu đồ. Các biểu đồ cần có gồm:
Biểu đồ doanh thu theo ngày, tuần, tháng.
Biểu đồ số lượng đơn hàng.
Biểu đồ top sản phẩm bán chạy.
Biểu đồ so sánh doanh số thực tế và dự báo.
Biểu đồ phân loại sản phẩm ABC-XYZ.
Danh sách cảnh báo sắp hết hàng.
Danh sách sản phẩm tồn kho chậm luân chuyển.
Danh sách Smart PO chờ duyệt.
Frontend gọi API từ Spring Boot để lấy dữ liệu. Token JWT được lưu ở phía client và gửi kèm trong header Authorization khi gọi các API cần xác thực.
6.5. Triển khai AI Service bằng FastAPI
AI Service được xây dựng bằng FastAPI để triển khai các chức năng liên quan đến dự báo và phân tích dữ liệu. FastAPI phù hợp vì nhẹ, tốc độ cao và dễ tích hợp với các thư viện Python như pandas, numpy, scikit-learn, Prophet, TensorFlow hoặc PyTorch.
Các endpoint chính của AI Service gồm:
Endpoint dự báo nhu cầu cho một sản phẩm.
Endpoint dự báo nhu cầu cho toàn bộ sản phẩm.
Endpoint tính sai số mô hình.
Endpoint kích hoạt retraining.
Endpoint phân loại ABC-XYZ.
Endpoint trả về trạng thái phiên bản mô hình.
Quy trình xử lý dự báo trong AI Service gồm:
Nhận product_id hoặc danh sách sản phẩm cần dự báo.
Truy xuất dữ liệu bán hàng lịch sử.
Kiểm tra chất lượng dữ liệu.
Chọn mô hình phù hợp.
Huấn luyện hoặc tải mô hình đã huấn luyện.
Dự báo nhu cầu trong 30 ngày tiếp theo.
Trả kết quả dự báo về backend hoặc lưu trực tiếp vào cơ sở dữ liệu.
Đối với sản phẩm có dữ liệu lịch sử đủ dài, hệ thống có thể sử dụng Prophet hoặc LSTM. Đối với sản phẩm mới, hệ thống dùng Moving Average hoặc mức dự báo mặc định dựa trên nhóm sản phẩm tương tự.
6.6. Triển khai mô hình Prophet
Prophet được sử dụng để dự báo các sản phẩm có dữ liệu bán hàng theo thời gian và có yếu tố mùa vụ. Dữ liệu đầu vào của Prophet cần có hai cột chính: ds là ngày và y là số lượng bán.
Các bước triển khai gồm:
Lấy dữ liệu bán hàng từ sales_logs.
Tổng hợp số lượng bán theo ngày.
Đổi tên cột ngày thành ds và số lượng bán thành y.
Bổ sung thông tin ngày lễ hoặc sự kiện nếu có.
Huấn luyện mô hình Prophet.
Tạo dataframe tương lai cho 30 ngày tiếp theo.
Sinh kết quả dự báo.
Lưu predicted_quantity, lower_bound và upper_bound vào forecast_results.
Ưu điểm của Prophet là dễ triển khai, dễ giải thích và phù hợp với dữ liệu có xu hướng hoặc mùa vụ rõ ràng. Tuy nhiên, Prophet có thể chưa đủ tốt với những dữ liệu có biến động phức tạp hoặc chịu ảnh hưởng mạnh bởi hành vi người dùng.
6.7. Triển khai mô hình LSTM
LSTM được sử dụng cho các sản phẩm có chuỗi bán hàng phức tạp hơn. Mô hình này có khả năng ghi nhớ thông tin trong chuỗi thời gian và học được các quan hệ phi tuyến.
Quy trình triển khai LSTM gồm:
Chuẩn bị dữ liệu bán hàng theo ngày.
Chuẩn hóa dữ liệu bằng MinMaxScaler.
Tạo chuỗi đầu vào theo cửa sổ thời gian, ví dụ dùng 14 ngày gần nhất để dự báo ngày tiếp theo.
Chia dữ liệu thành tập huấn luyện và kiểm thử.
Xây dựng mô hình LSTM gồm các lớp LSTM, Dense và Dropout nếu cần.
Huấn luyện mô hình.
Dự báo 30 ngày tiếp theo theo phương pháp lặp.
Đảo ngược chuẩn hóa để lấy số lượng dự báo thực tế.
Lưu kết quả vào cơ sở dữ liệu.
LSTM có thể cho kết quả tốt hơn trong một số trường hợp phức tạp, nhưng cần nhiều dữ liệu và tài nguyên tính toán hơn Prophet. Vì vậy, hệ thống cần cơ chế lựa chọn mô hình phù hợp thay vì dùng LSTM cho mọi sản phẩm.
6.8. Triển khai tính toán điểm đặt hàng lại
Điểm đặt hàng lại, hay Reorder Point, là ngưỡng tồn kho mà khi số lượng hàng giảm xuống bằng hoặc thấp hơn ngưỡng này thì hệ thống cần đề xuất nhập hàng.
Công thức cơ bản:
ROP = Nhu cầu trung bình mỗi ngày × Thời gian giao hàng trung bình + Tồn kho an toàn
Trong đó:
Nhu cầu trung bình mỗi ngày được tính từ lịch sử bán hàng hoặc kết quả dự báo.
Thời gian giao hàng trung bình được lấy từ dữ liệu nhà cung cấp.
Tồn kho an toàn được tính dựa trên mức độ biến động nhu cầu và mức độ ổn định của nhà cung cấp.
Ví dụ, nếu một sản phẩm bán trung bình 10 sản phẩm mỗi ngày, nhà cung cấp cần 5 ngày để giao hàng và tồn kho an toàn là 20 sản phẩm, thì:
ROP = 10 × 5 + 20 = 70 sản phẩm
Khi tồn kho hiện tại nhỏ hơn hoặc bằng 70, hệ thống tạo cảnh báo và đề xuất nhập hàng.
Việc tính ROP giúp chủ shop tránh tình trạng đặt hàng quá muộn, đặc biệt với những sản phẩm bán chạy hoặc có thời gian giao hàng dài.
6.9. Triển khai phân loại ABC-XYZ
Phân loại ABC được triển khai bằng cách tính giá trị tiêu thụ của từng sản phẩm trong một khoảng thời gian nhất định. Sau đó, hệ thống sắp xếp sản phẩm theo giá trị tiêu thụ giảm dần và tính tỷ trọng lũy kế.
Nhóm A gồm các sản phẩm chiếm khoảng 70-80% tổng giá trị tiêu thụ.
Nhóm B gồm các sản phẩm chiếm khoảng 15-20% tiếp theo.
Nhóm C gồm các sản phẩm còn lại.
Phân loại XYZ được triển khai bằng cách tính hệ số biến thiên nhu cầu. Hệ số biến thiên càng thấp thì nhu cầu càng ổn định.
Nhóm X là nhóm có nhu cầu ổn định.
Nhóm Y là nhóm có nhu cầu biến động trung bình.
Nhóm Z là nhóm có nhu cầu biến động cao.
Sau khi tính xong, hệ thống kết hợp kết quả ABC và XYZ để tạo nhãn phân loại. Ví dụ, một sản phẩm có giá trị tiêu thụ cao và nhu cầu ổn định sẽ được gắn nhãn AX. Sản phẩm có giá trị thấp và nhu cầu biến động mạnh sẽ được gắn nhãn CZ.
Kết quả phân loại được hiển thị trên Dashboard để chủ shop ưu tiên nguồn lực. Nhóm A cần được theo dõi kỹ hơn nhóm C. Nhóm Z cần được nhập hàng thận trọng hơn nhóm X.
6.10. Triển khai Smart Purchase Order
Smart Purchase Order là chức năng tự động tạo gợi ý nhập hàng. Quy trình triển khai gồm:
Đầu tiên, hệ thống kiểm tra danh sách sản phẩm có tồn kho nhỏ hơn hoặc bằng ROP.
Tiếp theo, hệ thống lấy kết quả dự báo nhu cầu 30 ngày tiếp theo của từng sản phẩm.
Sau đó, hệ thống tính số lượng đề xuất nhập hàng. Công thức có thể là:
Số lượng đề xuất = Nhu cầu dự báo trong kỳ + Tồn kho an toàn - Tồn kho hiện tại - Hàng đang đặt
Nếu kết quả nhỏ hơn 0, hệ thống không cần đề xuất nhập.
Sau khi tính số lượng, hệ thống chọn nhà cung cấp phù hợp dựa trên điểm uy tín, giá nhập và thời gian giao hàng.
Hệ thống tạo bản nháp đơn nhập hàng với trạng thái draft. Chủ shop xem bản nháp trên Dashboard, kiểm tra số lượng và nhà cung cấp được đề xuất. Nếu đồng ý, chủ shop phê duyệt. Nếu chưa phù hợp, chủ shop có thể chỉnh sửa.
Sau khi phê duyệt, đơn nhập hàng chuyển sang trạng thái approved hoặc sent. Khi hàng về kho, chủ shop xác nhận nhận hàng, hệ thống cập nhật tồn kho và ghi log nhập kho.
6.11. Triển khai đánh giá nhà cung cấp
Hệ thống đánh giá nhà cung cấp dựa trên dữ liệu thực tế thay vì đánh giá cảm tính. Các tiêu chí chính gồm:
Thời gian giao hàng thực tế so với thời gian cam kết.
Tỷ lệ giao đúng số lượng.
Tỷ lệ sản phẩm lỗi hoặc phải đổi trả.
Mức độ ổn định giá.
Tần suất phản hồi và khả năng đáp ứng đơn hàng.
Mỗi tiêu chí được quy đổi thành điểm từ 0 đến 100. Điểm tổng hợp của nhà cung cấp được tính bằng trung bình có trọng số.
Ví dụ:
Điểm giao hàng chiếm 40%.
Điểm giá cả chiếm 25%.
Điểm chất lượng chiếm 25%.
Điểm phản hồi chiếm 10%.
Nhà cung cấp có điểm cao được ưu tiên trong Smart PO. Nhà cung cấp có điểm thấp có thể bị cảnh báo hoặc chuyển sang trạng thái hạn chế sử dụng.
6.12. Triển khai Dashboard quản trị
Dashboard là nơi chủ shop theo dõi toàn bộ tình hình kinh doanh và chuỗi cung ứng. Dashboard cần đảm bảo dữ liệu dễ hiểu, trực quan và có khả năng hỗ trợ ra quyết định nhanh.
Các chỉ số cần hiển thị gồm:
Doanh thu hôm nay, tuần này và tháng này.
Số lượng đơn hàng.
Số sản phẩm bán ra.
Tổng giá trị tồn kho.
Số sản phẩm sắp hết hàng.
Số sản phẩm tồn kho chậm luân chuyển.
Top sản phẩm bán chạy.
Top sản phẩm có nguy cơ hết hàng.
Biểu đồ dự báo nhu cầu 30 ngày.
Danh sách Smart PO chờ duyệt.
Dashboard cần hỗ trợ lọc theo thời gian, danh mục, sản phẩm và trạng thái cảnh báo. Với các dữ liệu cần tải nhanh, hệ thống lấy từ Redis. Với các báo cáo chi tiết, hệ thống truy vấn MySQL.
6.13. Triển khai vòng lặp phản hồi và retraining
Vòng lặp phản hồi là cơ chế giúp hệ thống ngày càng thông minh hơn. Sau mỗi chu kỳ bán hàng, dữ liệu thực tế được đưa ngược lại vào hệ thống để đánh giá dự báo trước đó.
Quy trình gồm:
Hệ thống lấy doanh số thực tế của ngày vừa qua.
Hệ thống lấy kết quả dự báo tương ứng đã được tạo trước đó.
Hệ thống tính sai số bằng các chỉ số như MAE, RMSE hoặc MAPE.
Nếu sai số nằm trong ngưỡng cho phép, hệ thống tiếp tục sử dụng mô hình hiện tại.
Nếu sai số vượt ngưỡng, hệ thống đánh dấu mô hình cần retrain.
Airflow kích hoạt quy trình huấn luyện lại.
Mô hình mới được đánh giá trên tập kiểm thử.
Nếu mô hình mới tốt hơn, hệ thống cập nhật phiên bản mô hình.
Nếu mô hình mới không tốt hơn, hệ thống giữ nguyên mô hình cũ.
Cơ chế này giúp hệ thống thích nghi với thay đổi của thị trường, ví dụ khi sản phẩm trở thành xu hướng mới, khi nhu cầu giảm đột ngột hoặc khi hành vi khách hàng thay đổi sau các chương trình khuyến mãi.
6.14. Triển khai kiểm thử hệ thống
Kiểm thử là bước quan trọng để đảm bảo hệ thống hoạt động chính xác. Các nhóm kiểm thử gồm:
Kiểm thử đơn vị cho các hàm xử lý nghiệp vụ như tính ROP, tính số lượng nhập hàng, tính điểm nhà cung cấp và tính phân loại ABC-XYZ.
Kiểm thử API để đảm bảo các endpoint backend và AI Service trả về dữ liệu đúng định dạng.
Kiểm thử tích hợp để đảm bảo frontend, backend, database, Redis, FastAPI và Airflow hoạt động cùng nhau.
Kiểm thử hiệu năng để đánh giá thời gian phản hồi của Dashboard, API tạo đơn hàng và API dự báo.
Kiểm thử bảo mật để đảm bảo người dùng không thể truy cập chức năng ngoài quyền hạn.
Kiểm thử dữ liệu để đảm bảo pipeline xử lý đúng dữ liệu thiếu, dữ liệu trùng và dữ liệu sai định dạng.
6.15. Triển khai giám sát và ghi log
Hệ thống cần ghi log đầy đủ để dễ phát hiện và xử lý lỗi.
Backend ghi log các request quan trọng, lỗi nghiệp vụ, lỗi truy vấn cơ sở dữ liệu và lỗi xác thực.
AI Service ghi log quá trình chạy mô hình, thời gian huấn luyện, sai số mô hình và lỗi dữ liệu.
Airflow ghi log từng task trong DAG, bao gồm thời gian bắt đầu, thời gian kết thúc, trạng thái thành công hoặc thất bại.
MySQL cần được sao lưu định kỳ để tránh mất dữ liệu.
Prometheus và Grafana có thể được sử dụng để giám sát tài nguyên hệ thống, thời gian phản hồi API, số lượng task Airflow thất bại và trạng thái container.
6.16. Kết luận chương 6
Chương 6 đã trình bày chi tiết quá trình triển khai hệ thống AI-SCM từ môi trường chạy, backend, frontend, AI Service, Data Pipeline đến các thuật toán hỗ trợ ra quyết định. Hệ thống được triển khai theo hướng module hóa, trong đó mỗi thành phần đảm nhận một nhiệm vụ cụ thể.
Spring Boot xử lý nghiệp vụ lõi, ReactJS cung cấp giao diện tương tác, FastAPI triển khai mô hình AI, MySQL lưu trữ dữ liệu chính, Redis tăng tốc truy cập và Airflow điều phối pipeline tự động.
Thông qua các chức năng như dự báo nhu cầu, tính điểm đặt hàng lại, phân loại ABC-XYZ, đánh giá nhà cung cấp và Smart Purchase Order, hệ thống có thể hỗ trợ chủ shop đưa ra quyết định nhập hàng chính xác hơn, giảm nguy cơ cháy hàng, hạn chế tồn kho chết và tối ưu hóa dòng tiền trong quá trình kinh doanh.