Bỏ qua, tới nội dung chính

Giải pháp doanh nghiệp

Dashboard điều hành: ban giám đốc nên xem số liệu nào, lấy từ đâu?

Một dashboard có ích không bắt đầu từ biểu đồ đẹp, mà từ vài câu hỏi ban giám đốc phải trả lời mỗi tuần và nơi giữ bản đúng của từng con số.

· 7 phút đọc

Đầu tháng, giám đốc hỏi doanh thu tháng trước. Kế toán cần thêm vài ngày để khoá sổ. Phòng kinh doanh gửi một file Excel tự cộng từ danh sách đơn. Kho gửi một file khác về hàng đã xuất. Ba con số không khớp nhau, và cuộc họp đầu tháng dành phần lớn thời gian để hỏi "số nào đúng?".

Khi đó, rất nhiều doanh nghiệp nghĩ tới một dashboard điều hành: một màn hình cho ban giám đốc xem số liệu kinh doanh, vận hành mà không phải chờ ai tổng hợp tay. Ý tưởng đúng. Nhưng cũng rất nhiều dashboard được làm ra với hàng chục biểu đồ đẹp, rồi sau vài tuần không ai mở nữa.

Sự khác nhau giữa hai kết cục thường nằm ở những việc làm trước khi vẽ biểu đồ đầu tiên.

Bắt đầu từ câu hỏi, không bắt đầu từ biểu đồ

Câu hỏi sai để mở đầu là "dashboard nên có những biểu đồ gì?". Câu hỏi đúng là: mỗi tuần, ban giám đốc cần trả lời những câu nào để ra quyết định?

Hãy ngồi lại với những người sẽ dùng dashboard và liệt kê các câu hỏi họ đang phải hỏi đi hỏi lại. Ví dụ:

  • Tuần này bán được bao nhiêu, so với cùng kỳ và so với kế hoạch?
  • Khách hàng nào đang nợ quá hạn, tổng bao nhiêu?
  • Đơn hàng nào đang bị chậm giao, chậm ở khâu nào?
  • Mặt hàng nào sắp hết, mặt hàng nào tồn lâu không bán được?
  • Chi nhánh hay nhóm kinh doanh nào đang đi xuống?

Với mỗi câu hỏi, thêm một câu nữa: nếu con số này xấu đi, ai sẽ làm gì? Một con số mà không ai hành động khi nó thay đổi thì chưa cần nằm trên dashboard điều hành. Nó có thể nằm ở một báo cáo chi tiết cho bộ phận liên quan.

Từ câu hỏi đến con số: mỗi câu hỏi ban giám đốc cần trả lời được gắn với một con số, một cách tính đã thống nhất, phần mềm giữ dữ liệu gốc và người chịu trách nhiệm hành động khi con số xấu đi

Danh sách cuối cùng thường ngắn hơn bạn nghĩ. Một màn hình đầu tiên chỉ với vài con số mà ai cũng hiểu và ai cũng dùng có giá trị hơn nhiều so với một màn hình đầy biểu đồ mà mỗi người đọc một kiểu.

Thống nhất cách tính trước khi vẽ

Đây là bước hay bị bỏ qua nhất, và cũng là nguyên nhân phổ biến nhất khiến dashboard mất lòng tin. Cùng một chữ "doanh thu", mỗi bộ phận có thể đang hiểu khác nhau:

  • Kinh doanh tính theo ngày chốt đơn.
  • Kho tính theo ngày xuất hàng.
  • Kế toán tính theo ngày xuất hoá đơn, đã trừ hàng trả lại và chiết khấu.

Cả ba đều không sai. Nhưng nếu dashboard hiện một con số mà không nói rõ nó được tính theo cách nào, cuộc họp sẽ lại quay về buổi đối chiếu, chỉ khác là bây giờ đối chiếu với màn hình.

Với mỗi con số trên dashboard, nên viết ra một dòng định nghĩa ngắn mà các bộ phận cùng đồng ý: tính từ dữ liệu nào, tính theo ngày nào, có trừ gì không, và ai là người có quyền quyết định khi có tranh cãi. Dòng định nghĩa này nên hiện ngay trên dashboard, cạnh con số, để người xem không phải đoán.

Mỗi con số lấy từ đâu

Khi đã có danh sách con số và cách tính, câu hỏi tiếp theo là dữ liệu gốc nằm ở phần mềm nào. Doanh thu theo hoá đơn có thể nằm trong phần mềm kế toán, đơn hàng nằm trong phần mềm bán hàng, khách hàng nằm trong CRM, còn kế hoạch tháng có khi chỉ nằm trong một file Excel của phòng kinh doanh.

Lúc này thường lộ ra ba tình huống:

  1. Dữ liệu đã có trong phần mềm và lấy ra được. Đây là trường hợp dễ nhất: dashboard đọc dữ liệu từ phần mềm đó, qua kết nối mà phần mềm hỗ trợ.
  2. Dữ liệu có, nhưng nằm ở nhiều nơi và không khớp nhau. Cùng một khách hàng có nhiều mã, cùng một sản phẩm có tên khác nhau ở mỗi phần mềm. Cần dọn và thống nhất trước, nếu không dashboard chỉ hiển thị sự lộn xộn một cách đẹp hơn.
  3. Dữ liệu chưa được ghi lại ở đâu cả. Ví dụ lý do đơn hàng bị chậm chỉ được nói miệng. Muốn có con số này, trước hết quy trình phải ghi nhận nó.

Ba tình huống về nguồn dữ liệu khi làm dashboard: dữ liệu đã có và lấy ra được thì nối thẳng vào dashboard; dữ liệu có nhưng nằm nhiều nơi, không khớp thì dọn và thống nhất mã trước; dữ liệu chưa được ghi lại thì phải sửa quy trình để ghi nhận trước

Nếu phần lớn con số rơi vào tình huống thứ hai, việc nên làm trước có lẽ là kết nối các phần mềm đang dùng để mỗi loại dữ liệu chỉ có một nơi giữ bản đúng. Dashboard sẽ đứng vững hơn nhiều khi nó đọc từ những nguồn đã thống nhất.

Cần cập nhật nhanh tới mức nào

"Cập nhật liên tục" nghe hấp dẫn, nhưng không phải con số nào cũng cần như vậy. Hãy hỏi với từng con số: nếu biết muộn vài giờ hay muộn một ngày, quyết định có khác đi không?

  • Đơn hàng đang chậm giao, hàng sắp hết: biết càng sớm càng có thể xử lý trong ngày.
  • Doanh thu theo tuần, công nợ quá hạn: cập nhật mỗi ngày thường đã đủ.
  • Lợi nhuận theo tháng: phụ thuộc vào việc khoá sổ của kế toán, không nhanh hơn được tốc độ đó.

Mức cập nhật cũng phụ thuộc vào cách lấy dữ liệu từ từng phần mềm: có phần mềm cho phép đọc dữ liệu gần như ngay khi phát sinh, có phần mềm chỉ xuất được file theo lịch. Biết trước điều này giúp bạn đặt kỳ vọng đúng, thay vì đòi mọi con số phải nhảy theo từng phút.

Những lý do khiến dashboard bị bỏ xó

Quá nhiều thứ trên một màn hình. Người xem không biết nhìn vào đâu trước. Màn hình chính chỉ nên có những con số trả lời các câu hỏi đã chốt; chi tiết để ở trang sau.

Không ai tin con số. Chỉ cần một lần dashboard hiện số khác với số kế toán mà không giải thích được, người dùng sẽ quay về hỏi file Excel. Định nghĩa rõ cách tính và hiện thời điểm cập nhật gần nhất ngay trên màn hình giúp giữ lòng tin.

Không gắn với cuộc họp nào. Dashboard hiệu quả nhất khi nó trở thành tài liệu chính của một cuộc họp định kỳ, chẳng hạn họp giao ban đầu tuần mở thẳng màn hình đó ra thay vì chiếu slide tổng hợp tay.

Ai cũng thấy mọi thứ. Số liệu lương, lợi nhuận hay công nợ của từng khách không phải ai cũng nên xem. Phân quyền theo vai trò cần được tính ngay từ đầu, không phải vá sau khi đã lỡ chia sẻ.

Bắt đầu nhỏ, dùng thật rồi mới mở rộng

Cách ít rủi ro nhất là chọn một màn hình cho một nhóm người dùng, thường là ban giám đốc, với vài con số trả lời những câu hỏi gây mất thời gian nhất hiện nay. Cho nó chạy trong các cuộc họp thật vài tuần, ghi lại những câu hỏi mà màn hình chưa trả lời được, rồi mới thêm con số tiếp theo.

Trước khi lập trình, nên có một bản mẫu bấm thử được để người dùng thật xem bố cục, thứ tự các con số và cách đọc, vì sửa trên bản mẫu luôn rẻ hơn sửa trên phần mềm đã làm xong.

HD Web Services làm việc này thế nào

Dashboard điều hành là một phần trong giải pháp doanh nghiệp của chúng tôi: số liệu kinh doanh, vận hành cập nhật liên tục thay cho báo cáo tổng hợp tay. Dự án bắt đầu bằng khảo sát nghiệp vụ với từng bộ phận liên quan, sau đó bạn và người dùng thật thử bản mẫu giao diện trước khi chốt phạm vi lập trình. Việc phát triển chia theo sprint, mỗi sprint kết thúc bằng một phần chạy được, có buổi demo và nghiệm thu. Khả năng lấy dữ liệu từ phần mềm kế toán hay các phần mềm khác đang dùng, qua API hoặc trao đổi file theo lịch, được kiểm tra trong buổi khảo sát, trước khi đưa vào báo giá.

Nếu cuộc họp đầu tháng của công ty bạn vẫn đang bắt đầu bằng câu "số nào đúng?", hãy kể cho chúng tôi nghe ban giám đốc cần trả lời những câu hỏi gì mỗi tuần.

Viết bởi HD Web Services

Trao đổi 30 phút, nhận phác thảo phạm vi và báo giá

Không ràng buộc, không thúc ép. Nếu dự án của bạn không phù hợp với chúng tôi, chúng tôi sẽ nói thẳng.

ZaloƯớc tính chi phí