AI LÀM GÌ TRONG PHÂN TÍCH KINH DOANH
Theo dấu một câu hỏi kinh doanh đi qua tay từng vai trò dữ liệu cho đến khi trở thành quyết định
Nếu bạn từng đọc tin tuyển dụng trong lĩnh vực dữ liệu, hẳn bạn đã gặp cảnh này: tám chức danh khác nhau, mô tả công việc chồng lấn lên nhau và không ai nói rõ họ làm việc với nhau theo thứ tự nào. Business Analyst, Data Analyst, BI Analyst, Data Scientist, Data Engineer, Data Steward, ML Engineer, IT Business Analyst: mỗi chức danh nghe đều quen, nhưng đặt cạnh nhau thì khó trả lời câu hỏi đơn giản nhất là ai bắt đầu, ai kết thúc và ai bàn giao cái gì cho ai.
Tệ hơn, ở Việt Nam có hai nghề khác nhau cùng được gọi tắt là "BA". Không ít sinh viên học ngành phân tích kinh doanh rồi tra chức danh "Business Analyst", đọc được một mô tả công việc thuần công nghệ thông tin và tưởng mình đã học nhầm ngành. Sự nhầm lẫn này không chỉ gây hoang mang khi chọn nghề; nó còn khiến doanh nghiệp tuyển sai người, giao sai việc và kỳ vọng sai vào kết quả của một dự án phân tích.
Bài viết này giải quyết vấn đề đó bằng một sơ đồ. Sơ đồ không xếp hạng ai giỏi hơn ai, cũng không liệt kê kỹ năng cần có. Nó mô tả một chu trình phân tích chạy từ đầu đến cuối: câu hỏi kinh doanh xuất hiện ở đâu, đi qua tay ai, biến thành thứ gì và kết thúc ở chỗ nào. Mục 1 giới thiệu sơ đồ và cách đọc nó. Mục 2 lần lượt đi qua năm làn vai trò. Mục 3 và 4 phân tích những gì xảy ra sau bước báo cáo: ba nhánh quyết định và ba đường quay lại. Mục 5 gỡ bốn nhầm lẫn thường gặp nhất. Mục 6 bàn về phần việc mà trí tuệ nhân tạo đang đảm nhận, mục 7 bàn về trường hợp một tác tử AI tự chạy cả vòng SOAR và mục 8 gợi ý cách dùng sơ đồ như một công cụ chẩn đoán tổ chức.
1. Sơ đồ làn vai trò và cách đọc
Một chu trình phân tích có nhiều người tham gia, nhiều bước, nhiều thứ được chuyển tay. Cách gọn nhất để nhìn tất cả trên một trang là sơ đồ làn vai trò (swimlane), loại sơ đồ quen thuộc trong phân tích quy trình. Mục này giới thiệu sơ đồ, khung bốn bước làm trục dọc của nó và các quy ước hình vẽ cần biết trước khi đọc chi tiết.
1.1. Toàn cảnh chu trình
Hình 1 trình bày toàn bộ chu trình phân tích kinh doanh dưới dạng sơ đồ làn vai trò, từ lúc một vấn đề kinh doanh được nêu ra cho đến khi nó trở thành quyết định hoặc thay đổi hệ thống.

Hình 1. Sơ đồ làn vai trò trong một chu trình phân tích kinh doanh.
Nếu chỉ nhớ được một câu từ toàn bộ Hình 1, hãy nhớ câu này: câu hỏi đi từ trái sang phải để trở thành dữ liệu và bằng chứng, rồi quay ngược về bên trái để trở thành quyết định; người đứng giữa hai chiều đi và về đó là nhà phân tích kinh doanh. Mọi chi tiết ở các mục sau đều là cách triển khai câu này.
1.2. Hai trục của sơ đồ
Sơ đồ có hai trục. Các cột là làn vai trò: mỗi làn gom những vai trò có cùng loại trách nhiệm và một ô nằm trong làn nào thì vai trò của làn đó chịu trách nhiệm thực hiện. Các dải ngang là bước trong chu trình: bốn dải đầu ứng với bốn bước của mô hình SOAR, hai dải cuối nằm ngoài SOAR. Nhờ vậy, chỉ cần nhìn vị trí một ô là biết ngay hai điều: ai làm và làm ở giai đoạn nào.
SOAR là khung tư duy phân tích được Richardson và Watson dùng xuyên suốt giáo trình Introduction to Business Analytics, gồm bốn bước: xác định câu hỏi, thu thập dữ liệu, phân tích dữ liệu và báo cáo kết quả (Richardson & Watson, 2024). Bảng 1 tóm tắt ý nghĩa của từng bước.
Bảng 1. Bốn bước của mô hình SOAR
| Bước | Tên đầy đủ | Ý nghĩa |
|---|---|---|
| S | Specify the question | Xác định câu hỏi: vấn đề kinh doanh là gì, quyết định nào sẽ thay đổi tùy theo câu trả lời |
| O | Obtain the data | Thu thập dữ liệu: phạm vi, nguồn, chất lượng, đạo đức và quyền riêng tư |
| A | Analyze the data | Phân tích: mô tả, chẩn đoán, dự đoán, đề xuất |
| R | Report the results | Báo cáo: diễn giải kết quả thành khuyến nghị, kèm mức tin cậy và giới hạn |
Nguồn: dựa trên Richardson và Watson (2024).
Điểm đáng chú ý trong Bảng 1 là bước O không chỉ là "lấy dữ liệu về". Nó bao gồm cả việc thẩm định xem dữ liệu có đầy đủ, chính xác, được phép sử dụng hay không. Như mục 7 sẽ cho thấy, đây là một trong những ô hay bị bỏ trống nhất trong thực tế.
1.3. Quy ước hình khối và mũi tên
Bốn loại hình khối trong Hình 1 mang ý nghĩa riêng. Hình chữ nhật là một hành động; ô là hành động chứ không phải chức danh, nên cùng một người có thể xuất hiện ở nhiều ô. Hình thoi là nút quyết định. Hình trụ là kho dữ liệu. Hình tròn đậm là điểm bắt đầu và kết thúc.
Còn nhãn trên mũi tên luôn là thứ được bàn giao, không phải động tác của người gửi. Quy ước nhỏ này quan trọng hơn vẻ ngoài của nó: nó buộc người vẽ trả lời câu hỏi "rốt cuộc thứ gì đã chuyển tay?". Một mũi tên ghi "gửi báo cáo" không nói gì nhiều; một mũi tên ghi "khuyến nghị kèm ba phương án và đánh đổi" cho biết chính xác người nhận cần làm gì tiếp theo.
2. Năm làn vai trò
Sau khi đã biết cách đọc sơ đồ, có thể đi vào từng làn. Năm làn trong Hình 1 không tương ứng với năm phòng ban hay năm chức danh, mà với năm loại trách nhiệm khác nhau trong một chu trình phân tích. Bảng 2 tóm tắt mỗi làn gồm những vai trò nào, chịu trách nhiệm việc gì và bàn giao thứ gì.
Bảng 2. Năm làn vai trò trong chu trình phân tích kinh doanh
| Làn | Vai trò tiêu biểu | Chịu trách nhiệm | Bàn giao |
|---|---|---|---|
| 1. Người ra quyết định, chủ quy trình | Giám đốc, trưởng phòng kinh doanh, quản lý vận hành | Nêu vấn đề, ràng buộc nguồn lực; chọn hành động cuối cùng | Vấn đề kinh doanh; quyết định |
| 2. Nhà phân tích kinh doanh | Business Analyst | Biến câu hỏi mơ hồ thành bài toán phân tích; thẩm định dữ liệu; diễn giải kết quả thành khuyến nghị; khép vòng | Đặc tả bài toán; khuyến nghị kèm đánh đổi |
| 3. Phân tích và mô hình hóa | Data Analyst, BI Analyst (mô tả, chẩn đoán); Data Scientist (dự đoán, đề xuất) | Tạo ra bằng chứng | Báo cáo, dashboard; mô hình kèm độ tin cậy |
| 4. Nền tảng dữ liệu và phần mềm | Data Engineer, Data Steward, ML Engineer, Software Engineer | Làm cho dữ liệu tồn tại, sạch, đúng quyền; đưa mô hình vào vận hành | Dữ liệu đã làm sạch; API suy luận; tính năng mới |
| 5. Hiện thực hóa hệ thống (ngoài SOAR) | IT Business Analyst, System Analyst | Khảo sát quy trình, viết đặc tả phần mềm khi khuyến nghị đòi hỏi đổi hệ thống | Tài liệu yêu cầu (BRD), user story; thiết kế giải pháp |
Có ba điểm đáng chú ý trong Bảng 2. Thứ nhất, làn 1 có ít ô nhất trong sơ đồ, chỉ ba ô. Nhưng ô đầu tiên, nơi vấn đề được nêu ra rõ đến mức nào, quyết định chất lượng của mọi thứ phía sau. Một câu hỏi mơ hồ như "tại sao doanh số kém?" sẽ sinh ra một chuỗi báo cáo không ai dùng; một câu hỏi như "có nên đóng chi nhánh X trước quý sau không?" cho biết ngay dữ liệu nào cần, phân tích nào đủ.
Thứ hai, làn 2 là làn duy nhất có mặt ở cả bốn bước SOAR. Nhà phân tích kinh doanh cùng người ra quyết định đặt câu hỏi ở bước S, thẩm định dữ liệu ở bước O, đọc và kiểm tra kết quả ở bước A và chịu trách nhiệm diễn giải ở bước R. Vì vậy, có thể gọi làn này là lớp cầu nối giữa thế giới kinh doanh và thế giới dữ liệu.
Thứ ba, Data Steward ở làn 4, người chịu trách nhiệm chất lượng, phân quyền và nguồn gốc dữ liệu, là mắt xích hay bị quên nhất. Đây cũng là mắt xích mà khi hỏng, mọi phân tích phía sau đều mất ý nghĩa: một mô hình tinh vi chạy trên dữ liệu khách hàng bị trùng lặp hay sai định nghĩa vẫn cho ra kết luận sai, chỉ là sai một cách thuyết phục hơn.
3. Ba nhánh sau bước báo cáo
Bước R không phải điểm kết thúc của chu trình. Ngay sau đó là một nút quyết định mà người ra quyết định và nhà phân tích kinh doanh cùng trả lời: kết quả này đã đủ căn cứ để hành động chưa? Câu trả lời dẫn đến một trong ba nhánh, được tóm tắt trong Bảng 3.
Bảng 3. Ba nhánh sau bước báo cáo
| Nhánh | Điều xảy ra | Ví dụ |
|---|---|---|
| Chưa đủ căn cứ | Quay lại bước S với một câu hỏi hẹp hơn | Doanh thu giảm nhưng chưa rõ do giá hay do vị trí; tách thành hai câu hỏi riêng |
| Đủ căn cứ | Ra quyết định quản lý, không cần viết dòng mã nào | Điều chỉnh giá, đổi ca trực, thay mức tồn kho tối thiểu |
| Cần đổi hệ thống | Phê duyệt đầu tư, kích hoạt làn 5 và làn 4 | Cần thêm trường dữ liệu vào phần mềm bán hàng để đo đúng chỉ số |
Nhánh giữa trong Bảng 3 quan trọng nhất và cũng bị bỏ sót nhiều nhất. Nếu sơ đồ chỉ có một đường ra dẫn tới viết phần mềm, người đọc sẽ ngầm hiểu rằng phân tích chỉ có giá trị khi biến thành một tính năng mới. Đó là một hiểu lầm phổ biến và tốn kém: rất nhiều chu trình phân tích tốt kết thúc bằng một quyết định quản lý đơn giản, nhanh và rẻ, như đổi lịch giao hàng hay ngừng một chương trình khuyến mãi không hiệu quả. Đây cũng là lý do Davenport và Harris (2017) nhấn mạnh rằng năng lực cạnh tranh bằng phân tích nằm ở cách tổ chức ra quyết định, không chỉ ở hệ thống công nghệ.
4. Ba đường quay lại
Nếu ba nhánh ở mục 3 là các lối ra, thì Hình 1 còn có ba đường quay lại, biến chu trình thành một vòng lặp thay vì một đường thẳng. Mỗi đường quay lại tương ứng với một lý do khiến phân tích không bao giờ thực sự "xong".
Đường thứ nhất là phần mềm mới sinh ra dữ liệu mới. Mỗi lần nhánh "cần đổi hệ thống" được thực hiện, ta cũng thay đổi dữ liệu mà chu trình sau quan sát được. Một trường dữ liệu mới, một quy trình nhập liệu mới, một ứng dụng mới cho khách hàng đều làm thay đổi bức tranh mà nhà phân tích nhìn thấy ở lần tiếp theo; người phân tích cần biết điều này để không so sánh số liệu trước và sau một cách máy móc.
Đường thứ hai là cảnh báo mô hình suy giảm. Một mô hình dự đoán tốt hôm nay có thể kém dần khi hành vi khách hàng thay đổi, khi đối thủ đổi chiến lược, hay khi thị trường gặp cú sốc. Nếu không có vòng giám sát, mô hình sẽ âm thầm sai và các quyết định dựa trên nó cũng sai theo mà không ai nhận ra.
Đường thứ ba là SOAR đệ quy. Chu trình sau bắt đầu bằng một câu hỏi sắc hơn, được rút ra từ chính kết quả của chu trình trước. Khả năng quay lại với câu hỏi tốt hơn là khác biệt giữa một tổ chức trưởng thành về dữ liệu và một tổ chức chỉ làm báo cáo định kỳ.
5. Bốn nhầm lẫn thường gặp
Sơ đồ làn vai trò có ích nhất khi dùng để gỡ những nhầm lẫn mà sinh viên và doanh nghiệp hay mắc. Mục này đi qua bốn cặp khái niệm thường bị đánh đồng: hai nghề cùng gọi là "BA", nhà phân tích kinh doanh và nhà phân tích dữ liệu, nhà phân tích dữ liệu và nhà phân tích BI, cuối cùng là bước báo cáo của SOAR và pha triển khai của CRISP-DM.
5.1. Business Analyst và IT Business Analyst
Đây là nhầm lẫn gây hoang mang nhất cho sinh viên. Hai nghề cùng mang chức danh "BA" nhưng nằm ở hai làn khác nhau trong Hình 1 và giao những sản phẩm khác nhau. Bảng 4 so sánh hai vai trò.
Bảng 4. Business Analyst và IT Business Analyst
| Tiêu chí | Business Analyst (làn 2) | IT Business Analyst (làn 5) |
|---|---|---|
| Làm gì | Phân tích kinh doanh bằng dữ liệu: đặt câu hỏi, đọc số, khuyến nghị hành động | Khai thác yêu cầu, viết đặc tả cho phần mềm |
| Sản phẩm | Khuyến nghị kèm đánh đổi | Tài liệu yêu cầu, user story, tiêu chí nghiệm thu |
| Tham gia bước S | Có | Không; ở bước S, đối tác của Business Analyst là người ra quyết định |
Như Bảng 4 cho thấy, IT Business Analyst chỉ xuất hiện khi chu trình đi vào nhánh "cần đổi hệ thống". Khung kiến thức BABOK của Viện Phân tích Nghiệp vụ Quốc tế mô tả phân tích nghiệp vụ theo nghĩa rộng, bao gồm cả hai hướng (International Institute of Business Analysis, 2015); nhưng trên thị trường tuyển dụng Việt Nam, phần lớn tin "BA" thực chất là vị trí ở làn 5, gắn với dự án phần mềm. Khi đọc tin tuyển dụng, hãy tìm các từ khóa như "đặc tả yêu cầu", "user story", "làm việc với đội phát triển" để nhận ra đó là làn 5; còn "phân tích số liệu kinh doanh", "đề xuất giải pháp", "làm việc với ban giám đốc" thường thuộc làn 2.
5.2. Business Analyst và Data Analyst
Hai vai trò này không phải là một, nhưng ở doanh nghiệp nhỏ thường do một người kiêm nhiệm, nên ranh giới dễ bị xóa nhòa. Ranh giới nằm ở sản phẩm cuối cùng mà mỗi người phải chịu trách nhiệm.
Data Analyst giao câu trả lời: doanh thu tháng trước giảm 12,5% và phần lớn mức giảm đến từ một chi nhánh cụ thể. Business Analyst giao khuyến nghị kèm đánh đổi: nên khảo sát chi nhánh đó trước khi kết luận về toàn thị trường; phương án A tốn ba tuần nhưng chắc chắn hơn, phương án B rẻ hơn nhưng còn rủi ro. Câu trả lời là bằng chứng; khuyến nghị là cách dùng bằng chứng để chọn hành động.
Có một phép thử nhanh để phân biệt: "Nếu kết quả này dẫn tới một quyết định sai, ai phải giải trình?" Người đó, trong chu trình đang xét, đang đóng vai Business Analyst.
5.3. Data Analyst và BI Analyst
Đây là cặp có ranh giới mờ nhất và nhiều doanh nghiệp dùng hai chức danh thay thế cho nhau. Khi có phân biệt, ranh giới thường nằm trên trục một lần hay lặp lại. BI Analyst xây hệ thống báo cáo dùng lại được: mô hình ngữ nghĩa, bộ chỉ số chuẩn, dashboard cập nhật hằng tuần. Data Analyst làm phần khám phá một lần: một câu hỏi mới xuất hiện, tìm dữ liệu, phân tích và trả lời.
Lời khuyên thực tế là đọc mô tả công việc thay vì đọc chức danh. Bản thân khái niệm "BI" cũng có nhiều cách hiểu, như được phân tích trong bài Ba cách hiểu đúng về trí tuệ kinh doanh.
5.4. Bước báo cáo của SOAR và pha triển khai của CRISP-DM
Nhầm lẫn cuối cùng mang tính phương pháp. Sinh viên học cả SOAR và CRISP-DM, một quy trình khai phá dữ liệu phổ biến gồm sáu pha (Chapman và cộng sự, 2000), thường muốn ghép một đối một hai khung này. Bảng 5 cho thấy hai khung tương ứng với nhau ở đâu và lệch nhau ở đâu.
Bảng 5. Đối chiếu SOAR và CRISP-DM
| SOAR | CRISP-DM |
|---|---|
| S (xác định câu hỏi) | Business Understanding |
| O (thu thập dữ liệu) | Data Understanding và Data Preparation |
| A (phân tích) | Modeling và Evaluation |
| R (báo cáo) | Chỉ phần truyền đạt kết quả của Deployment |
Nguồn: dựa trên Chapman và cộng sự (2000), Richardson và Watson (2024).
Dòng cuối của Bảng 5 là chỗ dễ nhầm nhất. Phần triển khai kỹ thuật của pha Deployment, tức đưa mô hình lên môi trường thật, tích hợp với hệ thống và giám sát, nằm ở làn 4 và làn 5, ngoài SOAR. SOAR mô hình hóa công việc phân tích, không phải dự án công nghệ. Đồng nhất hai thứ này sẽ khiến người học tưởng nhà phân tích phải chịu trách nhiệm cả khâu triển khai hệ thống và khiến doanh nghiệp giao cho một người hai khối việc rất khác nhau.
6. Trí tuệ nhân tạo đang đảm nhận phần nào?
Câu hỏi mà sinh viên ngành dữ liệu hay đặt ra hiện nay là: nếu AI viết được truy vấn, dựng được biểu đồ, soạn được báo cáo, thì làn nào trong Hình 1 sẽ biến mất? Sơ đồ giúp trả lời câu hỏi này cụ thể hơn những dự đoán chung chung. Bảng 6 chia các ô trong sơ đồ thành hai nhóm theo mức độ AI có thể hỗ trợ.
Bảng 6. Phần việc AI tăng cường mạnh và phần việc vẫn thuộc về con người
| AI tăng cường mạnh | Vẫn thuộc về con người |
|---|---|
| Các ô ở làn 3 và làn 4: làm sạch dữ liệu, viết truy vấn, dựng biểu đồ, soạn bản nháp báo cáo | Các ô ở làn 1 và làn 2: chọn câu hỏi đáng trả lời, thẩm định giả định, chịu trách nhiệm về khuyến nghị |
Bảng 6 cho thấy AI làm rẻ đi phần tạo bằng chứng, nên giá trị dịch chuyển sang phần đặt câu hỏi và chịu trách nhiệm về quyết định. Điều này không có nghĩa làn 3 và làn 4 biến mất, mà là mỗi người ở hai làn này làm được nhiều hơn và người biết kiểm tra kết quả của AI trở nên quý hơn người chỉ biết chạy công cụ. Cách dùng AI an toàn khi phân tích được bàn kỹ trong bài Trí tuệ nhân tạo cho bảng tính và SQL từ cơ bản đến nâng cao.
7. Khi một tác tử AI tự chạy cả vòng SOAR
Mục 6 xem AI như trợ lý của từng làn: người vẫn bấm nút chạy, người vẫn đọc kết quả. Bước tiếp theo đã xuất hiện trong nhiều doanh nghiệp là một tác tử phân tích, tức mô hình ngôn ngữ lớn được nối với công cụ truy vấn dữ liệu, chạy mã và gửi thông báo, tự chạy cả vòng SOAR lặp lại: mỗi sáng đọc dữ liệu mới, tính chỉ số, phát hiện chỗ lệch, chạy lại dự báo, đề xuất hành động rồi gửi báo cáo ngắn cho người phụ trách. Câu hỏi khi đó không còn là "AI giúp tôi phân tích thế nào" mà là "tôi giao cho AI chạy phân tích đến đâu và giám sát nó thế nào". Bài Mô hình SOAR trong phân tích kinh doanh trình bày chi tiết bốn bước của vòng này.
7.1. Ba mức giao việc
Hình 2 xếp ba mức giao việc cho tác tử phân tích trên một trục, từ quyền quyết định nằm ở người đến quyền quyết định nằm ở máy.

Hình 2. Ba mức giao việc cho một tác tử phân tích.
Ở mức thứ nhất trong Hình 2, tác tử chạy phân tích và soạn đề xuất, còn mọi hành động chờ người duyệt; mức này hợp khi mới triển khai hoặc khi hành động có rủi ro cao. Ở mức thứ hai, tác tử tự thực thi những hành động nằm trong ngưỡng đã định và chỉ chuyển cho người các trường hợp vượt ngưỡng, chẳng hạn bản đề xuất lịch ca chỉ cần duyệt khi một ô thay đổi từ hai người trở lên. Ở mức thứ ba, tác tử tự quyết trong một phạm vi rộng; con người theo dõi chỉ số tổng hợp, đọc nhật ký và can thiệp khi chạm ngưỡng dừng.
7.2. Sáu tiêu chí chọn mức
Chọn mức nào là một quyết định quản trị, không phải quyết định kỹ thuật. Bảng 7 gom thành sáu tiêu chí. Không tiêu chí nào tự quyết định; một loại quyết định chỉ nên đẩy về phía tự động hóa khi phần lớn các tiêu chí cùng nghiêng về phía ấy.
Bảng 7. Sáu tiêu chí chọn mức tự động hóa cho một loại quyết định
| Tiêu chí | Nghiêng về để người quyết, AI hỗ trợ | Nghiêng về tự động hóa |
|---|---|---|
| Tần suất | Hiếm gặp | Lặp lại nhiều lần |
| Hậu quả nếu sai | Lớn, khó đảo ngược | Kiểm soát được hoặc đảo ngược được |
| Mức chuẩn hóa của bài toán | Thấp; mục tiêu còn tranh cãi | Cao; mục tiêu đã rõ |
| Dữ liệu và tốc độ phản hồi | Ít, chậm, khó đo | Nhiều, nhanh, đo được |
| Ảnh hưởng đến quyền lợi cá nhân và tuân thủ | Cao; cần giải trình hoặc cơ chế khiếu nại | Thấp hoặc đã có cơ chế giải trình, kiểm toán |
| Biến động của môi trường | Cao | Tương đối ổn định |
Áp Bảng 7 vào hai ví dụ của một chuỗi cửa hàng. Đề xuất lịch ca hằng tuần nghiêng gần hết về cột phải: lặp lại mỗi tuần, sai thì sửa được ở tuần sau, dữ liệu phản hồi nhanh, nên có thể giao cho tác tử ở mức thứ hai. Quyết định mở cửa hàng ở một tỉnh chưa từng hoạt động nghiêng gần hết về cột trái: hiếm gặp, sai thì tốn kém và khó rút lui, môi trường nhiều bất định, nên dù vẫn dựng được mô hình đề xuất, máy chỉ nên hỗ trợ. Quyết định tín dụng nằm ở giữa và cần cẩn trọng: lặp lại nhiều và dữ liệu dồi dào, nhưng chạm tới quyền lợi cá nhân, nên hàng tiêu chí ấy phải được xét riêng chứ không thể bị át đi bởi quy mô.
7.3. Những rủi ro riêng của tác tử phân tích
Giao cả vòng SOAR cho máy tạo ra những rủi ro không có khi AI chỉ là trợ lý. Lỗi lan truyền: một tác tử sai ở bước đầu thì mọi bước sau dựng trên cái sai ấy, mà không có người đứng giữa các bước để nhận ra. Tối ưu chỉ số đo được: khi được giao một chỉ số, tác tử tìm cách nhanh nhất làm chỉ số ấy đẹp lên, kể cả những cách người thiết kế không nghĩ tới; đó là định luật Goodhart, khi một thước đo trở thành mục tiêu thì nó thôi là một thước đo tốt. Câu lệnh ẩn trong dữ liệu: tác tử đọc email khách hàng hay đánh giá sản phẩm có thể gặp một đoạn văn bản cố ý viết như câu lệnh. Trôi hiệu năng không ai thấy: báo cáo vẫn đến đúng giờ mỗi sáng trong khi dữ liệu đã đổi và dự báo đã sai dần. Trách nhiệm bị pha loãng: khi một quyết định đi qua tác tử, người duyệt và người thiết kế, mỗi bên đều có thể nghĩ bên kia đã kiểm.
Vì vậy, trước khi cho một tác tử chạy thật, cần viết ra một bản đặc tả vận hành gồm nhiệm vụ, quyền đọc và ghi, ngưỡng tự thực thi, ngưỡng dừng, nhật ký, bộ tình huống kiểm thử và chỉ số giám sát sau triển khai, kèm tên người chịu trách nhiệm cho từng loại quyết định. Trong sơ đồ làn vai trò ở Hình 1, bản đặc tả ấy là việc của làn 1 và làn 2, đúng phần mà mục 6 nói vẫn thuộc về con người. Bài AI agent cho doanh nghiệp nhỏ có một phiếu cấp quyền tám câu dùng được cho mục đích này.
8. Dùng sơ đồ như một công cụ chẩn đoán
Ngoài việc giúp chọn nghề, sơ đồ làn vai trò còn là một công cụ chẩn đoán tổ chức. Cách dùng rất đơn giản: in Hình 1 ra và đánh dấu những ô không có ai làm trong tổ chức của bạn. Kinh nghiệm cho thấy có ba ô thường trống nhất.
Ô thứ nhất là thẩm định dữ liệu ở bước O. Nhiều nơi nhảy thẳng từ câu hỏi sang viết truy vấn, rồi mới phát hiện dữ liệu thiếu, sai định nghĩa hay không được phép dùng, khi đã tốn nhiều tuần phân tích. Ô thứ hai là Data Steward: khi không ai chịu trách nhiệm chất lượng dữ liệu, mọi phân tích phía sau đứng trên nền cát. Ô thứ ba là khép vòng: rất ít tổ chức quay lại đo xem khuyến nghị lần trước có thực sự tạo ra giá trị hay không, nên họ không biết phân tích của mình đáng giá bao nhiêu.
Cần nhớ rằng các vai trò trong sơ đồ là vai trò, không phải chức danh hay biên chế. Ở một doanh nghiệp nhỏ, hai đến ba người có thể đảm nhận tất cả các ô. Thứ không đổi theo quy mô là trình tự bàn giao: câu hỏi, dữ liệu, bằng chứng, khuyến nghị, hành động.
Kết luận
Tám chức danh trong lĩnh vực dữ liệu chỉ khó hiểu khi ta nhìn chúng như một danh sách. Đặt vào một chu trình, chúng trở thành những mắt xích có thứ tự rõ ràng: người ra quyết định nêu vấn đề, nhà phân tích kinh doanh biến nó thành bài toán, các nhà phân tích dữ liệu và nhà khoa học dữ liệu tạo ra bằng chứng trên nền dữ liệu do kỹ sư và người quản lý dữ liệu chuẩn bị, rồi bằng chứng quay lại thành khuyến nghị và quyết định. Chỉ khi quyết định đòi hỏi thay đổi hệ thống, IT Business Analyst và đội phần mềm mới bước vào.
Với sinh viên, sơ đồ giúp trả lời câu hỏi "mình muốn đứng ở làn nào" thay vì "mình muốn có chức danh gì". Với doanh nghiệp, nó giúp nhìn ra những ô đang trống trước khi đầu tư thêm vào công cụ. Và trong bối cảnh AI làm rẻ đi phần tạo bằng chứng, nó nhắc rằng giá trị bền vững nhất nằm ở hai đầu của chu trình: đặt đúng câu hỏi và chịu trách nhiệm về quyết định. Ngay cả khi một tác tử AI tự chạy cả vòng phân tích, câu hỏi "ai chịu trách nhiệm khi hệ thống sai" vẫn phải có câu trả lời là một con người cụ thể.
Đọc thêm
- Ba cách hiểu đúng về trí tuệ kinh doanh
- Ra quyết định dựa trên dữ liệu
- Nghề nhà khoa học dữ liệu năm 2027
- Từ bài toán kinh doanh đến giải pháp dữ liệu
- Kể chuyện bằng dữ liệu để ra quyết định
- Mô hình SOAR trong phân tích kinh doanh
- AI agent cho doanh nghiệp nhỏ
Tài liệu tham khảo
Chapman, P., Clinton, J., Kerber, R., Khabaza, T., Reinartz, T., Shearer, C., & Wirth, R. (2000). CRISP-DM 1.0: Step-by-step data mining guide. SPSS.
Davenport, T. H., & Harris, J. G. (2017). Competing on analytics: The new science of winning (Updated ed.). Harvard Business Review Press. https://store.hbr.org/product/competing-on-analytics-updated-with-a-new-introduction-the-new-science-of-winning/10157
International Institute of Business Analysis. (2015). A guide to the business analysis body of knowledge (BABOK Guide) (v3). https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Richardson, V. J., & Watson, M. W. (2024). Introduction to business analytics. McGraw-Hill. https://www.mheducation.com/highered/product/introduction-to-business-analytics-richardson.html