Bỏ qua để đến Nội dung

Kiểm soát version BOQ và báo giá: hết cảnh nhiều file "final" trôi nổi trên Zalo

BOQ_v1, BOQ_v2_sua, BOQ_final, BOQ_final_that — bất kỳ ai làm sales hoặc QS trong ngành nội thất đều quen thuộc với những cái tên file này. Vấn đề không phải là đặt tên file, mà là doanh nghiệp không có cách nào biết đâu mới là phiên bản đúng để gửi khách.
27 tháng 7, 2026 bởi
Kiểm soát version BOQ và báo giá: hết cảnh nhiều file "final" trôi nổi trên Zalo
Fu Nguyễn

Trong một dự án thi công nội thất trung bình, BOQ có thể được chỉnh sửa 5-10 lần trước khi chốt: khách đổi vật liệu, kiến trúc sư sửa bản vẽ, đội QS phát hiện thiếu hạng mục, sales thương lượng giảm giá. Mỗi lần chỉnh sửa tạo ra một file mới, và file đó thường được gửi qua Zalo hoặc email cho nhiều người cùng lúc — sales, QS, PM, đôi khi cả khách hàng. Vấn đề bắt đầu từ đây: không có quy tắc nào xác định phiên bản nào là "phiên bản sống" (working version) và phiên bản nào đã lỗi thời.

Hậu quả của việc thiếu version control

Hậu quả rõ nhất là gửi nhầm báo giá cho khách — một file BOQ cũ với đơn giá đã lỗi thời được gửi đi, khách chốt theo giá đó, và khi phát hiện sai lệch thì doanh nghiệp buộc phải chọn một trong hai lựa chọn tồi: giữ đúng cam kết và chịu lỗ margin, hoặc giải thích lại với khách và làm mất uy tín. Hậu quả thứ hai kín đáo hơn nhưng nguy hiểm không kém: hai nhân sự làm việc trên hai phiên bản BOQ khác nhau mà không biết, dẫn đến báo giá nội bộ và báo giá gửi khách bị lệch nhau, gây khó khăn khi đối chiếu doanh thu và ngân sách sau này.

Ở quy mô 10-30 dự án chạy song song, những sai lệch nhỏ này không phải là ngoại lệ — chúng là hiện tượng thường trực, và mỗi lần xảy ra đều trực tiếp ăn vào margin dự án (mục tiêu ngành thường đặt ở mức trên 25% cho margin dự kiến khi BOQ được duyệt).

Version control không phải là công nghệ phức tạp

Về bản chất, kiểm soát phiên bản BOQ chỉ cần ba nguyên tắc rõ ràng. Một, mỗi lần BOQ thay đổi phải tạo một phiên bản có mã định danh và ngày tạo, không ghi đè lên phiên bản cũ. Hai, chỉ có một phiên bản được đánh dấu là "approved" tại một thời điểm — đây là phiên bản duy nhất được phép dùng để lập báo giá gửi khách. Ba, mọi thay đổi sau khi BOQ đã approved phải đi qua lại quy trình phê duyệt, không được sửa trực tiếp trên file đã duyệt.

Khi ba nguyên tắc này được áp dụng trên một hệ thống có lưu vết (thay vì file Excel gửi qua Zalo), sales luôn biết chắc chắn phiên bản nào để dùng, và doanh nghiệp có thể truy vết lại toàn bộ lịch sử thay đổi BOQ nếu phát sinh tranh chấp với khách sau này.

Ma trận phê duyệt margin — mắt xích còn thiếu

Ngoài version control, phần lớn doanh nghiệp nội thất còn thiếu một cơ chế quan trọng khác: ma trận phê duyệt margin (margin approval matrix). Khi sales có toàn quyền chỉnh giá để chốt đơn nhanh, họ có xu hướng giảm giá để tăng tỷ lệ chuyển đổi báo giá thành đơn hàng (quote-to-order, mục tiêu thường ở khoảng 30%) — nhưng lại không nhìn thấy tác động của mức giảm đó lên margin dự án. Một ma trận phê duyệt đơn giản — ví dụ giảm dưới 5% margin thì sales tự quyết, giảm 5-10% cần trưởng phòng duyệt, giảm trên 10% cần CEO duyệt — giúp doanh nghiệp cân bằng giữa tốc độ chốt đơn và bảo vệ lợi nhuận.

Rút ngắn thời gian ra báo giá mà không đánh đổi độ chính xác

Mục tiêu hợp lý cho thời gian ra báo giá sau khi BOQ được duyệt là dưới 2 ngày. Điều này chỉ khả thi khi báo giá được tạo trực tiếp từ BOQ đã duyệt — thay vì QS xuất BOQ ra Excel, sales copy sang một file báo giá riêng rồi tự tính lại đơn giá và điều khoản thương mại. Mỗi lần dữ liệu phải "nhảy" từ hệ thống này sang hệ thống khác là một điểm có thể phát sinh sai số và mất thời gian. Khi báo giá được sinh trực tiếp từ BOQ với cùng một bộ dữ liệu, doanh nghiệp vừa rút ngắn được thời gian, vừa loại bỏ rủi ro sai lệch giữa hai tài liệu vốn phải luôn khớp nhau.

Chia sẻ bài này
Thẻ
Lưu trữ