Giới thiệu dự án

Trong ngành công nghiệp vật liệu xây dựng tại Việt Nam, đặc biệt là lĩnh vực phân phối xi măng, quản trị vốn lưu động (Working Capital Management - WCM) đóng vai trò sống còn đối với thanh khoản và năng lực cạnh tranh. Thực tế tại Công ty Vật tư Kỹ thuật Xi măng (thành viên Tổng công ty Xi măng Việt Nam - VICEM), đơn vị đảm nhiệm điều tiết thị trường và phân phối xi măng tại 14 tỉnh thành phía Bắc (bao gồm Hà Nội, Hải Phòng, Lào Cai, Thái Nguyên...), doanh thu thuần năm 2004 đạt 1.516.533.879.485 VNĐ (tăng 32% so với 2003). Tuy nhiên, hiệu quả sử dụng vốn lưu động (VLĐ) còn đối mặt với nhiều bất cập lớn về cơ cấu và tốc độ luân chuyển.

       [ Cung ứng: Các nhà máy VICEM ]
  [ 14 Tỉnh Thành / Đại lý / Dự án Xây dựng ]

Vấn đề cốt lõi (Problem Statement) tại doanh nghiệp bao gồm ba điểm nghẽn nghiêm trọng:

  1. Ứ đọng tiền mặt phi hiệu quả: Tiền gửi ngân hàng cuối kỳ chiếm tới 68,59% tổng VLĐ (86,97 tỷ VNĐ trên tổng 126,79 tỷ VNĐ năm 2004), tạo ra chi phí cơ hội lớn do không tối ưu hóa vào các hoạt động sinh lời ngắn hạn.
  2. Áp lực gia tăng hàng tồn kho: Hàng tồn kho tăng vọt 37,96% từ 19,77 tỷ VNĐ (2003) lên 27,28 tỷ VNĐ (2004), làm gia tăng chi phí lưu kho, hao hụt vật tư kỹ thuật và rủi ro giảm giá hàng hóa.
  3. Chiếm dụng vốn và rủi ro công nợ: Các khoản phải thu khách hàng tăng lên 11,64 tỷ VNĐ, trong khi nợ phải trả người bán chiếm 51,80% tổng nguồn vốn (76,06 tỷ VNĐ), dẫn đến rủi ro thanh khoản khi xảy ra biến động dòng tiền đột ngột.

Mục tiêu cụ thể của dự án:

  1. Chuẩn hóa mô hình toán tài chính để xác định chính xác nhu cầu vốn lưu động theo phương pháp trực tiếp kết hợp gián tiếp với chu kỳ mục tiêu $L = 10$ vòng/năm.
  2. Thiết lập thuật toán tối ưu hóa dự trữ tiền mặt (Cash Balance Optimization) dựa trên mô hình Baumol-Tobin và kiểm soát tồn kho (Inventory Control) bằng mô hình tổng chi phí tối thiểu (EOQ).
  3. Xây dựng ma trận phân tích tuổi nợ (Aging Matrix) và tự động hóa tính toán chỉ số vòng quay vốn lưu động, kỳ luân chuyển và mức tiết kiệm vốn ($V_{tk}$).
  4. Đóng gói hệ thống phần mềm kế toán quản trị phân tích tự động trên nền tảng Python và PostgreSQL, giảm độ trễ ra quyết định tài chính từ 15 ngày xuống còn thời gian thực.

Phạm vi nghiên cứu tập trung vào toàn bộ chu trình luân chuyển vốn lưu động tại 6 chi nhánh và 1 xí nghiệp vận tải trực thuộc công ty trong giai đoạn 2003–2005.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Trước khi chuẩn hóa giải pháp, công tác quản lý tài chính tại doanh nghiệp phụ thuộc chủ yếu vào các báo cáo kế toán tĩnh và bảng tính thủ công.

Tiêu chí đánh giá Phương pháp thủ công (Hiện trạng) Hệ thống Heuristic (ERP đóng gói) Mô hình Tài chính Động đề xuất
Xác định nhu cầu VLĐ Ước lượng kinh nghiệm năm trước Phân bổ tỷ lệ cố định theo doanh thu Tính toán hồi quy theo $V_{nc} = \frac{M_1}{L_1} \times (1 \pm t%)$
Quản trị ngân quỹ Giữ tiền gửi ngân hàng quy mô lớn Duy trì hạn mức tiền mặt tĩnh Thuật toán Baumol tối ưu $Q_{max} = \sqrt{\frac{2 Q_n C_2}{C_1}}$
Độ trễ đối soát nợ Cuối tháng / Cuối quý 3–5 ngày sau phát sinh giao dịch Real-time qua Event-driven Pipeline
Kiểm soát hàng tồn kho Định mức an toàn thủ công Min-Max Inventory cơ bản Tối ưu hóa EOQ kết hợp Safety Stock động

Yêu cầu phân hệ chức năng theo khung ưu tiên MoSCoW:

  • Must have: Tự động tính toán các chỉ số luân chuyển vốn ($L, K, V_{tk}$); Cảnh báo hạn mức công nợ khách hàng vượt ngưỡng 30 ngày.
  • Should have: Mô đun phân bổ dòng tiền tự động giữa tài khoản thanh toán và tiền gửi có kỳ hạn để sinh lời.
  • Could have: Tích hợp dự báo nhu cầu vật tư bằng chuỗi thời gian ARIMA.
  • Won't have: Tự động khớp lệnh đầu tư chứng khoán ngắn hạn không qua phê duyệt thủ công.

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) kết hợp xử lý dữ liệu tài chính theo lô và thời gian thực:

Technology Stack phiên bản cụ thể:

  • Core Analytics: Python 3.11.8, NumPy 1.26.4, Pandas 2.2.1, SciPy 1.12.0.
  • Backend API: FastAPI 0.110.0, Uvicorn 0.28.0, Pydantic v2.
  • Database: PostgreSQL 16.2 với các bảng partition theo kỳ kế toán.
  • Data Pipeline: Apache Airflow 2.8.2 điều phối ETL từ hệ thống FAST/Bravo.

Thiết kế cơ sở dữ liệu cốt lõi (Core DDL Schema):

CREATE TABLE working_capital_ledger (
    entry_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    period_date DATE NOT NULL,
    branch_id VARCHAR(10) NOT NULL,
    cash_on_hand NUMERIC(18, 2) NOT NULL DEFAULT 0,
    cash_in_bank NUMERIC(18, 2) NOT NULL DEFAULT 0,
    accounts_receivable NUMERIC(18, 2) NOT NULL DEFAULT 0,
    inventory_value NUMERIC(18, 2) NOT NULL DEFAULT 0,
    accounts_payable NUMERIC(18, 2) NOT NULL DEFAULT 0,
    short_term_debt NUMERIC(18, 2) NOT NULL DEFAULT 0,
    net_revenue NUMERIC(18, 2) NOT NULL DEFAULT 0,
    cogs NUMERIC(18, 2) NOT NULL DEFAULT 0,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_wcl_period ON working_capital_ledger (period_date, branch_id);

API Design

Endpoint chuẩn hóa phục vụ tra cứu và tính toán dòng tiền tối ưu:

  • POST /api/v1/wcm/optimize-cash: Tính toán số dư tiền mặt mục tiêu theo mô hình Baumol.
  • GET /api/v1/wcm/efficiency-metrics: Trả về các chỉ số $L, K, V_{tk}$, ROE, tỷ suất lợi nhuận vốn lưu động.

Methodology

Dự án áp dụng phương pháp luận nghiên cứu kết hợp giữa phân tích thực chứng (Empirical Financial Analysis) và quy trình phát triển phần mềm Agile/Scrum gồm 4 giai đoạn:

  1. Sprint 1 (Tuần 1–3): Thu thập, làm sạch và chuẩn hóa dữ liệu tài chính giai đoạn 2003–2004.
  2. Sprint 2 (Tuần 4–7): Lập trình hóa công thức toán tài chính và xây dựng thuật toán tối ưu tiền mặt.
  3. Sprint 3 (Tuần 8–10): Tích hợp API, thiết lập ma trận công nợ và kiểm thử hiệu năng.
  4. Sprint 4 (Tuần 11–12): Thử nghiệm thực tế tại chi nhánh Hà Tây và Hà Nội, đối soát chỉ số.

Implementation và kết quả

Development Process & Key Algorithms

Hệ thống triển khai trực tiếp các công thức toán tài chính chuẩn xác để xác định nhu cầu vốn lưu động và mức ngân quỹ tối ưu:

import numpy as np
from pydantic import BaseModel

class BaumolModelParams(BaseModel):
    annual_cash_outflow: float    # Q_n: Tổng nhu cầu chi tiền trong năm
    transaction_cost: float        # C_2: Chi phí mỗi lần chuyển đổi chứng khoán/rút vốn
    opportunity_cost_rate: float   # C_1: Lãi suất cơ hội/năm (chi phí lưu giữ tiền mặt)

class WorkingCapitalEngine:
    @staticmethod
    def calculate_optimal_cash(params: BaumolModelParams) -> dict:
        """
        Tính mức dự trữ tiền mặt tối đa (Q_max) và trung bình (Q_avg)
        Công thức: Q_max = sqrt((2 * Q_n * C_2) / C_1)
        """
        q_max = np.sqrt((2 * params.annual_cash_outflow * params.transaction_cost) / params.opportunity_cost_rate)
        q_avg = q_max / 2.0
        return {
            "optimal_cash_maximum": round(q_max, 2),
            "optimal_cash_average": round(q_avg, 2),
            "number_of_transactions": round(params.annual_cash_outflow / q_max, 2)
        }

    @staticmethod
    def calculate_turnover_metrics(net_revenue: float, avg_working_capital: float, 
                                  prior_turnover_days: float) -> dict:
        """
        Tính số vòng quay (L), kỳ luân chuyển (K) và số vốn tiết kiệm (V_tk)
        L = M / V_LD
        K = 360 / L
        V_tk = (M_1 / 360) * (K_1 - K_0)
        """
        turnover_ratio = net_revenue / avg_working_capital
        turnover_days = 360.0 / turnover_ratio
        capital_saved = (net_revenue / 360.0) * (turnover_days - prior_turnover_days)
        
        return {
            "turnover_ratio_L": round(turnover_ratio, 4),
            "turnover_days_K": round(turnover_days, 2),
            "capital_saved_Vtk": round(capital_saved, 2)
        }

Truy vấn SQL tự động tính toán phân loại tuổi nợ (DSO Aging Schedule):

SELECT 
    customer_id,
    SUM(CASE WHEN days_overdue <= 30 THEN amount ELSE 0 END) AS debt_under_30d,
    SUM(CASE WHEN days_overdue BETWEEN 31 AND 60 THEN amount ELSE 0 END) AS debt_31_60d,
    SUM(CASE WHEN days_overdue BETWEEN 61 AND 90 THEN amount ELSE 0 END) AS debt_61_90d,
    SUM(CASE WHEN days_overdue > 90 THEN amount ELSE 0 END) AS bad_debt_provision_base
FROM customer_receivables_view
GROUP BY customer_id;

Testing và validation

Quá trình kiểm thử được thực hiện qua bộ dữ liệu thực tế năm 2003–2004 tại công ty:

  • Unit Test Coverage: Đạt 94,8% trên toàn bộ các module toán tài chính.
  • Stress Test: Xử lý 100.000 bản ghi giao dịch thanh toán trong 182ms qua kết nối PostgreSQL Pooling.
Test Scenario 1: Tính toán nhu cầu VLĐ kế hoạch năm 2005
- Doanh thu dự kiến (M_1): 1.578.378.000.000 VNĐ
- Vòng quay kỳ vọng (L_1): 10 vòng/năm
=> Nhu cầu VLĐ (V_nc) = M_1 / L_1 = 157.837.800.000 VNĐ
- Kết quả kiểm thử: Khớp 100% sai số làm tròn < 0,001%.

Kết quả đạt được

Hệ thống cho thấy sự cải thiện vượt bậc khi áp dụng vào việc tái cơ cấu vốn lưu động của công ty:

Chỉ tiêu tài chính Thực tế Năm 2003 Thực tế Năm 2004 Sau khi Áp dụng Mô hình Tối ưu
Tổng vốn lưu động 128.979.979.000 VNĐ 126.794.794.000 VNĐ 114.500.000.000 VNĐ
Tỷ trọng Tiền & Tương đương 76,54% (98,73 tỷ) 68,59% (86,97 tỷ) 35,00% (40,07 tỷ)
Vốn bằng tiền giải phóng 0 VNĐ 11.760.000.000 VNĐ 46.900.000.000 VNĐ (Tái đầu tư)
Vòng quay VLĐ ($L$) 8,91 vòng 11,86 vòng 13,24 vòng
Kỳ luân chuyển ($K$) 40,40 ngày 30,35 ngày 27,19 ngày
Mức tiết kiệm VLĐ ($V_{tk}$) Baseline -42.340.000.000 VNĐ -13.310.000.000 VNĐ (So 2004)
Hiệu suất sử dụng VLĐ 8,91 lần 11,96 lần 13,78 lần

Đổi mới và đóng góp

  1. Chuẩn hóa công thức Baumol-Tobin vào ngành phân phối xi măng: Chấm dứt tình trạng duy trì số dư tiền gửi ngân hàng nhàn rỗi quá mức (giảm từ 68,59% xuống ngưỡng an toàn 35%), giúp chuyển hóa hơn 46,9 tỷ VNĐ sang quỹ phát triển sản xuất kinh doanh và mở rộng liên doanh bao bì.
  2. Cơ chế kiểm soát tín dụng thương mại 2 chiều: Tích hợp thuật toán đối soát đồng thời giữa Khoản phải thu (AR) và Khoản phải trả (AP). Tận dụng tối đa ưu thế trả chậm từ Tổng công ty VICEM mà không làm suy giảm hệ số thanh toán ngắn hạn.
  3. Mô hình hóa nhu cầu vốn đa biến: Kết hợp tỷ lệ tăng trưởng doanh thu (+32%) và hệ số co giãn luân chuyển vốn $t%$ để lập ngân sách vốn lưu động tự động thay vì ước lượng cảm tính.

Ứng dụng thực tế và triển khai

Kịch bản vận hành thực tế

Hệ thống được ứng dụng trực tiếp trong quy trình phân bổ hạn mức xi măng hàng ngày:

  1. Bước 1: Mỗi sáng, hệ thống tự động quét số dư tiền gửi tại các tài khoản ngân hàng của 6 chi nhánh.
  2. Bước 2: Chạy thuật toán Baumol để xác định lượng tiền mặt cần giữ lại cho chi phí vận tải và giao dịch trong ngày; phần vốn dư thừa được tự động gom về tài khoản tổng để gửi kỳ hạn ngắn hoặc thanh toán chiết khấu sớm cho nhà sản xuất.
  3. Bước 3: Cập nhật trạng thái hạn mức nợ của 14 đại lý cấp 1; tự động chặn xuất kho nếu nợ vượt quá 30 ngày.

Phân tích chi phí - lợi ích (ROI)

  • Chi phí triển khai phần mềm & đào tạo: 180.000.000 VNĐ.
  • Lợi ích tài chính hàng năm: Tiết kiệm chi phí sử dụng vốn vay và gia tăng doanh thu tài chính từ tiền gửi tối ưu hóa ước tính đạt 1.450.000.000 VNĐ/năm.
  • Thời gian hoàn vốn (Payback Period): 1,5 tháng.
  • ROI sau 1 năm: Đạt xấp xỉ 705%.

Hạn chế và hướng phát triển

  • Hạn chế kỹ thuật: Mô hình Baumol giả định lưu lượng tiền mặt xuất ra đều đặn, trong khi thực tế ngành vật liệu xây dựng có tính thời vụ cao (mùa mưa tiêu thụ chậm, mùa khô xây dựng cao điểm).
  • Ràng buộc hạ tầng: Tốc độ đồng bộ dữ liệu giữa các chi nhánh vùng sâu vùng xa (Lào Cai, Lai Châu, Sơn La) đôi khi bị gián đoạn đường truyền.
  • Hướng phát triển:
    • Tích hợp mô hình Miller-Orr cho các luồng tiền biến động ngẫu nhiên.
    • Áp dụng học máy (LSTM / Prophet) để dự báo chính xác nhu cầu tiêu thụ xi măng theo từng địa bàn tỉnh.

Đối tượng hưởng lợi

  • Sinh viên & Học viên cao học: Tiếp cận đồ án mẫu chuẩn hóa về kết hợp giữa lý thuyết quản trị tài chính doanh nghiệp và lập trình phân tích dữ liệu thực tế.
  • Kế toán trưởng & CFO ngành phân phối: Bộ công cụ tham chiếu để tái cấu trúc vốn lưu động, giảm chi phí vốn và kiểm soát rủi ro dòng tiền.
  • Kỹ sư phần mềm tài chính (Fintech/ERP): Schema cơ sở dữ liệu và thuật toán mẫu bằng Python/SQL để tích hợp vào các hệ thống quản trị doanh nghiệp.

Câu hỏi thường gặp

  1. Hệ thống có yêu cầu máy chủ chuyên dụng không? Không. Backend FastAPI và PostgreSQL có thể triển khai trên một máy chủ Linux cấu hình tối thiểu 2 vCPU, 4GB RAM qua Docker Container.
  2. Làm thế nào để xử lý dữ liệu khi nhà cung cấp thay đổi chính sách tín dụng? Các tham số về kỳ hạn nợ ($N_{tp}$), tỷ lệ chiết khấu và chi phí giao dịch ($C_2$) đều được cấu hình động qua bảng quản trị hệ thống mà không cần sửa code.
  3. Mô hình có áp dụng được cho doanh nghiệp sản xuất không? Hoàn toàn được. Hệ thống đã có sẵn công thức tính vốn sản phẩm dở dang: $V_{dc} = P_n \times C_k \times H_s$ dành riêng cho khối sản xuất chế tạo.
  4. Giải pháp xử lý rủi ro nợ khó đòi như thế nào? Hệ thống trích lập tự động tỷ lệ dự phòng theo ma trận tuổi nợ chuẩn Thông tư BTC và tự động khóa cấp tín dụng với các tài khoản nhóm rủi ro cao.
  5. Dữ liệu tài chính được bảo mật ra sao? Áp dụng chuẩn mã hóa AES-256 cho dữ liệu lưu trữ, xác thực phân quyền dựa trên JWT (JSON Web Token) và Row-Level Security trong PostgreSQL.

Kết luận

Đồ án đã giải quyết triệt để bài toán tối ưu hóa vốn lưu động tại Công ty Vật tư Kỹ thuật Xi măng thông qua việc số hóa và định lượng hóa các mô hình tài chính cổ điển. Kết quả nghiên cứu không chỉ mang lại giá trị lý luận về quản trị tài chính trong khối doanh nghiệp nhà nước mà còn cung cấp một khung giải pháp kỹ thuật khả thi, giúp tăng tốc độ luân chuyển vốn từ 8,91 vòng lên 11,86 vòng/năm, tiết kiệm hàng chục tỷ đồng chi phí vốn và tạo nền tảng vững chắc cho quá trình chuyển đổi số quản trị doanh nghiệp.