9 giờ sáng thứ Hai, CEO một công ty thi công nội thất mở laptop, chuẩn bị họp giao ban với các chỉ huy trưởng công trình. Câu hỏi đầu tiên rất đơn giản: "Công trình Vinhomes đang lãi bao nhiêu?" Không ai trả lời được ngay. PM phải mở file Excel cá nhân, kế toán phải lục lại email duyệt tạm ứng, còn số liệu vật tư mới nhất thì đang nằm trong một đoạn tin nhắn Zalo từ tối hôm qua. Cuộc họp giao ban biến thành buổi đối chiếu số liệu kéo dài 40 phút, và cuối cùng ba con số đưa ra vẫn lệch nhau.
Đây không phải tình huống hiếm gặp. Với phần lớn doanh nghiệp thiết kế và thi công nội thất tại Việt Nam, đặc biệt ở quy mô 20–200 nhân sự đang tăng trưởng nhanh, dữ liệu công trình tồn tại ở khắp nơi — trừ một nơi mà CEO có thể tin tưởng để ra quyết định.
Một buổi sáng thứ Hai điển hình
Hãy hình dung công ty đang triển khai song song 6 công trình: 2 căn hộ cao cấp, 1 văn phòng, 1 showroom, 2 biệt thự. Mỗi công trình có một PM phụ trách, và mỗi PM có một cách quản lý dữ liệu riêng — vì không ai quy định phải làm khác đi.
PM công trình A dùng một file Excel theo dõi tiến độ, tự thiết kế cột theo thói quen cá nhân. PM công trình B dùng Excel nhưng cấu trúc cột hoàn toàn khác, vì học từ công ty cũ. Nhóm thi công tại hiện trường báo cáo khối lượng hoàn thành qua ảnh chụp gửi Zalo, không kèm số liệu định lượng theo BOQ. Bộ phận mua hàng gửi yêu cầu duyệt ngân sách qua email, không ai lưu lại thành một luồng phê duyệt có thể tra cứu lại. Kế toán tổng hợp công nợ vào cuối tháng bằng cách gọi điện hỏi từng PM "công trình này đã thu được bao nhiêu rồi".
Không ai làm sai quy trình — vì không có quy trình nào được viết ra. Mỗi người đang làm điều hợp lý nhất trong phạm vi hiểu biết của mình. Vấn đề nằm ở cấp hệ thống, không nằm ở cấp cá nhân.
Vì sao dữ liệu công trình bị vỡ vụn thành nhiều mảnh
Có bốn nguyên nhân gốc rễ lặp lại ở hầu hết doanh nghiệp thi công nội thất đang trong giai đoạn mở rộng quy mô:
Không có nguồn dữ liệu chính thức (single source of truth). Khi công ty chỉ có 1–2 công trình, một file Excel dùng chung là đủ. Khi số công trình tăng lên 5, 10, mỗi PM tự nhân bản file mẫu và chỉnh sửa theo ý mình. Không ai được giao vai trò Data Owner — người chịu trách nhiệm định nghĩa cấu trúc dữ liệu chuẩn và đảm bảo mọi người dùng đúng cấu trúc đó.
Không có mã hóa dữ liệu thống nhất. Mã công trình, mã khách hàng, mã hạng mục trong BOQ được đặt tự do theo thói quen từng người. Cùng một hạng mục "Tủ bếp trên" có thể xuất hiện dưới ba tên gọi khác nhau ở ba công trình, khiến việc gộp số liệu toàn công ty gần như bất khả thi nếu không làm thủ công.
Kênh trao đổi không phải là kênh lưu trữ. Zalo và email được thiết kế để trao đổi nhanh, không được thiết kế để làm hệ thống dữ liệu có cấu trúc. Một quyết định duyệt phát sinh (Variation Order) nằm lẫn trong 200 tin nhắn của một nhóm chat sẽ gần như không thể tra cứu lại sau ba tháng, kể cả khi người ra quyết định vẫn nhớ mình từng duyệt.
Không có kiểm soát phiên bản. File "BOQ_congtrinh_A_final.xlsx", "BOQ_congtrinh_A_final_v2.xlsx", "BOQ_congtrinh_A_final_v2_sua.xlsx" cùng tồn tại trên máy của ba người khác nhau. Không ai chắc chắn bản nào là bản được duyệt cuối cùng để thi công.
Hình 1: Dữ liệu công trình phân tán trên nhiều kênh không liên kết với nhau — mỗi nguồn là một mảnh ghép rời rạc mà không ai chịu trách nhiệm hợp nhất.
Hậu quả không chỉ là "mất thời gian tổng hợp"
Nhiều CEO chấp nhận sống chung với tình trạng này vì nghĩ cái giá phải trả chỉ là vài giờ họp mỗi tuần. Thực tế, dữ liệu phân tán tạo ra bốn hệ quả tài chính cụ thể, âm thầm bào mòn lợi nhuận công trình.
1. Sai lệch giữa Budget, Actual Cost và Committed Cost. Khi ngân sách baseline chuyển từ BOQ sang từng hạng mục theo WBS được lập trên Excel của PM, còn chi phí thực tế (Actual Cost) và chi phí đã cam kết nhưng chưa chi (Committed Cost — tức các PO đã phát nhưng chưa nghiệm thu) nằm rải rác ở bộ phận mua hàng và kế toán, không ai nhìn thấy bức tranh tổng cùng lúc. Kết quả: công trình có thể đang âm thầm vượt ngân sách 15–20% mà CEO chỉ phát hiện ra khi công trình gần nghiệm thu, lúc không còn dư địa xử lý.
2. Phát sinh (Variation Order) trôi mất, không thu được tiền. Khi yêu cầu thay đổi từ khách hàng chỉ được trao đổi miệng hoặc qua Zalo, không có Change Request Form và không cập nhật vào hồ sơ hợp đồng, đội thi công vẫn làm thêm hạng mục — nhưng đến khi xuất hóa đơn cuối công trình, không có căn cứ để thu tiền phát sinh. Công ty làm thêm việc, khách hàng không trả thêm tiền.
3. Hồ sơ nghiệm thu và thanh toán bị chậm vì thiếu bằng chứng tập trung. Khối lượng hoàn thành nằm trong ảnh Zalo, không được đối chiếu định kỳ với BOQ và tiến độ. Đến milestone thanh toán, đội dự án phải quay lại tìm ảnh, tìm tin nhắn, dựng lại hồ sơ nghiệm thu từ đầu — trễ hồ sơ trung bình vài ngày đến vài tuần, kéo dài vòng quay công nợ (DSO) và ảnh hưởng trực tiếp dòng tiền.
4. CEO ra quyết định portfolio dựa trên cảm giác, không dựa trên số liệu. Không có bức tranh lãi/lỗ theo thời gian thực của từng công trình, CEO không biết nên dồn nguồn lực vào công trình nào, nên từ chối dự án nào, nên đàm phán lại điều khoản nào với nhà cung cấp. Quyết định chiến lược bị trì hoãn hoặc dựa trên trực giác thay vì dữ liệu.
Một tình huống minh họa
Đây là ví dụ minh họa mang tính mô phỏng, không phải số liệu thống kê chính thức, chỉ nhằm hình dung quy mô tác động.
Một công trình thi công nội thất biệt thự có ngân sách baseline 4,2 tỷ đồng theo BOQ đã duyệt. Trong quá trình thi công, khách hàng yêu cầu đổi vật liệu ốp tường và mở rộng khu vực bếp — hai thay đổi được PM đồng ý qua tin nhắn để "kịp tiến độ", không lập Change Request Form, không có phê duyệt bằng văn bản. Chi phí phát sinh ước tính 180 triệu đồng.
Đến khi nghiệm thu, đội kế toán không tìm được căn cứ để đưa hai khoản phát sinh này vào hóa đơn cuối. Khách hàng chỉ đồng ý thanh toán theo đúng BOQ ban đầu vì "không có văn bản nào xác nhận thay đổi". Công ty gánh 180 triệu đồng chi phí phát sinh, tương đương gần 4,3% giá trị hợp đồng — biến một công trình có biên lợi nhuận dự kiến 12% xuống còn khoảng 7,7%. Nguyên nhân không phải do đội thi công làm sai, mà do không có nơi nào ghi nhận và kiểm soát Variation Order một cách có hệ thống.
Vì sao Excel, Zalo và Email không thể mở rộng theo quy mô công trình
Excel, Zalo và Email đều là công cụ tốt — cho đúng việc chúng được sinh ra để làm. Vấn đề xuất hiện khi doanh nghiệp dùng chúng để làm việc mà chúng không được thiết kế để làm: quản lý dữ liệu vận hành xuyên suốt nhiều công trình, nhiều phòng ban, nhiều thời điểm.
Ba giới hạn cốt lõi:
Không có một phiên bản dữ liệu duy nhất. Mỗi file Excel là một bản sao độc lập. Khi PM sửa file trên máy mình, kế toán không biết bản mới nhất là bản nào, dẫn đến việc mọi báo cáo tổng hợp đều là "ảnh chụp cũ" tại thời điểm ai đó gửi file đi.
Không có luồng phê duyệt có thể truy vết. Một quyết định duyệt chi, duyệt VO, duyệt thay đổi thiết kế trên Zalo hoặc email không gắn với hồ sơ dự án, không có dấu vết ai duyệt, khi nào, với điều kiện gì — nên khi có tranh chấp hoặc cần kiểm toán nội bộ, gần như không có gì để đối chiếu.
Không kết nối được với số liệu tài chính thực tế. Excel tại công trường không tự động phản ánh hóa đơn đã ghi nhận ở kế toán, PO đã phát ở mua hàng, hay khoản đã thu ở công nợ. Muốn có bức tranh Budget–Actual–Committed–ETC–EAC đầy đủ, ai đó phải copy-paste thủ công từ nhiều nguồn — công việc dễ sai và luôn chậm hơn thực tế vài ngày đến vài tuần.
Hình 2: Khác biệt giữa mô hình dữ liệu rời rạc hiện tại và mô hình có nguồn dữ liệu chính thức, Data Owner và báo cáo tập trung cho CEO.
5 việc CEO có thể làm ngay trong quý này — chưa cần đổi hệ thống
Chuẩn hóa dữ liệu không bắt đầu bằng việc mua phần mềm. Nó bắt đầu bằng việc thiết lập kỷ luật dữ liệu tối thiểu, có thể làm được ngay cả khi công ty vẫn đang dùng Excel.
1. Chỉ định Data Owner cho từng loại dữ liệu. Ai chịu trách nhiệm về dữ liệu BOQ chuẩn? Ai chịu trách nhiệm về danh mục nhà cung cấp? Ai chịu trách nhiệm về mã công trình? Mỗi loại dữ liệu cần một người sở hữu rõ ràng, không phải "ai tiện thì sửa".
2. Chọn một nguồn dữ liệu chính thức cho mỗi loại thông tin. Ví dụ: BOQ baseline chỉ được coi là hợp lệ khi nằm trong thư mục dự án dùng chung, có số revision, có người phê duyệt — không phải bản nào PM đang mở trên máy mình.
3. Đặt quy tắc mã hóa tối thiểu cho công trình, khách hàng, hạng mục BOQ. Không cần phần mềm phức tạp — một bảng mã hóa thống nhất trong Google Sheet dùng chung, được Data Owner kiểm soát, đã đủ để loại bỏ phần lớn tình trạng "cùng một hạng mục, ba tên gọi khác nhau".
4. Bắt buộc mọi yêu cầu thay đổi (VO) phải có Change Request Form bằng văn bản. Không quan trọng form đơn giản đến đâu — quan trọng là mọi thay đổi phạm vi đều được ghi nhận, có người duyệt, có căn cứ để tính vào hồ sơ thanh toán cuối cùng.
5. Tổ chức một buổi review dữ liệu 30 phút mỗi tuần. Không phải để họp tiến độ — mà để hỏi riêng một câu: "Dữ liệu công trình tuần này có đang được cập nhật đúng nguồn, đúng người, đúng thời điểm không?" Buổi review ngắn này thường lộ ra vấn đề trước khi nó biến thành hồ sơ tranh chấp hoặc công nợ khó đòi.
Hình 3: Lộ trình ba bước để chuyển từ dữ liệu rời rạc sang nền tảng vận hành tập trung.
Từ chuẩn hóa dữ liệu thủ công đến nền tảng ERP
Năm việc trên giúp doanh nghiệp kiểm soát được phần lớn rủi ro trong ngắn hạn, nhưng có giới hạn tự nhiên: chúng vẫn dựa vào kỷ luật con người, không có cơ chế bắt buộc và không tự động tổng hợp số liệu real-time. Khi số công trình tăng lên, khi đội ngũ mở rộng, khi khách hàng đòi hỏi báo cáo tiến độ minh bạch hơn, kỷ luật thủ công sẽ dần quá tải.
Đây là lúc một nền tảng ERP đóng vai trò là nơi lưu trữ duy nhất cho BOQ, ngân sách, PO, VO, tiến độ và công nợ — nơi Data Owner định nghĩa cấu trúc một lần, mọi phòng ban nhập liệu vào cùng một hệ thống, và CEO có báo cáo lãi/lỗ theo từng công trình cập nhật theo thời gian thực thay vì phải chờ họp giao ban thứ Hai để biết.
Đây cũng chính là nội dung khóa học nền tảng "Tổng quan ERP cho công ty thiết kế & thi công nội thất" đang có trên AI-X — giúp CEO và đội ngũ quản lý hình dung rõ cách một công ty nội thất vận hành trên ERP, trước khi bước vào các SOP chi tiết hơn về ngân sách, mua hàng, tiến độ và Variation Order.
Kết luận
Dữ liệu phân tán trên Excel, Zalo và Email không phải là vấn đề công nghệ — đó là vấn đề quản trị. Doanh nghiệp không cần chờ đến khi đủ ngân sách triển khai ERP mới bắt đầu xử lý. Việc có thể làm ngay trong quý này là: chỉ định người sở hữu dữ liệu, thống nhất một nguồn chính thức, và bắt buộc mọi thay đổi phạm vi phải được ghi nhận bằng văn bản.
Ba việc đơn giản này không giải quyết triệt để bài toán, nhưng đủ để CEO ngừng phải đoán xem công trình nào đang lãi, công trình nào đang âm thầm lỗ — và đó là bước đầu tiên trước khi nghĩ đến bất kỳ khoản đầu tư công nghệ nào.