- Giá trị của đội dữ liệu không đến từ sản lượng pipeline, schema hay dashboard, mà từ sự thay đổi trong quyết định của tổ chức; giữa dữ liệu và hành động cần có một lớp diễn giải là Góc nhìn (Perspective)
- Data-Perspective-Action là mô hình vận hành xây dựng dữ liệu đáng tin cậy, diễn giải theo bối cảnh kinh doanh, rồi liên tục đề xuất các hành động cụ thể
- Trong 2026 AI & Data Leadership Executive Benchmark Survey, 93% lãnh đạo dữ liệu và AI xem văn hóa và quản trị thay đổi là rào cản cốt lõi khi triển khai, trong khi chỉ 7% chỉ ra công nghệ
- Có thể biến góc nhìn thành thói quen và kết nối đến quyết định thực tế bằng tài liệu một trang hằng tuần, hệ thống chỉ số cốt lõi, đồng thiết kế với các bên liên quan và quy tắc gắn khuyến nghị hành động vào mọi phân tích
- Khi AI ngày càng tạo ra pipeline, phân tích ban đầu và dashboard, kiến thức miền và niềm tin trở thành điểm khác biệt; vì vậy đội dữ liệu phải vượt ra ngoài việc cung cấp kết quả chính xác để xây dựng một thực tại chung
Vì sao cần Data-Perspective-Action
- Giá trị của tổ chức được tạo ra từ quyết định, không phải sản phẩm dữ liệu; giữa đầu ra thô và hành động thực tế cần có một lớp diễn giải là góc nhìn
- Ngay cả đội có năng lực kỹ thuật và dữ liệu chính xác cũng có thể trở nên không liên quan đến quyết định của tổ chức nếu chỉ tối ưu sản lượng như xử lý yêu cầu, đóng ticket, triển khai dashboard
- Ngay cả hệ thống dữ liệu được thiết kế tốt cũng có thể bị đẩy xuống thấp trong thứ tự ưu tiên, mất ngân sách hoặc biến mất vì tái cơ cấu nếu không biến việc kết nối công việc với quyết định thành thói quen
- Data-Perspective-Action là framework chủ động lặp lại quá trình đi từ dữ liệu, qua diễn giải có quan điểm, đến các quyết định cụ thể
Điểm xuất phát của framework
- Báo cáo hằng tháng của một agency quảng cáo mất 4 tuần để hoàn thành nên đã lỗi thời khi được gửi đi, nhưng khi workflow được tự động hóa xuống còn khoảng một ngày, thời gian còn lại được dùng cho mô hình dự báo
- Mô hình không phức tạp, nhưng cho thấy kết quả dự kiến khi dịch chuyển ngân sách theo từng kênh, giúp khách hàng xem trước lợi nhuận kỳ vọng và thực hiện thay đổi kênh cùng các thử nghiệm
- Từ trải nghiệm này, trình tự dữ liệu, diễn giải và quyết định cụ thể được hình thành, rồi cùng mô hình đó được áp dụng cho nhiều tổ chức sau này
Bước 1: Data đáng tin cậy
- Lớp Data bao gồm hạ tầng, độ tin cậy, tính nhất quán, luồng thông tin, pipeline, schema, model và dashboard; phần lớn công việc hằng ngày của data engineer và analytics engineer nằm ở đây
- Không thể tạo góc nhìn từ dữ liệu không đáng tin cậy, nhưng nếu dừng công việc ở nhận yêu cầu → xử lý → đóng ticket, gánh nặng diễn giải dữ liệu chính xác sẽ được chuyển cho các bên liên quan chưa được chuẩn bị
- Một đội đã xây dựng 200 dashboard với pipeline và schema tinh vi cùng logic cập nhật đã được kiểm chứng, nhưng chỉ 10 dashboard được mở trước các quyết định thực tế
- 190 dashboard còn lại được tạo ra khi đội dữ liệu và các bên liên quan chưa thống nhất chúng phục vụ quyết định nào
- Những dashboard không cần thiết đã bị loại bỏ, nhưng nguyên nhân gốc là thiếu định nghĩa chung về mục đích công việc
- Nếu chỉ ở lại lớp Data, backlog và khối lượng công việc vẫn được duy trì, nhưng khoảng cách với quyết định thực tế sẽ ngày càng lớn, khiến đội dễ bị hạ thấp mức ưu tiên
Bước 2: Perspective
- Perspective là lớp biến đội cung cấp thông tin thành đội tạo ảnh hưởng trong tổ chức; trọng tâm là kiến thức miền để đánh giá các chỉ số đang theo dõi có phù hợp với một quyết định cụ thể hay không
- Trong 2026 AI & Data Leadership Executive Benchmark Survey, 93% lãnh đạo cấp cao về dữ liệu và AI chọn văn hóa và quản trị thay đổi là thách thức chính khi triển khai, trong khi chỉ 7% chọn công nghệ
- Chênh lệch giữa văn hóa/quản trị thay đổi và công nghệ:
- Đây là khoảng cách lớn nhất trong 15 kỳ khảo sát thường niên, và trong suốt thời gian khảo sát, văn hóa cùng quản trị thay đổi liên tục xuất hiện như rào cản lặp lại nhiều hơn công nghệ
- Dù tổ chức đầu tư vào hạ tầng và nhân tài, kết quả vẫn bị giới hạn nếu thiếu năng lực diễn giải và thực thi thay đổi
- Khi AI có thể tạo pipeline, phân tích ban đầu và dashboard bằng prompt, nút thắt chuyển từ xây dựng sang niềm tin
- Khi sản lượng tăng, các guardrail như chất lượng dữ liệu, governance và định nghĩa rõ ràng về sự thật càng quan trọng hơn
- Mick Dreeling của Netflix cho rằng trong môi trường nơi các bên liên quan truy vấn trực tiếp agent, trách nhiệm đảm bảo câu trả lời đúng và liên tục nâng chuẩn rất có thể thuộc về đội data engineering
- Shridhar Iyer của Meta đánh giá rằng dù agent hấp thụ kiến thức phổ quát, chuyên môn miền vẫn là tài sản trí tuệ không biến mất
- Những chuyên gia phát triển Perspective một cách có hệ thống sẽ càng có giá trị khi công cụ AI tiến bộ, trong khi công việc chỉ ở lớp Data sẽ dễ bị tự động hóa hơn
-
Cái bẫy của tính khách quan
- Chuyên gia dữ liệu có thể cảm thấy việc đưa ra diễn giải giống như xâm phạm thẩm quyền, rồi rơi vào trạng thái thụ động không gắn bối cảnh vào phân tích
- Trong thời gian hạn chế và nhiều ưu tiên cùng lúc, các bên liên quan phải tự diễn giải dashboard mà họ chỉ hiểu một nửa, hoặc dựa vào trực giác
- Dữ liệu không tự nói lên điều gì; nếu đội dữ liệu không cẩn trọng diễn giải dựa trên bối cảnh và chuyên môn, người khác sẽ diễn giải thay
-
Vấn đề không nhìn thấy sau khi bàn giao
- Dù pipeline chạy, dashboard được mở và test đều pass, các bên liên quan vẫn có thể tải CSV xuống, mở trong Excel, thêm cột và công thức, rồi tái tạo phân tích mỗi khi cần
- Những hệ thống như vậy tuy đúng về mặt kỹ thuật nhưng trong thực tế đang bị đi đường vòng
- Nếu hỏi 5 bên liên quan về các quyết định họ đang đưa ra và điểm còn bất định, có thể tìm được vấn đề giải quyết được trong một hoặc hai ngày
- Niềm tin tích lũy bằng cách chủ động giải quyết những vấn đề nhỏ sẽ trở thành nền tảng để đội dữ liệu tham gia các cuộc họp trước quyết định, thay vì sau quyết định
-
Rèn luyện góc nhìn bằng một trang hằng tuần
- Mỗi tuần viết một trang gồm ba phần sau
- Tóm tắt trong một đoạn những sự thật mà dữ liệu cho thấy
- Diễn giải trong một đoạn, có quan điểm, rằng điều đó có ý nghĩa gì với doanh nghiệp hiện tại
- Đề xuất 1–2 bullet cụ thể về việc cần làm tiếp theo
- Chia sẻ với một quản lý, đồng nghiệp hoặc một người phụ trách kinh doanh và nhận một phản hồi; lặp lại chu kỳ này trong 3 tháng sẽ thay đổi trực giác của bạn về dữ liệu mà người ra quyết định coi trọng
- Công việc quan trọng nhất bắt đầu từ đề xuất hành động; dù không thoải mái, cần rèn luyện việc hình thành ý kiến của chính mình
- Mỗi tuần viết một trang gồm ba phần sau
-
Chỉ số macro và micro
- Chỉ số macro là một số ít chỉ số cốt lõi trả lời công ty có khỏe mạnh hay không, còn chỉ số micro là các chỉ số đầu vào giải thích chuyển động của macro
- Monisha Kanoth của Apple cho rằng một chỉ số sao Bắc Đẩu vững chắc được toàn bộ doanh nghiệp đồng thuận là nền tảng của niềm tin
- Với một lãnh đạo marketing từng nhận dữ liệu từ hàng chục nguồn, hệ thống báo cáo được xây dựng lại thành 3 chỉ số macro và 5 tín hiệu micro
- Trong vòng một quý, họ thoát khỏi tình trạng không biết nên tin con số nào, và có thể nói chính xác trong các cuộc trao đổi với hội đồng quản trị đâu là động lực tăng trưởng và đâu không phải
- Khi xác định chỉ số quan trọng và ưu tiên tính toàn vẹn của chúng, chất lượng câu hỏi và câu trả lời của đội dữ liệu cũng được cải thiện
-
Đồng thiết kế với các bên liên quan
- Phát hành phiên bản 0.8 là cách cho xem kết quả trước khi hoàn thiện và để các bên liên quan tham gia vào 20% cuối cùng của quá trình xây dựng
- Đồng sáng tạo tạo ra cảm giác sở hữu đối với kết quả, và cảm giác sở hữu biến đầu ra thành cam kết hành động thực tế
- Một bên liên quan đã viết ra 100 câu hỏi thật sự quan trọng, và phần lớn câu hỏi xuất hiện trong vài năm sau đó đều nằm trong danh sách này
- Danh sách này được dùng như roadmap xây dựng và công cụ kiểm soát phạm vi
- Khi có yêu cầu mới, có thể so sánh nó có quan trọng hơn các mục đã thống nhất hay không, thay vì chỉ quyết định từ chối hay không
-
Biến sản phẩm bàn giao thành câu chuyện, không phải liên kết
- Nếu chỉ chia sẻ SQL query, spreadsheet hoặc liên kết dashboard, bạn đang chuyển phần việc diễn giải khó nhất cho người dùng
- Dù ngắn, việc viết một câu chuyện buộc bạn phải chọn điều gì quan trọng, chịu trách nhiệm với một diễn giải cụ thể, và tạo ra sản phẩm có thể nhận phản hồi, phản biện, chỉnh sửa
- Có thể dùng AI tạo sinh để trau chuốt câu chữ, nhưng không nên giao phó chính việc suy nghĩ
- Viết là quá trình tư duy, và AI không thể phát triển thay bạn một góc nhìn độc đáo
- Nếu không trực tiếp tham gia vào suy nghĩ mà chỉ chuyển tiếp nguyên xi câu chuyện do AI tạo ra, bạn sẽ bỏ qua lớp Perspective được tích lũy theo thời gian
Bước 3: Action
- Khoảng cách từ khuyến nghị đến quyết định thực tế của tổ chức là rất lớn, và đội dữ liệu thường đánh giá thấp công việc cần thiết cho sự chuyển đổi này cũng như trách nhiệm của chính mình
- Khoảng trống giữa phân tích và cuộc họp ra quyết định phải được lấp bằng khuyến nghị rõ ràng, định lượng quy mô cơ hội và hoạt động ủng hộ liên tục
- Nếu đội dữ liệu không tham gia khu vực này, diễn giải, lợi ích và lịch trình của các bên liên quan sẽ lấp khoảng trống, khiến đội mất quyền chủ động ở phần quan trọng nhất của công việc
-
Quy tắc không chỉ trình bày dữ liệu
- Mọi phân tích phải bao gồm hành động được khuyến nghị, và không được trình bày dữ liệu đơn lẻ
- Ràng buộc rằng cuối cùng phải khuyến nghị điều gì đó sẽ thay đổi phạm vi công việc ngay từ đầu
- Bạn sẽ điều tra xoay quanh một câu hỏi cụ thể
- Bạn sẽ đo lường các chỉ số liên quan đến quyết định
- Bạn sẽ cân nhắc lãnh đạo cần thông tin gì để hành động
- Trong một trường hợp mô hình định lượng cơ hội tăng trưởng không dẫn đến hành động của lãnh đạo, vấn đề không nằm ở độ chính xác của phân tích mà ở thiếu khuyến nghị và bối cảnh chung
- Nếu nhảy thẳng từ Data sang Action, việc xây dựng quan hệ, đồng sáng tạo và tạo niềm tin sẽ bị bỏ qua, khiến khuyến nghị có thể không được thực thi
-
Quy mô cơ hội và sự ủng hộ liên tục
- Khi phân tích tạo ra giả thuyết, đội dữ liệu phải trực tiếp định lượng cơ hội đáng giá bao nhiêu và vì sao nên ưu tiên
- Dù ước tính có thể sai, con số cụ thể cho người ra quyết định một đối tượng để phản biện; ước tính có thể tranh luận dễ dẫn đến quyết định hơn một định hướng mơ hồ
- Không phải cứ trình bày một lần là sẽ được đưa vào roadmap; có thể mất nhiều tháng để đạt tới lớp Action
- Cần duy trì learning agenda để theo dõi các khuyến nghị đã được thực thi và chưa được thực thi, đồng thời tiếp tục ủng hộ những mục vẫn còn quan trọng bằng cách đưa ra số liệu đã cập nhật
- Nếu dừng công việc tiếp theo chỉ vì bài trình bày đầu tiên không được chấp nhận, bạn đang từ bỏ công việc cốt lõi là kết nối đến quyết định
Cấu trúc tổ chức hỗ trợ framework
- Đơn vị cơ bản lý tưởng là một bộ đôi gồm 1 analytics engineer và 1 analyst được phân công vào một lĩnh vực kinh doanh cụ thể
- Analytics engineer chịu trách nhiệm về độ vững chắc của hệ thống
- Analyst phụ trách câu chuyện, quan hệ với các bên liên quan và khuyến nghị hành động
- Engineer không có đối tác phụ trách câu chuyện dễ xây dựng vì sự hoàn chỉnh hơn là vì quyết định; analyst không có đối tác hệ thống đáng tin cậy sẽ khó tạo cơ sở thuyết phục
- Các tổ chức hiện tại không cần tái cơ cấu ngay; có thể phân công hai vai trò này vào một lĩnh vực kinh doanh trong một quý để kiểm chứng mô hình rồi mở rộng
- Nếu công việc hạ tầng chiếm phần lớn năng lực đội như ở các công ty giai đoạn đầu, thay vì lập bộ đôi, có thể bảo vệ thời gian để chia sẻ góc nhìn
- Thực hiện đánh giá kinh doanh hằng tuần
- Có thể tổ chức demo hằng tháng cho các đội mà mình không trực tiếp phụ trách
- Thói quen lặp lại Perspective quan trọng hơn bản thân sơ đồ tổ chức
Nhịp vận hành tích lũy trong dài hạn
- Khi lặp lại hằng tuần việc tạo góc nhìn và ủng hộ hành động, hiệu quả sẽ tích lũy qua nhiều tháng và nhiều năm
- Càng tham gia vào quá trình ra quyết định, bạn càng phân biệt tốt hơn pipeline không rõ lý do tồn tại, cảnh báo gần như chỉ là nhiễu, và khoản đầu tư hạ tầng thật sự cần trong tương lai
- Vai trò của đội dữ liệu là xây dựng một thực tại chung mà các thành viên trong tổ chức có thể cùng tin cậy về tình hình hiện tại và ý nghĩa của nó
- Data-Perspective-Action là mô hình vận hành liên tục làm rõ rằng mục đích của công việc kỹ thuật là các quyết định tốt hơn, và pipeline cùng schema cũng tồn tại vì những quyết định đó
Chưa có bình luận nào.