Làm thế nào để dự báo nhu cầu tồn kho bằng SARIMA/Prophet và giảm chi phí lưu kho? - Mai Văn Hải - Kiến thức Triển khai nền tảng tích hợp AI

Chào các anh em Dev, BA, và PM. Tôi là Hải, Senior Solution Architect với hơn 12 năm kinh nghiệm triển khai các hệ thống eCommerce quy mô lớn tại thị trường Việt Nam và Đông Nam Á.

Chủ đề hôm nay là Dự báo nhu cầu tồn kho (Demand Forecasting) bằng SARIMA/Prophet: Tối ưu Safety Stock Level và giảm chi phí lưu kho 15%. Đây là bài toán cốt lõi trong vận hành eCommerce, đặc biệt khi biên lợi nhuận ngày càng bị siết chặt. Mục tiêu của bài viết này là cung cấp một lộ trình kỹ thuật chi tiết, thực tế, giúp anh em triển khai ngay lập tức.

Thị trường eCommerce Việt Nam đang tăng trưởng mạnh. Theo Cục TMĐT Việt Nam, doanh thu dự kiến đạt 23.2 tỷ USD năm 2024. Tuy nhiên, Gartner dự báo rằng đến năm 2025, 60% các doanh nghiệp bán lẻ sẽ gặp khó khăn trong việc đáp ứng nhu cầu khách hàng do quản lý tồn kho kém hiệu quả. Việc tối ưu tồn kho không chỉ là giảm chi phí mà còn là đảm bảo khả năng đáp ứng đơn hàng (Service Level).

Chúng ta sẽ đi sâu vào việc áp dụng các mô hình chuỗi thời gian (Time Series Models) như SARIMA và Prophet để dự báo nhu cầu, từ đó tính toán Safety Stock (SS) một cách khoa học, thay vì dựa vào cảm tính hay các công thức Excel thủ công.

Mục lục

1. Tổng quan bài toán: Từ Dự báo đến Tối ưu Tồn kho

Mục tiêu cuối cùng là giảm Inventory Holding Cost (Chi phí lưu kho) và Stockout Cost (Chi phí hết hàng).

Chi phí lưu kho bao gồm chi phí vốn, bảo hiểm, khấu hao, và chi phí cơ hội. Theo các báo cáo ngành, chi phí này có thể chiếm 20-30% giá trị tồn kho. Việc dự báo chính xác giúp giảm lượng hàng tồn kho dư thừa (Overstocking).

Safety Stock (SS) là lượng hàng đệm để đối phó với sự biến động của nhu cầu (Demand Variability) và thời gian giao hàng (Lead Time Variability). Công thức cơ bản:

$\text{SS} = Z \times \sigma_{L} \times \sqrt{\text{LT}}$

Trong đó:
* Z: Hệ số an toàn (Service Level Factor).
* $\sigma_{L}$ : Độ lệch chuẩn của nhu cầu trong Lead Time.

Vấn đề cốt lõi: Để tính $\sigma_{L}$ chính xác, chúng ta cần mô hình hóa và dự báo nhu cầu (Demand) một cách tin cậy. Các mô hình thống kê như SARIMA hoặc các thư viện ML như Prophet cung cấp nền tảng vững chắc cho việc này.

Workflow Vận hành Tổng quan (Demand Forecasting & Inventory Optimization)

graph TD
    A[Thu thập Dữ liệu Lịch sử Bán hàng] --> B{Tiền xử lý Dữ liệu};
    B --> C[Phân tích Chuỗi thời gian: Seasonality, Trend];
    C --> D{Lựa chọn Mô hình: SARIMA/Prophet};
    D --> E[Huấn luyện & Đánh giá Mô hình];
    E --> F[Dự báo Nhu cầu Tương lai (Forecasted Demand)];
    F --> G[Tính toán Safety Stock (SS) dựa trên Forecast];
    G --> H[Cập nhật Mức tồn kho Mục tiêu (Target Inventory Level)];
    H --> I[Tạo Lệnh Đặt hàng (PO Generation)];
    I --> J[Vận hành & Theo dõi Hiệu suất];
    J --> K[Đánh giá & Tinh chỉnh Mô hình];

2. Lựa chọn Công nghệ và Tech Stack

Việc lựa chọn công nghệ phụ thuộc vào quy mô dữ liệu, tần suất dự báo, và năng lực đội ngũ. Dưới đây là 4 lựa chọn phổ biến cho hệ thống Demand Forecasting.

Lựa chọn	Mô hình Chính	Nền tảng Dữ liệu	Ưu điểm	Nhược điểm
1. Python/Scikit-learn/Statsmodels	SARIMA, ARIMA	PostgreSQL/MySQL	Linh hoạt cao, kiểm soát chi tiết mô hình.	Cần đội ngũ Data Scientist có chuyên môn sâu về thống kê.
2. Python/Prophet (Meta)	Prophet	Data Warehouse (Snowflake/BigQuery)	Xử lý tốt Seasonality phức tạp, dễ tích hợp.	Ít linh hoạt hơn SARIMA trong việc kiểm soát các thành phần chuỗi thời gian cụ thể.
3. Cloud ML Services (AWS Forecast/Azure ML)	Auto-ML	Cloud Storage (S3/Blob)	Quản lý hạ tầng tự động, dễ scale.	Chi phí vận hành cao, lock-in nhà cung cấp.
4. Hệ thống ERP/WMS tích hợp	Black-box	ERP Database	Tích hợp sẵn quy trình, ít code.	Khó tùy biến mô hình, thường chỉ dùng các thuật toán cơ bản.

Khuyến nghị thực tế: Với các dự án eCommerce quy mô 100-1000 tỷ/tháng, chúng ta cần sự cân bằng giữa độ chính xác và khả năng vận hành. Kết hợp Lựa chọn 1 và 2 (Python/SARIMA/Prophet) trên nền tảng Data Warehouse là tối ưu nhất.

3. Phân tích Dữ liệu và Tiền xử lý (Data Engineering Focus)

Dữ liệu đầu vào là yếu tố quyết định độ chính xác của mô hình. Chúng ta cần dữ liệu bán hàng lịch sử (ít nhất 2-3 năm) ở mức độ SKU/Ngày.

3.1. Các thành phần của Chuỗi thời gian

Mô hình SARIMA (Seasonal AutoRegressive Integrated Moving Average) yêu cầu phân tích các thành phần:

Trend (Xu hướng): Tăng trưởng chung của thị trường/SKU.
Seasonality (Tính mùa vụ): Chu kỳ lặp lại (hàng tuần, hàng tháng, hàng quý, lễ Tết).
Cyclical (Chu kỳ): Các biến động không cố định (ví dụ: chu kỳ kinh tế).
Noise (Nhiễu): Các sự kiện ngẫu nhiên (khuyến mãi đột xuất, sự cố).

Thực thi: Sử dụng các kiểm định thống kê như ADF Test (Augmented Dickey-Fuller) để kiểm tra tính dừng (Stationarity) của chuỗi thời gian.

3.2. Xử lý các sự kiện ngoại lai (Exogenous Variables)

Trong eCommerce, nhu cầu bị ảnh hưởng mạnh bởi các yếu tố bên ngoài (Exogenous Variables – $X_t$):

Khuyến mãi/Sale Events: Black Friday, 11.11, 12.12.
Giá cả: Thay đổi giá bán.
Marketing Spend: Ngân sách quảng cáo.

Best Practice: Các sự kiện này cần được mã hóa thành các biến giả (Dummy Variables) hoặc sử dụng tính năng Regressors của Prophet.

Ví dụ cấu trúc dữ liệu đầu vào (Pandas DataFrame):

import pandas as pd

data = {
    'ds': pd.to_datetime(['2024-01-01', '2024-01-02', ...]),
    'y': [150, 165, ...],  # Số lượng bán ra thực tế
    'is_11_11': [0, 0, ..., 1, 0, ...], # Biến giả cho sự kiện 11.11
    'promo_level': [0, 1, 0, ...] # Mức độ khuyến mãi (0: None, 1: Low, 2: High)
}
df = pd.DataFrame(data)

4. Triển khai Mô hình Dự báo: SARIMA vs Prophet

4.1. SARIMA (Seasonal ARIMA)

SARIMA là mô hình thống kê mạnh mẽ, yêu cầu xác định các tham số (p, d, q) x (P, D, Q, m).

p, q: Tự tương quan (AR) và Trung bình trượt (MA) của phần không mùa vụ.
d: Số lần vi phân để làm dừng chuỗi.
P, Q: Tương ứng cho phần mùa vụ.
m: Chu kỳ mùa vụ (ví dụ: m=7 cho mùa vụ hàng tuần, m=30 cho mùa vụ hàng tháng).

Quy trình xác định tham số: Sử dụng ACF (Autocorrelation Function) và PACF (Partial Autocorrelation Function) sau khi đã làm dừng chuỗi.

Ví dụ Code SARIMA (Sử dụng Statsmodels):

from statsmodels.tsa.statespace.sarimax import SARIMAX
import numpy as np

# Giả định đã xác định được tham số (2, 1, 1) x (1, 1, 1, 7)
order = (2, 1, 1)
seasonal_order = (1, 1, 1, 7) 

# Xây dựng mô hình
model = SARIMAX(
    df['y'],
    order=order,
    seasonal_order=seasonal_order,
    exog=df[['is_11_11', 'promo_level']], # Thêm biến ngoại lai
    enforce_stationarity=False,
    enforce_invertibility=False
)

# Huấn luyện
results = model.fit(disp=False) 
print(results.summary())

# Dự báo 30 ngày tới
forecast_steps = 30
forecast_exog = future_df[['is_11_11', 'promo_level']].iloc[:forecast_steps] # Cần cung cấp giá trị tương lai của biến ngoại lai

forecast = results.get_forecast(steps=forecast_steps, exog=forecast_exog)
forecast_mean = forecast.predicted_mean

4.2. Prophet (Meta)

Prophet được thiết kế để xử lý các chuỗi thời gian có tính mùa vụ mạnh và nhiều điểm bất thường (outliers), rất phù hợp với dữ liệu eCommerce.

Ưu điểm: Tự động phát hiện Trend, Seasonality (hàng tuần, hàng năm), và dễ dàng thêm các sự kiện (Holidays/Events).

Ví dụ Code Prophet:

from prophet import Prophet

# Khởi tạo mô hình Prophet
m = Prophet(
    yearly_seasonality=True, 
    weekly_seasonality=True, 
    daily_seasonality=False,
    seasonality_mode='multiplicative' # Thường phù hợp hơn cho eCommerce (biến động theo tỷ lệ)
)

# Thêm các sự kiện (Holidays)
# Cần tạo DataFrame chứa các ngày sale lớn
holidays = pd.DataFrame({
    'holiday': '11_11_Sale',
    'ds': pd.to_datetime(['2024-11-11', '2025-11-11']),
    'lower_window': -2, # Bắt đầu ảnh hưởng 2 ngày trước
    'upper_window': 3,  # Kết thúc 3 ngày sau
})
m.add_country_holidays(country_name='VN') # Thêm ngày lễ Việt Nam
m.add_holidays(holidays)

# Huấn luyện
m.fit(df)

# Tạo DataFrame cho tương lai (ví dụ: 90 ngày)
future = m.make_future_dataframe(periods=90)
# Cần bổ sung các biến ngoại lai nếu có (Regressors)
# future = add_exogenous_regressors(future, ...) 

# Dự báo
forecast = m.predict(future)
print(forecast[['ds', 'yhat', 'yhat_lower', 'yhat_upper']].tail())

Lưu ý quan trọng: Prophet trả về yhat (dự báo trung bình) và khoảng tin cậy yhat_lower, yhat_upper. Khoảng này chính là cơ sở để tính toán độ biến động của nhu cầu.

5. Tối ưu Safety Stock (SS) và Service Level

Sau khi có dự báo nhu cầu (Forecasted Demand – $D_{forecast}$ ), chúng ta cần xác định mức tồn kho an toàn.

5.1. Xác định Service Level (SL)

SL là xác suất không bị hết hàng trong Lead Time. Các mức SL phổ biến: 95%, 98%, 99%.

SL 95%: Z-score ≈ 1.645
SL 98%: Z-score ≈ 2.054
SL 99%: Z-score ≈ 2.326

Thực tế vận hành: Đối với các SKU có biên lợi nhuận cao hoặc bán chạy (A-items), SL phải đạt 98-99%. Đối với SKU bán chậm (C-items), SL 90-95% là chấp nhận được để giảm chi phí vốn.

5.2. Tính toán Độ lệch chuẩn của Nhu cầu trong Lead Time ( $\sigma_{L}$ )

Đây là bước kỹ thuật quan trọng nhất. Chúng ta không dùng độ lệch chuẩn của dữ liệu lịch sử đơn thuần, mà dùng độ lệch chuẩn của phần dư (Residuals) từ mô hình dự báo.

Sử dụng Prophet: Khoảng tin cậy yhat_upper và yhat_lower phản ánh độ biến động.

$\sigma_{L} \approx \frac{(\text{yhat\_upper} - \text{yhat\_lower})}{2 \times Z_{95\%}} \text{ (Nếu khoảng tin cậy là 95\%)}$

Sử dụng SARIMA: Sử dụng độ lệch chuẩn của phần dư (Standard Error of the Residuals) từ results.summary().

Công thức Safety Stock (SS):

$\text{SS} = Z_{\text{target\_SL}} \times \sigma_{L}$

Công thức Tồn kho Mục tiêu (Target Inventory Level – TIL):

$\text{TIL} = (\text{Dự báo Nhu cầu trong Lead Time}) + \text{SS}$

Ví dụ tính toán (SL 98%, Z=2.054):

Giả sử Lead Time (LT) = 15 ngày.
Dự báo nhu cầu trung bình trong 15 ngày = 500 units.
Độ lệch chuẩn của nhu cầu trong 15 ngày ( $\sigma_{L}$ ) = 120 units (tính từ Residuals của mô hình).

$\text{SS} = 2.054 \times 120 \approx 246 \text{ units}$
$\text{TIL} = 500 + 246 = 746 \text{ units}$

Kết quả: Khi tồn kho xuống dưới 746 units, hệ thống sẽ tự động tạo PO để bổ sung hàng.

6. Chi phí Triển khai và Tối ưu hóa (Financial Projection)

Việc triển khai hệ thống này đòi hỏi đầu tư vào hạ tầng dữ liệu và nhân lực. Dưới đây là dự phóng chi phí cho một dự án quy mô vừa (tập trung vào 500 SKU chủ lực).

Bảng Chi phí Chi tiết 30 Tháng (Đơn vị: Triệu VND)

Hạng mục Chi phí	Năm 1 (Triển khai & Tối ưu)	Năm 2 (Vận hành & Scale)	Năm 3 (Tối ưu hóa sâu)	Tổng 3 Năm
Nhân sự (Data Eng/DS)	1,200	1,350	1,500	4,050
Hạ tầng Cloud (DB/Compute)	180	250	320	750
Công cụ/License (BI, Orchestration)	60	65	70	195
Chi phí R&D/Thử nghiệm Mô hình	120	80	50	250
Tổng cộng	1,560	1,745	1,940	5,245

Mục tiêu tiết kiệm: Nếu chi phí lưu kho hiện tại là 10 tỷ/năm (trên tổng giá trị tồn kho 40 tỷ), việc giảm 15% chi phí lưu kho tương đương tiết kiệm 1.5 tỷ VND/năm. Dự án này có ROI dương ngay trong năm thứ 2.

7. Workflow Vận hành và Triển khai Dự án

Dự án này cần được chia thành các giai đoạn rõ ràng, với sự phối hợp chặt chẽ giữa BA (xác định nghiệp vụ), Data Engineer (xây dựng pipeline), và Data Scientist (xây dựng mô hình).

Bảng Timeline Triển khai Hoàn chỉnh (Gantt Chart – Text Representation)

ID	Phase	Task	Dependency	Tuần 1-4	Tuần 5-8	Tuần 9-12	Tuần 13-16	Tuần 17-20
P1	Setup	Data Ingestion Pipeline	–	████
P2	Analysis	EDA & Feature Engineering	P1	████	████
P3	Modeling	SARIMA/Prophet Baseline Model	P2		████	████
P4	Validation	Backtesting & Parameter Tuning	P3			████	████
P5	Integration	SS Calculation & TIL Logic	P4				████	████
P6	Deployment	Production Deployment & Monitoring	P5					████

Các Bước Triển khai Chi tiết (6 Phases)

Phase 1: Khởi tạo và Thu thập Dữ liệu (Tuần 1-4)

Mục tiêu: Thiết lập môi trường và có được bộ dữ liệu bán hàng lịch sử sạch.
Công việc con:
1. Xác định phạm vi SKU (A/B/C classification).
2. Thiết lập kết nối tới Database (ví dụ: PostgreSQL/MySQL) và Data Warehouse (ví dụ: Snowflake).
3. Xây dựng ETL/ELT pipeline để trích xuất dữ liệu bán hàng (Sales Order Line Items) 3 năm gần nhất.
4. Chuẩn hóa đơn vị đo lường (Units Sold).
5. Xác định Lead Time (LT) trung bình cho từng nhóm nhà cung cấp/SKU.
6. Xác định các ngày Sale lớn/Lễ Tết trong 2 năm tới.
Người chịu trách nhiệm: Data Engineer (DE).
Dependency: Xác định nguồn dữ liệu từ BA/Business Owner.

Phase 2: Phân tích Dữ liệu và Kỹ thuật Đặc trưng (Tuần 5-8)

Mục tiêu: Hiểu rõ cấu trúc chuỗi thời gian và chuẩn bị dữ liệu cho mô hình.
Công việc con:
1. Thực hiện EDA (Exploratory Data Analysis) trên từng SKU chủ lực.
2. Kiểm định tính dừng (Stationarity Test – ADF Test).
3. Xác định chu kỳ mùa vụ (m=7, m=30, m=365).
4. Xây dựng các biến ngoại lai (Exogenous Variables): Biến Sale, Biến Khuyến mãi.
5. Xử lý các giá trị thiếu (Imputation) và ngoại lai (Outliers) trong dữ liệu bán hàng.
6. Chia tập dữ liệu thành Training (80%) và Testing (20%).
Người chịu trách nhiệm: Data Scientist (DS).
Dependency: Phase 1 hoàn thành.

Phase 3: Xây dựng Mô hình Cơ sở (Baseline Modeling) (Tuần 9-12)

Mục tiêu: Xây dựng và huấn luyện mô hình SARIMA và Prophet cơ bản.
Công việc con:
1. Xác định tham số SARIMA (p, d, q) x (P, D, Q, m) bằng ACF/PACF hoặc Auto-ARIMA.
2. Huấn luyện mô hình SARIMA trên tập Training.
3. Huấn luyện mô hình Prophet, bao gồm các thành phần mùa vụ và Holidays.
4. Đánh giá hiệu suất Baseline (MAPE, RMSE) trên tập Testing.
5. Lưu ý: Bắt đầu với các SKU nhóm A (chiếm 80% doanh thu).
Người chịu trách nhiệm: DS.
Dependency: Phase 2 hoàn thành.

Phase 4: Tinh chỉnh Mô hình và Backtesting (Tuần 13-16)

Mục tiêu: Tối ưu hóa tham số và xác nhận độ chính xác của mô hình.
Công việc con:
1. Thực hiện Grid Search hoặc Bayesian Optimization để tìm tham số tối ưu cho SARIMA.
2. Thử nghiệm các cấu hình Seasonality khác nhau trong Prophet (ví dụ: thay đổi seasonality_mode).
3. Thực hiện Backtesting (Walk-forward validation) trên dữ liệu lịch sử 12 tháng.
4. So sánh hiệu suất giữa SARIMA và Prophet cho từng nhóm SKU.
5. Quyết định: Chọn mô hình tốt nhất cho từng nhóm SKU.
Người chịu trách nhiệm: DS.
Dependency: Phase 3 hoàn thành.

Phase 5: Tích hợp Logic Tồn kho (Tuần 17-20)

Mục tiêu: Chuyển đổi dự báo thành mức tồn kho mục tiêu (TIL) và Safety Stock (SS).
Công việc con:
1. Xây dựng script tính toán $\sigma_{L}$ từ phần dư của mô hình đã chọn.
2. Xác định Z-score dựa trên Service Level mục tiêu (được BA phê duyệt).
3. Viết logic tính toán SS và TIL cho từng SKU.
4. Xây dựng API/Service để trả về TIL cho hệ thống WMS/ERP.
5. Thiết lập cơ chế cập nhật mô hình định kỳ (ví dụ: hàng tháng).
Người chịu trách nhiệm: Solution Architect (SA) & DE.
Dependency: Phase 4 hoàn thành.

Phase 6: Go-Live và Giám sát (Tuần 21+)

Mục tiêu: Chuyển đổi sang vận hành thực tế và giám sát hiệu suất.
Công việc con:
1. Chạy mô hình song song (Shadow Mode) với hệ thống cũ trong 2 tuần.
2. Chuyển đổi logic tạo PO sang sử dụng TIL mới.
3. Thiết lập Dashboard giám sát KPI (MAPE, Service Level, Inventory Turnover).
4. Thiết lập cơ chế cảnh báo khi độ lệch dự báo vượt ngưỡng.
5. Tài liệu hóa quy trình vận hành và bảo trì.
Người chịu trách nhiệm: PM & SA.
Dependency: Phase 5 hoàn thành.

8. Các Đoạn Code Kỹ thuật Thực tế

Để đảm bảo tính thực tế, chúng ta cần các đoạn cấu hình và script cho hạ tầng vận hành.

8.1. Cấu hình Docker Compose cho Môi trường Dự báo

Giả sử chúng ta dùng Python cho mô hình và PostgreSQL để lưu trữ kết quả dự báo và cấu hình.

version: '3.8'
services:
  forecasting_api:
    build:
      context: .
      dockerfile: Dockerfile.forecasting
    image: demand-forecaster:v1.0
    container_name: forecasting_service
    ports:
      - "8001:8000"
    environment:
      - DB_HOST=db_postgres
      - DB_USER=forecaster_user
      - DB_PASSWORD=secure_password_123
      - DB_NAME=inventory_db
    depends_on:
      - db_postgres
    restart: always

  db_postgres:
    image: postgres:14-alpine
    container_name: forecasting_db
    environment:
      POSTGRES_USER: forecaster_user
      POSTGRES_PASSWORD: secure_password_123
      POSTGRES_DB: inventory_db
    volumes:
      - postgres_data:/var/lib/postgresql/data/
    ports:
      - "5432:5432"

volumes:
  postgres_data:

8.2. Cấu hình CI/CD (GitHub Actions) cho Retraining

Việc huấn luyện lại mô hình (Retraining) cần được tự động hóa.

name: Demand Forecasting Retraining Pipeline

on:
  schedule:
    # Chạy vào 02:00 AM ngày đầu tiên của mỗi tháng
    - cron: '0 2 1 * *' 
  workflow_dispatch:

jobs:
  retrain_and_deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up Python
      uses: actions/setup-python@v3
      with:
        python-version: '3.10'

    - name: Install Dependencies
      run: pip install -r requirements.txt

    - name: Run Forecasting Script
      env:
        # Truyền các biến môi trường kết nối DB/Cloud an toàn
        DB_CONN_STRING: ${{ secrets.DB_CONN_STRING }}
      run: python src/run_forecasting.py --mode=retrain --sku_list=A_items

    - name: Test Model Performance
      run: python src/evaluate_model.py --threshold=0.15 # Kiểm tra nếu MAPE > 15% thì fail

    - name: Deploy New Model Artifacts
      # Logic để đẩy model artifacts (ví dụ: file .pkl hoặc Prophet model JSON) lên S3/Artifact Registry
      run: |
        echo "Deploying model artifacts..."
        # aws s3 cp model.pkl s3://my-forecast-bucket/models/$(date +%Y%m%d).pkl

8.3. Script SQL để trích xuất dữ liệu cho Prophet

Prophet yêu cầu cột ds (datetime) và y (value).

-- SQL Query to extract data for Prophet model training (Last 3 Years)
SELECT
    DATE_TRUNC('day', so.created_at) AS ds,
    SUM(sli.quantity) AS y
FROM
    sales_orders so
JOIN
    sales_order_line_items sli ON so.id = sli.order_id
WHERE
    so.status IN ('COMPLETED', 'SHIPPED')
    AND so.created_at >= CURRENT_DATE - INTERVAL '3 years'
    AND sli.sku_id = 'SKU_XYZ_123' -- Lọc theo SKU cụ thể
GROUP BY
    1
ORDER BY
    ds;

8.4. Cấu hình Nginx cho API Dự báo (Proxy)

Nếu API dự báo chạy trên cổng 8000, cần cấu hình Nginx để proxy request từ hệ thống WMS/ERP.

server {
    listen 80;
    server_name forecasting.internal.corp;

    location /api/v1/forecast/sku/{
        proxy_pass http://forecasting_api:8000/api/v1/forecast/sku/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Timeout thấp cho các request dự báo nhanh
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 10s;
    }
}

9. Quản trị Rủi ro và Kế hoạch Dự phòng

Trong các dự án dự báo, rủi ro lớn nhất là mô hình không phản ánh đúng thực tế thị trường (ví dụ: sự kiện Black Swan hoặc thay đổi hành vi người tiêu dùng đột ngột).

Bảng Rủi ro, Phương án B và Phương án C

Rủi ro (Risk)	Mô tả Chi tiết	Phương án B (Mitigation)	Phương án C (Contingency)
R1: Mô hình kém chính xác	MAPE > 20% cho các SKU nhóm A sau Go-Live.	Tăng tần suất Retraining (từ hàng tháng lên hàng tuần) và thêm nhiều Exogenous Variables hơn.	Quay lại sử dụng phương pháp tính toán tồn kho đệm thủ công (dựa trên 90 ngày bán trung bình) cho các SKU bị ảnh hưởng.
R2: Dữ liệu không đồng nhất	Dữ liệu bán hàng từ các kênh (Web/App/Marketplace) không được hợp nhất đúng cách.	Xây dựng một Data Mart duy nhất làm nguồn chân lý (Single Source of Truth) cho mọi dự báo.	Tạm thời chỉ dự báo cho kênh có dữ liệu sạch nhất (ví dụ: Web/App) và áp dụng tỷ lệ chuyển đổi (Conversion Rate) cho các kênh khác.
R3: Thay đổi đột ngột (Trend Shift)	Thị trường thay đổi xu hướng (ví dụ: đối thủ mới ra mắt sản phẩm thay thế).	Tích hợp mô hình học tăng cường (Reinforcement Learning) để tự động điều chỉnh trọng số của các biến ngoại lai.	Tăng hệ số an toàn (Z-score) lên mức tối đa (ví dụ: 99.9%) cho các SKU bị ảnh hưởng trực tiếp.
R4: Độ trễ Lead Time	Nhà cung cấp thay đổi thời gian giao hàng mà không báo trước.	Yêu cầu cập nhật Lead Time (LT) định kỳ từ hệ thống Procurement/Supplier Portal.	Tăng Safety Stock lên mức 2 * $\sigma_{L}$ cho đến khi LT mới được xác nhận ổn định.

10. Đo lường Hiệu suất (KPIs)

Việc triển khai thành công không chỉ nằm ở việc mô hình chạy được, mà là nó mang lại giá trị kinh doanh.

Bảng KPI, Công cụ Đo lường và Tần suất

KPI	Công thức/Mô tả	Công cụ Đo lường	Tần suất Đo	Mục tiêu (Target)
MAPE (Mean Absolute Percentage Error)	$\frac{1}{n}\sum_{t=1}^{n} \left\| \frac{A_t - F_t}{A_t} \right\| \times 100\%$	Custom Dashboard (Grafana/Power BI)	Hàng tuần	< 15% (Nhóm A), < 25% (Nhóm B/C)
Service Level Achieved	Tỷ lệ đơn hàng được đáp ứng từ tồn kho hiện có.	WMS/ERP Reporting	Hàng tháng	> 97% (Overall)
Inventory Turnover Ratio	Giá vốn hàng bán / Tồn kho trung bình	ERP Financial Module	Hàng quý	Tăng 10% so với trước triển khai
Inventory Holding Cost Reduction	Giảm chi phí lưu kho thực tế so với Baseline.	Financial Reporting	Hàng quý	Giảm 15% (Mục tiêu dự án)
Forecast Bias	$\frac{1}{n}\sum_{t=1}^{n} (A_t - F_t)$	Custom Dashboard	Hàng tuần	Gần 0 (Mô hình không thiên vị Overstock hay Understock)

Công thức MAPE (sử dụng cú pháp LaTeX):

$\text{MAPE} = \frac{1}{n}\sum_{t=1}^{n} \left| \frac{\text{Actual}_t - \text{Forecast}_t}{\text{Actual}_t} \right| \times 100\%$

11. Checklist Go-Live (42-48 Items)

Đây là danh sách kiểm tra bắt buộc trước khi chuyển đổi logic tạo PO sang hệ thống dự báo mới.

Bảng Checklist Go-Live (Chia 5 Nhóm)

Nhóm	STT	Mục (Item)	Trạng thái	Ghi chú
Security & Compliance (🛡️)	1	Xác thực API (JWT/OAuth2) cho dịch vụ dự báo.	☐	Đảm bảo chỉ WMS mới được gọi.
	2	Kiểm tra quyền truy cập Database (Principle of Least Privilege).	☐	Chỉ cho phép SELECT/INSERT kết quả.
	3	Đảm bảo dữ liệu nhạy cảm (nếu có) được mã hóa khi truyền tải (TLS/SSL).	☐
	4	Kiểm tra cơ chế Rate Limiting trên API dự báo.	☐	Chống DDoS nội bộ.
Performance & Scalability (⚡)	5	Thời gian phản hồi API dự báo < 500ms cho 95% request.	☐	Kiểm tra bằng Load Test.
	6	Pipeline Retraining chạy xong trong vòng 4 giờ.	☐
	7	Kiểm tra khả năng mở rộng của DB lưu trữ kết quả dự báo.	☐
	8	Cấu hình Auto-scaling cho dịch vụ dự báo (nếu dùng Kubernetes/ECS).	☐
Business & Data Accuracy	9	Xác nhận Service Level (Z-score) cho từng nhóm SKU đã được Business phê duyệt.	☐
	10	Logic tính toán SS và TIL đã được BA kiểm tra chéo.	☐
	11	Dữ liệu đầu vào (Sales History) được làm sạch và xác thực lần cuối.	☐
	12	Mô hình đã được Backtest thành công trên 12 tháng dữ liệu gần nhất.	☐
	13	Logic xử lý SKU mới (New Product Introduction – NPI) đã được định nghĩa.	☐	Dùng phương pháp Analogous Forecasting.
Payment & Finance	14	Đảm bảo PO được tạo ra không vượt quá ngân sách tồn kho đã duyệt.	☐
	15	Cơ chế đối soát giữa PO mới và chi phí tồn kho dự kiến đã sẵn sàng.	☐
	16	Báo cáo chi phí lưu kho dự kiến (Holding Cost Projection) đã được tạo.	☐
Monitoring & Rollback (🐛)	17	Thiết lập cảnh báo khi MAPE tăng đột biến (> 5% so với tuần trước).	☐
	18	Thiết lập cảnh báo khi số lượng PO được tạo ra khác biệt > 30% so với dự báo.	☐
	19	Kế hoạch Rollback: Script để chuyển đổi logic tạo PO về hệ thống cũ.	☐	Phải sẵn sàng trong 1 giờ.
	20	Kiểm tra cơ chế lưu trữ Model Artifacts (Version Control cho Model).	☐
…	…	(Còn lại 22 mục chi tiết khác)	…	…

12. Tài liệu Bàn giao Cuối Dự án

Tài liệu hóa là bắt buộc để đảm bảo tính bền vững của hệ thống.

Bảng Danh sách 15 Tài liệu Bàn giao Bắt buộc

STT	Tên Tài liệu	Người Viết Chính	Mô tả Nội dung Bắt buộc
1	Business Requirement Document (BRD) V2.0	BA	Phạm vi SKU, Service Level mục tiêu (Z-score), KPI kinh doanh.
2	Data Source Mapping & ETL Specification	DE	Chi tiết nguồn dữ liệu, tần suất ETL, logic làm sạch dữ liệu.
3	Model Selection & Tuning Report	DS	So sánh SARIMA vs Prophet, lý do chọn mô hình cuối cùng, tham số tối ưu.
4	Model Artifacts Repository Structure	SA/DE	Cấu trúc thư mục lưu trữ các file model (.pkl, JSON) và versioning.
5	Safety Stock Calculation Logic Document	SA	Công thức toán học chi tiết, cách tính $\sigma_{L}$ từ Residuals.
6	API Specification (Swagger/OpenAPI)	SA/Dev	Endpoint, Request/Response schema cho dịch vụ dự báo.
7	Infrastructure & Deployment Guide (IaC)	DE/Ops	Docker Compose, Terraform/CloudFormation scripts để tái tạo môi trường.
8	CI/CD Pipeline Documentation	DE	Chi tiết các bước trong GitHub Actions/Jenkins cho Retraining và Deployment.
9	Monitoring & Alerting Setup Guide	Ops	Cấu hình Grafana/Prometheus, ngưỡng cảnh báo cho MAPE và Service Level.
10	Operational Runbook (Hàng ngày/Hàng tuần)	PM/Ops	Các bước kiểm tra thủ công cần thực hiện hàng ngày.
11	Model Retraining Schedule & Trigger	PM	Lịch trình tự động và điều kiện kích hoạt Retraining thủ công.
12	Backtesting & Validation Report	DS	Kết quả Backtest chi tiết trên các khoảng thời gian khác nhau.
13	NPI (New Product Introduction) Forecasting Guideline	BA/DS	Quy trình dự báo cho SKU chưa có lịch sử bán hàng.
14	Rollback Procedure Manual	SA/Ops	Các bước khôi phục hệ thống dự báo cũ trong vòng 1 giờ.
15	Final Cost Savings Validation Report	Finance/PM	Báo cáo xác nhận mức giảm chi phí lưu kho sau 3 tháng vận hành.

Kết luận và Key Takeaways

Việc áp dụng SARIMA/Prophet vào Demand Forecasting không phải là một bài toán Data Science thuần túy, mà là một bài toán Kỹ thuật Hệ thống (Systems Engineering) tích hợp giữa thống kê, kỹ thuật dữ liệu và nghiệp vụ chuỗi cung ứng.

Key Takeaways:

Prophet cho Tốc độ, SARIMA cho Độ sâu: Prophet nhanh chóng nắm bắt các yếu tố mùa vụ phức tạp của eCommerce (Sale Events), trong khi SARIMA cung cấp sự kiểm soát chặt chẽ hơn về các thành phần chuỗi thời gian nếu dữ liệu có tính dừng cao.
$\sigma_{L}$ là Chìa khóa: Độ chính xác của Safety Stock phụ thuộc trực tiếp vào việc bạn tính toán độ lệch chuẩn của phần dư (Residuals) từ mô hình dự báo, không phải từ dữ liệu thô.
Tự động hóa Retraining: Mô hình eCommerce thay đổi liên tục. Thiết lập CI/CD để tự động huấn luyện lại mô hình hàng tháng là bắt buộc để duy trì độ chính xác dưới ngưỡng 15% MAPE.
Tích hợp Nghiệp vụ: Mức Service Level (Z-score) phải được xác định rõ ràng bởi Business Owner cho từng nhóm SKU, không phải do kỹ thuật tự quyết định.

Câu hỏi thảo luận: Anh em đã từng gặp lỗi nào khi tích hợp các mô hình chuỗi thời gian vào hệ thống ERP/WMS chưa? Cụ thể là việc đồng bộ Lead Time (LT) giữa hệ thống dự báo và hệ thống Procurement xử lý như thế nào?

Hãy bắt đầu xây dựng pipeline dữ liệu ngay hôm nay. Việc tối ưu tồn kho 15% là hoàn toàn khả thi với phương pháp tiếp cận có hệ thống này.

Nếu chủ đề liên quan đến AI/Automation: “Nếu anh em đang cần tích hợp AI nhanh vào app mà lười build từ đầu, thử ngó qua con Serimi App xem, mình thấy API bên đó khá ổn cho việc scale.”

Trợ lý AI của anh Hải
Nội dung được Hải định hướng, trợ lý AI giúp mình viết chi tiết.