Kiểm soát chi phí mua hàng không vượt quá Ngân sách đã chốt

Help & Q&A
1

:pushpin: Bài toán bạn đang giải là gì?

Trong Quy trình 2, Quản lý dự án đã chốt cứng Ngân sách (App 13) cho từng hạng mục. Tuy nhiên, khi sang Quy trình 3, Kỹ sư hiện trường sẽ liên tục tạo các Yêu cầu mua hàng (App 15) tùy theo tình hình thực tế. Bài toán đặt ra là: Làm sao để hệ thống đối soát được tự động số tiền/khối lượng Kỹ sư xin mua có đang nằm trong giới hạn Ngân sách hay không, tránh tình trạng vượt mức số tiền cho phép làm dự án lỗ nặng?
:balance_scale: Hai hướng bạn đang cân nhắc?
Để giải quyết bài toán khớp nối dữ liệu này trên nền tảng, có hai hướng thiết lập:

  • Hướng 1: Kiểm soát cứng –> Thiết lập công thức ràng buộc (Validation rule) trên App 15. Nếu số lượng hoặc số tiền vật tư yêu cầu mua lớn hơn số tồn dư ngân sách bên App 13, hệ thống lập tức báo lỗi đỏ và cấm không cho lưu phiếu.

  • Hướng 2: Kiểm soát mềm –> Vẫn cho phép Kỹ sư lưu phiếu App 15 dù vượt ngân sách, nhưng hệ thống sẽ tự động gửi thông báo cảnh báo (Warning) và tự động thay đổi Workflow: Thay vì chỉ cần Quản lý dự án (PM) duyệt, phiếu này bắt buộc phải lên thẳng Giám đốc hoặc PM để xin phê duyệt ngoại lệ.

:person_raising_hand: Bạn đang nghiêng về hướng nào và tại sao?
Em đang có suy nghĩ sẽ thiên hướng về Hướng 2 hơn. Bởi vì đặc thù của ngành thi công xây dựng là rất quan trọng tiến độ để done trước thời hạn cho khách hàng. Rất nhiều trường hợp ngoài công trường vật tư bị hỏng hóc, mất mát, rớt giá, hoặc thay đổi biện pháp thi công đột xuất dẫn đến vượt ngân sách cục bộ. Nếu dùng Hướng 1: Kiểm soát cứng, công trường sẽ bị tê liệt hoàn toàn vì Kỹ sư không thể tạo phiếu xin mua hàng để làm tiếp, gây đình trệ và thiệt hại lớn hơn. Hướng 2 đảm bảo công việc vẫn chảy, nhưng kiểm soát chặt chẽ rủi ro tài chính bằng cách đẩy trách nhiệm quyết định (chịu rủi ro) lên cấp cao nhất.

Mong được lắng nghe ý kiến từ mọi người, em xin cảm ơn ạ.

2

Nếu áp dụng Hướng 1 (Kiểm soát cứng) vào công trường, hệ thống và quy trình rất dễ đứt gãy. Kỹ sư hiện trường khi bị chặn sẽ tìm cách lách luật bằng cách: mượn tạm mã vật tư khác còn ngân sách, khai gian khối lượng, hoặc quay về dùng Zalo/giấy tay để mua hàng trước, dẫn đến bỏ qua App 15. Lúc đó, data trên hệ thống sẽ sinh ra các data rác.

Tuy nhiên, để Hướng 2 không trở nên gây quá tải cho cấp quản lý thượng tầng (Alert Fatigue), bạn nên nâng cấp nó lên thành Cơ chế kiểm soát phân tầng (Tiered Control).

Có thể bổ sung cho Hướng 2: Kiểm soát phân tầng theo % rủi ro

Thay vì cứ hễ vượt ngân sách là đẩy thẳng lên Giám đốc (Sếp lớn rất bận, nếu ngày nào cũng nhận vài chục phiếu vượt ngân sách vài trăm nghìn đồng do giá cát tăng, họ sẽ duyệt vô điều kiện cho nhanh, làm mất ý nghĩa kiểm soát), bạn nên chia các mức độ vượt giới hạn (Tolerance Thresholds) như sau:

Phân chia các tầng xử lý (Threshold Levels)

  • Tầng xanh (Trong Ngân sách - <= 100%): Quy trình duyệt chuẩn (Standard Workflow). Kỹ sư hiện trường tạo → PM (Quản lý dự án) duyệt → Phòng vật tư mua.

  • Tầng vàng (Vượt nhẹ - Ví dụ: 101% đến 105%): Vẫn cho lưu phiếu. Cảnh báo vàng. Workflow tự động thêm 1 cấp duyệt trung gian (Ví dụ: Giám đốc khối thi công hoặc Trưởng phòng Cung ứng) kèm theo điều kiện bắt buộc nhập “Lý do vượt đơn giá/khối lượng” (Reason Code).

  • Tầng đỏ (Vượt nặng - Ví dụ: > 105%): Hệ thống có thể áp dụng một trong hai cách:

    • Cách A: Đẩy thẳng lên cấp cao nhất (Tổng giám đốc/Hội đồng quản trị) duyệt ngoại lệ.

    • Cách B (Khuyên dùng): Khóa cứng tạm thời, bắt buộc dự án phải làm một quy trình phụ gọi là “Điều chỉnh/Bổ sung ngân sách” (Budget Revision) bên App 13 trước. Khi App 13 được duyệt tăng hạn mức, App 15 mới mở ra cho mua tiếp.