Dữ liệu vận hành

Hai người, hai con số doanh thu, cùng một ngày

09/2026 · 4 phút đọc

Cuộc họp nào cũng có đoạn này. Một người đọc số doanh thu của mình, người kia nói số tôi khác. Rồi cả phòng dừng lại mười lăm phút để tìm xem ai đúng.

Phần lớn trường hợp không ai sai. Hai người tính hai thứ khác nhau nhưng gọi bằng một cái tên.

“Doanh thu” là gì

Nghe thì hiển nhiên. Nhưng thử hỏi cụ thể:

Doanh thu đã trừ khuyến mãi chưa. Đơn huỷ trong ngày có tính không. Đơn đặt hôm nay giao ngày mai tính vào ngày nào. Đơn qua ứng dụng giao đồ ăn lấy giá khách trả hay giá về tài khoản sau chiết khấu. Thuế nằm trong hay ngoài.

Năm câu hỏi, mỗi câu hai lựa chọn. Về lý thuyết là ba mươi hai cách tính khác nhau cho cùng một chữ.

Người làm bán hàng thường lấy giá khách trả, vì đó là thứ họ cam kết với khách. Người làm kế toán lấy số về tài khoản, vì đó là thứ ghi sổ. Cả hai đều đúng trong phạm vi của mình. Vấn đề chỉ xuất hiện khi hai con số gặp nhau trên một slide.

Chuyện xảy ra trước khi có dashboard

Ở giai đoạn báo cáo còn ghép tay, mỗi bộ phận giữ một file Excel riêng. Cuối ngày ai đó gom lại, sửa vài chỗ cho khớp, gửi đi.

Chỗ “sửa cho khớp” mới là chỗ đáng sợ. Nó không được ghi lại ở đâu. Người làm việc đó nghỉ phép thì hôm sau số ra khác, và không ai giải thích được vì sao.

Tôi đã thấy đủ tình huống như vậy để rút ra một kết luận: xây dashboard mà không định nghĩa chỉ số trước thì chỉ là làm cho cái sai chạy nhanh hơn.

Từ điển chỉ số, làm trước khi viết dòng mã nào

Trước khi kéo dữ liệu từ API về, tôi ngồi với từng bộ phận và viết ra một bảng. Mỗi chỉ số một dòng, bốn cột.

Tên gọi. Đúng cái tên mọi người đang dùng hằng ngày, không phải tên tôi nghĩ ra.

Định nghĩa bằng lời. Một câu, không có chữ “và tương tự”, không có dấu ba chấm.

Công thức. Lấy từ bảng nào, cột nào, trừ đi cái gì.

Nguồn và tần suất. Số này về từ đâu, cập nhật mấy lần một ngày.

Bảng đó khó viết hơn phần kỹ thuật. Có chỉ số mất hai buổi mới thống nhất được một câu định nghĩa. Nhưng sau khi thống nhất, phần dựng dashboard chỉ là việc thi hành.

Sơ đồ luồng dữ liệu: POS, kế toán và marketing đổ về một cơ sở dữ liệu doanh nghiệp sở hữu, qua từ điển chỉ số rồi lên dashboard

Con số phải tự chảy

Nguyên tắc thứ hai: không ai được nhập tay vào giữa đường.

Dữ liệu đi từ hệ thống nguồn, qua lịch đồng bộ, vào một cơ sở dữ liệu do doanh nghiệp sở hữu, rồi lên dashboard. Mỗi khâu đều tự động. Nếu một khâu cần người can thiệp, đó là chỗ sẽ hỏng khi người đó bận.

Tôi dựng MySQL bằng Docker cho phần lưu trữ, lý do đơn giản là để mang đi và khôi phục được. Dữ liệu nằm trong tay doanh nghiệp, không nằm trong tay nhà cung cấp phần mềm nào. Muốn phân tích chéo giữa bán hàng, kế toán và marketing thì phải gom về một chỗ trước đã.

Kết quả

Hai chỉ số tôi theo dõi là thời gian ra báo cáo cuối ngày và tỷ lệ điểm bán đã được phủ dữ liệu. Con số cụ thể sẽ cập nhật khi được phép công bố.

Nhưng thay đổi lớn nhất không đo bằng phút. Là ở chỗ trong cuộc họp, khi hai người đọc ra hai con số khác nhau, giờ có một tài liệu để mở ra và xem ai đang tính cái gì.

Mười lăm phút tranh luận rút xuống còn một câu.

Cách làm đầy đủ nằm trong gói Dashboard KPI. Hai dự án liên quan: dashboard bán hàng thời gian thựcdata platform tự dựng trên MySQL.

Chỗ bạn cũng có hai con số cho một cái tên? Nói tôi nghe.