Writing Data Reports That Non-Technical People Actually Read \u2014 CSV-X.com

Bởi Marcus Chen, Chuyên viên Phân tích Dữ liệu cao cấp tại một công ty bán lẻ Fortune 500 với 12 năm kinh nghiệm chuyển đổi các tập dữ liệu phức tạp thành quyết định cho ban giám đốc

Vào thứ Ba tuần trước, tôi đã thấy ánh mắt của CFO chúng tôi trở nên vô hồn chưa đầy 47 giây sau khi tôi bắt đầu trình bày phân tích doanh số hàng quý. Tôi biết chính xác thời gian đó vì tôi đã tập dượt nó mười bảy lần. Báo cáo chứa những thông tin xuất sắc về mô hình phân khúc khách hàng qua 847 cửa hàng, các mô hình dự đoán với độ chính xác 94%, và các hệ số tương quan sẽ khiến bất kỳ nhà thống kê nào cũng phải rơi nước mắt vì vui mừng. Cô ấy đã đóng bài trình bày ở trang 3 trong tổng số 24 trang.

Khoảnh khắc đó đã khiến công ty chúng tôi mất khoảng 2,3 triệu đô la trong các cơ hội tối ưu hóa bị bỏ lỡ trong quý tiếp theo. Không phải vì dữ liệu sai—nó hoàn hảo. Không phải vì những thông tin không có giá trị—chúng có tính chuyển biến. Báo cáo thất bại vì tôi đã phạm phải tội lỗi chết người của phân tích dữ liệu: tôi đã viết nó cho bản thân mình, chứ không phải cho cô ấy.

Trong mười hai năm qua, tôi đã viết hơn 340 báo cáo dữ liệu cho các nhà lãnh đạo, thành viên hội đồng quản trị, và các nhóm chức năng chéo. Tôi đã học rằng khoảng cách giữa "đúng về mặt kỹ thuật" và "thực sự hữu ích" là nơi mà hầu hết các sự nghiệp dữ liệu sẽ mất đi. Những nhà phân tích vượt qua khoảng cách này trở nên không thể thiếu. Những người không làm được điều đó trở thành những người mà lãnh đạo tránh xa ở hành lang.

Sự Thật Tàn Nhẫn Về Cách Các Nhà Lãnh Đạo Đọc Báo Cáo

Đây là điều mà không ai nói với bạn trong các khóa học dữ liệu: các nhà lãnh đạo không đọc báo cáo theo cách mà bạn nghĩ. Sau khi theo sát các lãnh đạo C-suite cho một dự án nghiên cứu vào năm 2019, tôi phát hiện rằng nhà lãnh đạo trung bình chỉ dành 2,7 phút cho một báo cáo dữ liệu trước khi quyết định rằng có nên tham gia sâu hay không. Không phải 20 phút. Không đến 10. Ít hơn ba phút.

Trong 167 giây đó, họ tự hỏi ba câu hỏi: "Điều này có nghĩa là gì đối với mục tiêu của tôi?", "Tôi cần làm gì về điều này?", và "Tôi có thể tin tưởng vào phán đoán của người này không?" Nếu báo cáo của bạn không trả lời những câu hỏi này trong trang đầu tiên, nó chỉ là rác số.

Tôi đã học điều này theo cách khó khăn vào năm 2016 khi tôi dành sáu tuần để xây dựng một mô hình giá trị vòng đời khách hàng có thể dự đoán tỷ lệ rời bỏ với độ chính xác 89%. Tôi đã trình bày nó trong một báo cáo dài 31 trang với phương pháp chi tiết, giả định thống kê, và quy trình xác thực. Phó giám đốc Marketing đã cảm ơn tôi một cách lịch sự và không bao giờ đề cập đến nó nữa. Ba tháng sau, một nhà tư vấn đã trình bày những phát hiện giống hệt trong một bản ghi chú hai trang với ba điểm chính và một biểu đồ. Công ty đã đầu tư 4,5 triệu đô la vào chương trình giữ chân khách hàng dựa trên bản ghi chú đó.

Sự khác biệt không phải là chất lượng phân tích—của tôi khách quan hơn. Sự khác biệt là nhà tư vấn đã hiểu điều mà tôi không: các nhà lãnh đạo đang bị ngợp trong thông tin và thiếu rõ ràng. Họ không cần hiểu phương pháp của bạn. Họ cần hiểu điều gì cần làm tiếp theo và tại sao lại quan trọng. Khi tôi cuối cùng hiểu bài học này, các báo cáo của tôi bắt đầu được tiếp nhận khác đi. Các dự án được tài trợ. Các chiến lược được thực hiện. Lịch của tôi đầy các yêu cầu họp thay vì các công nhận lịch sự.

Các báo cáo dữ liệu thành công nhất mà tôi đã viết tuân theo những gì tôi gọi là "Kim Tự Tháp Chuyên Môn Đảo Ngược." Bạn bắt đầu với kết luận và khuyến nghị—điều mà người đọc quan tâm nhất. Sau đó, bạn cung cấp đủ bối cảnh để xây dựng sự tự tin. Cuối cùng, bạn giấu các chi tiết kỹ thuật trong phần phụ lục cho 8% độc giả thực sự muốn xác minh công việc của bạn. Điều này có vẻ đi ngược lại với mọi bản năng mà bạn phát triển trong học thuật hoặc đào tạo kỹ thuật, nhưng đó là cách để bạn khiến báo cáo được đọc thay vì bị lưu trữ.

Bắt Đầu Với Tiêu Đề, Không Phải Chuyến Đi

Mỗi báo cáo tôi viết hiện nay bắt đầu bằng một câu đơn có thể đứng riêng làm tiêu đề email. Không phải một đoạn văn. Không phải một tóm tắt. Một câu ghi lại phát hiện quan trọng và sự hệ lụy của nó. Ví dụ: "Chuyển 15% ngân sách marketing từ tìm kiếm trả tiền sang email sẽ tạo ra thêm 3,2 triệu đô la doanh thu dựa trên mẫu hành vi khách hàng Q3."

"Khoảng cách giữa 'đúng về mặt kỹ thuật' và 'thực sự hữu ích' là nơi mà hầu hết các sự nghiệp dữ liệu sẽ mất đi. Những nhà phân tích vượt qua khoảng cách này trở nên không thể thiếu."

Cách tiếp cận này vi phạm mọi điều mà tôi đã học trong bằng thống kê, nơi chúng tôi được dạy xây dựng lập luận một cách có phương pháp từ việc thu thập dữ liệu qua phân tích đến kết luận. Nhưng đây là thực tế: khán giả của bạn đã tin rằng bạn đã thực hiện phân tích đúng, nếu không họ đã không đọc báo cáo của bạn. Điều họ không biết là liệu những phát hiện của bạn có quan trọng với họ hay không. Hãy dẫn dắt với điều đó.

Tôi đã thử nghiệm cách tiếp cận này một cách hệ thống trong 18 tháng với hai nhóm báo cáo. Nhóm A theo cấu trúc truyền thống: bối cảnh, phương pháp, phát hiện, kết luận. Nhóm B bắt đầu với phát hiện và khuyến nghị tiêu đề. Các báo cáo của Nhóm B có khả năng dẫn đến các cuộc họp tiếp theo cao hơn 4,3 lần và có khả năng ảnh hưởng đến quyết định kinh doanh thực tế cao hơn 6,7 lần. Sự khác biệt rất rõ ràng đến mức tôi giờ từ chối viết báo cáo theo cách khác.

Câu tiêu đề nên chứa ba yếu tố: hành động hoặc thay đổi cụ thể được khuyến nghị, tác động hoặc lợi ích được định lượng, và nguồn dữ liệu hoặc khung thời gian mà dựa vào khuyến nghị. "Chúng ta nên làm X vì điều đó sẽ tạo ra Y dựa trên Z." Mọi thứ khác trong báo cáo tồn tại để hỗ trợ, giải thích hoặc bảo vệ câu này. Nếu bạn không thể viết câu này, bạn chưa sẵn sàng để viết báo cáo.

Một kỹ thuật mà tôi sử dụng là viết tiêu đề trước khi tôi thậm chí hoàn thành phân tích. Nó ép tôi phải làm rõ câu hỏi mà tôi thực sự đang cố gắng trả lời. Tôi đã bỏ dở hàng tá phân tích giữa chừng vì tôi không thể diễn đạt một tiêu đề thuyết phục—điều này có nghĩa là phân tích sẽ không dẫn đến quyết định gì cả. Điều này tiết kiệm một lượng lớn thời gian và ngăn chặn những báo cáo "thú vị nhưng vô dụng" làm phiền các nhóm dữ liệu.

Thay Thế Thuật Ngữ Bằng Những So Sánh Cụ Thể

Vào năm 2018, tôi đã viết một báo cáo về tối ưu hóa tồn kho mà có cụm từ "giảm mức dự trữ an toàn xuống 1,5 độ lệch chuẩn." Chính xác về mặt kỹ thuật. Hoàn toàn vô nghĩa với giám đốc vận hành đang đọc nó. Cô ấy sau đó đã nói với tôi rằng cô ấy đã gật đầu trong cuộc họp nhưng không biết tôi đang khuyến nghị gì hay tại sao điều đó lại quan trọng.

Bây giờ tôi viết: "Chúng tôi hiện đang lưu giữ đủ tồn kho dự phòng để xử lý một đợt tăng cầu một lần trong 20 năm. Chúng tôi có thể giảm an toàn mức này xuống bằng một lần trong 10 năm, điều này sẽ giải phóng 8,3 triệu đô la vốn lưu động—xấp xỉ bằng ngân sách hàng năm cho toàn bộ khu vực Đông Nam của chúng tôi." Cùng một khuyến nghị, nhưng bây giờ nó được gắn với những khái niệm mà cô ấy nghĩ đến hàng ngày: phân bổ vốn, ngân sách khu vực, khả năng chịu rủi ro.

Việc chuyển đổi từ kỹ thuật sang cụ thể không phải là giảm bớt—đó là tôn trọng chuyên môn của khán giả của bạn, mà nằm ở các lĩnh vực khác nhau so với bạn. Giám đốc vận hành hiểu rõ rủi ro chuỗi cung ứng hơn tôi từng hiểu. Cô ấy không hiểu phân bố thống kê, và cô ấy không cần phải hiểu. Công việc của tôi là chuyển đổi những phát hiện kỹ thuật của tôi thành ngôn ngữ vận hành của cô ấy.

Tôi giữ một danh sách các so sánh hiệu quả cho các khái niệm dữ liệu thông thường. Thay vì "intervall tin cậy 95%", tôi nói "chúng ta chắc chắn về điều này như chúng ta chắc chắn rằng mặt trời sẽ mọc vào ngày mai." Thay vì "hệ số tương quan 0,73", tôi nói "hai yếu tố này chuyển động cùng nhau khoảng ba phần tư thời gian, giống như việc doanh số kem và nhiệt độ đều tăng lên vào mùa hè." Thay vì "giá trị p nhỏ hơn 0,05", tôi nói "mô hình này là có thật, không phải tiếng ồn ngẫu nhiên—chúng ta sẽ thấy điều này tình cờ ít hơn một lần trong 20 tình huống tương tự."