Có một kiểu cuộc họp rất dễ gặp. Màn hình chia sẻ một file report dài, nhiều tab, nhiều cột, nhiều màu. Ai cũng chăm chú vài phút đầu, rồi dần dần căn phòng bắt đầu trôi. Một người hỏi con số này lấy từ đâu. Một người khác giải thích vì sao tháng này khác tháng trước. Cuối cùng, cuộc họp kết thúc với cảm giác đã xem rất nhiều dữ liệu, nhưng không ai thật sự biết tuần sau phải làm gì khác đi.
Phần Scorecard trong Data làm mình nghĩ nhiều về vấn đề đó. Doanh nghiệp không thiếu số liệu. Nhiều nơi còn thừa số liệu. Cái thiếu là một trang số đủ đơn giản để nhìn nhanh, đủ đúng để tin, và đủ gần với hành động để khi nó lệch, team biết cần đào sâu ở đâu. Scorecard không nên là một kho dữ liệu. Nó nên là bảng điều khiển tối giản của business.
Một nhóm nhỏ con số, không phải một rừng KPI
Một Scorecard tốt thường chỉ cần một nhóm nhỏ measurables quan trọng. Ít quá thì không đủ pulse của business. Nhiều quá thì mất trọng tâm. Điều khó không phải là nghĩ ra thêm số để đo. Điều khó là bỏ bớt những số không thật sự quyết định sức khỏe vận hành.
Mình thấy điểm này rất gần với engineering. Một hệ thống monitoring có quá nhiều alert sẽ làm team chai lì. Alert nào cũng đỏ thì cuối cùng không alert nào còn gây chú ý. Scorecard cũng vậy. Nếu thứ gì cũng được đưa lên trang chính, nghĩa là team chưa làm xong phần suy nghĩ khó: đâu là vài tín hiệu thật sự cho biết business đang đi đúng hướng?
Những số còn lại không phải bị vứt đi. Chúng có thể nằm trong dashboard chi tiết, departmental report, hoặc deep-dive khi cần. Nhưng trang Scorecard chính cần giữ vai trò riêng: nhìn vào là biết business có đang ổn không, chỗ nào cần bàn ngay, chỗ nào cần IDS, và chỗ nào đang thành xu hướng.
Scorecard giống đèn báo trên xe
Một hình ảnh dễ hiểu là đèn check engine. Khi nó sáng lên, mình chưa biết chính xác xe hỏng gì. Nhưng mình biết có một nơi cần kiểm tra. Scorecard cũng vậy. Một measurable bị đỏ không tự động nói toàn bộ nguyên nhân. Nó chỉ nói: ở đây có tín hiệu bất thường, đừng bỏ qua.
Điều này làm cuộc họp tốt hơn. Thay vì tranh luận vòng quanh bằng cảm giác, team có điểm bắt đầu. Number này không đạt. Nó thuộc function nào. Ai accountable. Đây là vấn đề thật hay chỉ là nhiễu tạm thời. Nếu thật, nguyên nhân nằm ở People, Process, Sales, Operations, Cash hay một giả định sai nào đó. Một số đỏ không phải để đổ lỗi. Nó là lời mời mở nắp hệ thống ra xem.
Nếu không có đèn báo sớm, business thường chỉ biết vấn đề khi đã nằm trong P&L, khi khách hàng đã rời đi, khi cash đã căng, khi team đã quá tải, hoặc khi một quý đã kết thúc. Lúc đó vẫn có thể sửa, nhưng chi phí sửa cao hơn rất nhiều.
P&L là gương chiếu hậu, không phải kính chắn gió
Một ý rất đáng nhớ trong cuốn sách là P&L cho biết business đã diễn ra như thế nào. Nó quan trọng, nhưng nó là lagging indicator. Nó giống gương chiếu hậu. Mình cần gương chiếu hậu để lái xe an toàn, nhưng không thể chỉ nhìn gương chiếu hậu mà lái về phía trước.
Scorecard nên ưu tiên những leading indicators: các hoạt động hoặc tín hiệu có khả năng dự báo kết quả. Nếu revenue là kết quả, thì có thể cần nhìn trước vào qualified leads, số proposal, close rate, average deal size, activation time, capacity, hoặc các hành động tạo ra revenue. Nếu profit bị mỏng, có thể cần nhìn vào rework, labor efficiency, pricing discipline, gross margin, hoặc lỗi quy trình.
Điểm quan trọng là không bị kẹt ở từ ngữ. Một số có thể là lagging indicator với phòng ban này nhưng lại là leading indicator với phòng ban khác. Điều cần hỏi không phải là nhãn của nó nghe chuẩn chưa. Điều cần hỏi là: con số này có giúp mình thấy đường phía trước không?
Bắt đầu từ điều muốn đạt, rồi đi ngược lại
Cách chọn số có ích nhất trong sách là đi ngược từ kết quả mong muốn. Nếu muốn có một kết quả, trước đó điều gì phải xảy ra? Và trước điều đó nữa, hành động nào tạo ra nó? Cứ lùi lại như vậy cho đến khi chạm vào một hoạt động đủ cụ thể, đủ đo được, và đủ gần để team có thể làm trong tuần này.
Ví dụ, nếu muốn có khách hàng mới, mình không nên chỉ đo số khách hàng mới vào cuối tháng. Mình cần hiểu chuỗi phía trước: bao nhiêu cuộc tiếp cận tạo ra bao nhiêu cuộc gặp, bao nhiêu cuộc gặp tạo ra bao nhiêu proposal, bao nhiêu proposal tạo ra một deal. Khi chuỗi này rõ, team không còn chỉ hy vọng vào kết quả. Team biết hoạt động nào cần làm đều để kết quả có xác suất xảy ra.
Đây là first-principles thinking trong vận hành. Không bắt đầu bằng việc hỏi đối thủ đo gì. Không bắt đầu bằng template KPI trên mạng. Bắt đầu bằng business của mình: mình thật sự muốn gì, điều gì tạo ra nó, và hoạt động nào nếu đo mỗi tuần sẽ cho mình tín hiệu sớm nhất?
Nhịp hằng tuần tạo ra nhiều cơ hội sửa nhỏ
Mình thích nhấn mạnh của sách về nhịp tuần. Đo hằng tháng có thể hợp với một vài số, nhưng nếu một vấn đề chỉ lộ ra mỗi tháng một lần, mình chỉ có mười hai cơ hội chỉnh trong năm. Đo hằng tuần cho team hơn năm mươi lần chỉnh hướng. Những chỉnh hướng nhỏ, nếu làm đều, thường ít đau hơn một cú bẻ lái lớn vào cuối quý.
Weekly Scorecard cũng buộc team đối diện với thực tế thường xuyên hơn. Không cần đợi cảm giác bất an tích tụ thành một cuộc họp lớn. Một con số lệch tuần này được đưa vào agenda. Team Identify, Discuss, Solve. Ra to-do. Tuần sau xem lại. Nhịp này làm business bớt phụ thuộc vào trí nhớ và cảm xúc nhất thời.
Tuy vậy, đo thường xuyên không có nghĩa phản ứng quá đà. Có số cần nhìn theo range, vì quá thấp hay quá cao đều gây hại. Lead quá ít thì thiếu sales. Lead quá nhiều có thể làm sales hoặc operations quá tải. Một Scorecard tốt không chỉ hỏi tăng hay giảm. Nó hỏi vùng khỏe mạnh của con số này nằm ở đâu.
Scorecard phải tiến hóa
Một Scorecard đầu tiên hiếm khi đúng ngay. Điều này làm mình thấy dễ chịu. Nhiều hệ thống đo thất bại không phải vì ý tưởng data sai, mà vì team kỳ vọng có bản hoàn hảo ngay từ lần đầu. Khi không hoàn hảo, họ bỏ. Trong khi cách đúng hơn là xem Scorecard như một sản phẩm cần iterate.
Quý này có thể bỏ một số không tạo hành động. Thêm một số mới sau khi business bị bất ngờ bởi một vấn đề. Đổi goal khi đội ngũ mạnh hơn. Chuyển một số từ Scorecard chính xuống departmental Scorecard nếu nó quá chi tiết. Nhìn trend 13 tuần để xem mình đang đo signal hay noise. Scorecard trưởng thành cùng business, nếu team chịu học từ nó.
Những bẫy thường gặp
Có vài bẫy mình muốn ghi lại. Bẫy thứ nhất là comparison game: lấy Scorecard của công ty khác rồi áp vào mình. Học từ người khác có ích, nhưng copy metric dễ làm mình đo business của người ta, không phải business của mình.
Bẫy thứ hai là dùng Scorecard phức tạp để che vấn đề con người. Nếu không tin một người đang ở đúng seat, thêm nhiều số không chắc giúp được. Có khi vấn đề không phải Data Component, mà là People Component.
Bẫy thứ ba là nhét informational metrics vào Scorecard chỉ vì chủ doanh nghiệp muốn xem tiện. Những số đó có thể quan trọng, nhưng nếu chúng không dự báo hành động và không kéo team về kết quả mong muốn, chúng làm Scorecard loãng đi.
Bẫy cuối là đo thứ dễ đo thay vì thứ cần đo. Đây là streetlight effect rất quen: tìm chìa khóa dưới đèn vì chỗ đó sáng, dù mình làm rơi ở nơi khác. Trong business, điều dễ đo thường rất hấp dẫn. Nhưng số dễ đo không nhất thiết là số thật sự làm business tốt hơn.
Một Scorecard tốt không phải là nơi chứa mọi dữ liệu. Nó là một trang ít số nhưng nhiều tác dụng: nhìn được hiện tại, dự báo tương lai gần, chỉ ra chỗ cần bàn, và buộc team hành động đều đặn.
Key Takeaways
- Scorecard là bảng cảnh báo sớm, không phải kho dữ liệu. Nó phải giúp team thấy điều gì đang lệch trước khi P&L cuối tháng xác nhận vấn đề.
- Ít số nhưng đúng số tốt hơn nhiều KPI. Nếu một metric đỏ mà không ai biết phải làm gì, có thể nó chưa đủ gần với hành động.
- P&L thường nhìn quá khứ, Scorecard nên nhìn tương lai gần. Ví dụ: số lead tuần này, số demo đã book, số ticket quá hạn hoặc số đơn giao trễ có thể dự báo tháng sau tốt hay xấu.
- Reverse-engineer từ kết quả mong muốn. Muốn đạt revenue cụ thể, hãy đi ngược về số khách cần chốt, close rate, average sale, số proposal và số warm lead cần tạo.
- Nhịp đo hằng tuần tạo kỷ luật. Scorecard không phát huy nếu chỉ mở khi có vấn đề; nó cần một cadence đều để team học pattern.
- Đừng copy Scorecard của công ty khác. Metric tốt phải phản ánh business model, stage, constraint và mục tiêu thật của mình.
- Bài tập nhỏ: chọn 5 đến 15 con số cho team hiện tại; với mỗi số, viết rõ owner, goal, tần suất cập nhật và hành động khi nó đỏ.
Bài tập nhỏ sau khi đọc phần này có thể là nhìn lại dashboard hiện tại của mình, dù là cho một công ty, một team hay một dự án cá nhân. Nếu chỉ được giữ lại 5 đến 15 con số cho mỗi tuần, mình sẽ giữ số nào? Và quan trọng hơn: khi một số bị đỏ, team có thật sự biết phải làm gì với nó không?