Vì sao dashboard tự phục vụ không hoạt động
(briefer.cloud)- "self-serve dashboards" thực tế không hoạt động tốt. Lý do là kỹ sư hoặc nhà khoa học dữ liệu phải dành rất nhiều thời gian để viết truy vấn và chuẩn bị dashboard cho người dùng doanh nghiệp.
Vì sao "self-serve BI" không hoạt động
- SQL là công cụ "self-serve BI" duy nhất. Nhưng hầu hết các nhà cung cấp "self-serve BI" lại cố ngụy trang SQL thành một thứ khác.
- Việc viết truy vấn SQL không phải là rào cản duy nhất khiến các bên liên quan trong doanh nghiệp không thể truy vấn dữ liệu. Họ không hiểu ý nghĩa của dữ liệu, nguồn gốc của dữ liệu, cách dữ liệu được tính toán, cũng như không biết cách diễn giải và xác thực kết quả.
Thử nghiệm 1: cách tiếp cận "dropdown và checkbox" truyền thống
- Giao diện này thực chất chỉ là một nỗ lực tạo ra "SQL-by-mouse". Nó không tốt hơn SQL mà còn chậm hơn, kém tin cậy hơn, hạn chế hơn và không thể khái quát sang các công cụ khác.
- Những người như CFO sẽ không dùng giao diện này để truy vấn dữ liệu. Vì họ không có ngữ cảnh để hiểu dữ liệu và cũng không thể tự tin về kết quả.
Thử nghiệm 2: cách tiếp cận text-to-SQL
- LLM gần như quá hiệu quả trong việc dịch ngôn ngữ tự nhiên sang SQL. Ngay cả khi câu hỏi không phù hợp, nó vẫn sẽ cố tạo ra truy vấn.
- Người làm kỹ thuật sẽ nhận ra rằng câu hỏi không phù hợp và yêu cầu thêm ngữ cảnh. Họ sẽ giải thích các loại dữ liệu sẵn có và phối hợp với bộ phận kinh doanh để xây dựng những câu hỏi chính xác, hữu ích.
- LLM có thể trở thành lời giải thực sự cho "self-serve BI", nhưng chưa phải ở hình thức hiện tại. Nó cần nhiều ngữ cảnh hơn và phải thành thạo hơn trong việc thể hiện sự không chắc chắn cũng như yêu cầu thêm thông tin.
Những gì thực sự hiệu quả
- Vấn đề của "self-serve BI" không nằm ở SQL mà nằm ở ngữ cảnh và ý nghĩa của dữ liệu. Giải pháp là dạy cho mọi người hiểu về dữ liệu mà họ đang truy vấn, bất kể giao diện là gì.
- Việc yêu cầu đội ngũ kỹ thuật ghi chép toàn bộ tri thức tạo ra chi phí vận hành đáng kể và nhanh chóng trở nên lỗi thời.
- Giải pháp thực sự cho "self-serve BI" không phải là biến BI thành "self-serve" cho người không chuyên kỹ thuật, mà là giúp người làm kỹ thuật hỗ trợ các bên liên quan trong doanh nghiệp hiệu quả hơn bằng những công cụ tốt hơn.
Gợi ý về công cụ tốt hơn:
- Cung cấp LLM cho người làm kỹ thuật thay vì cho các bên liên quan trong doanh nghiệp.
- Cho phép họ tự do xử lý dữ liệu bằng các công cụ quen thuộc như Python, R, v.v.
- Giúp người làm kỹ thuật dễ dàng chia sẻ công việc của họ. Notebook và ứng dụng dữ liệu nội bộ khó chia sẻ vì phải xử lý container, dependency và hạ tầng.
1 bình luận
Các ý kiến trên Hacker News
Ở một công ty từng dùng công cụ BI để tạo dashboard, các con số trông kỳ lạ nên họ xem vào trình tạo truy vấn, nhưng hoàn toàn không thể biết một phần của truy vấn là inner join hay left join
Nhà phân tích kinh doanh tạo dashboard đó cũng không biết; thực tế ý định là dùng inner join, nhưng left join lại được thực thi, khiến dữ liệu hiển thị lớn hơn thực tế cả một bậc độ lớn
Từ lúc đó, tôi không còn tin các lớp trừu tượng kiểu này đặt lên trên SQL dành cho những người không biết SQL nữa
Có quá nhiều người có thể truy cập dữ liệu nhưng không hiểu chính dữ liệu, các mối quan hệ của nó, hay kết quả họ tạo ra có ý nghĩa gì
Trong 25 năm qua, nào là kỹ sư và nhà khoa học phân tán/nhúng, dashboard tự phục vụ, các công cụ BI/dữ liệu low-code, rồi giờ là LLM chuyển văn bản thành SQL/trực quan hóa, tất cả đều nổi lên như lời giải, nhưng rốt cuộc vẫn không giải quyết được sự thiếu hiểu biết về dữ liệu và vấn đề niềm tin vào đầu ra
Tuy vậy SQL cũng không phải lời giải. Có nhiều người biết SQL đủ để trích xuất dữ liệu, nhưng hiếm người hiểu cả cấu trúc dữ liệu, schema và cách sử dụng đúng
Ngoài kinh nghiệm ra, hiện vẫn chưa có công cụ nào giải quyết được vấn đề này; LLM có thể một ngày nào đó làm được, nhưng thành thật mà nói khả năng có vẻ thấp
Dashboard rất hữu ích để xem nhanh KPI và đào sâu, nhưng cuối cùng điều quan trọng là thực hành quản lý dữ liệu và năng lực hiểu đúng dữ liệu/mối quan hệ/chỉ số để kết nối chúng thành insight kinh doanh
Tương lai thì đáng kỳ vọng, nhưng cho đến nay các công cụ thế hệ kế tiếp chưa từng giữ được lời hứa, nên tôi tuyệt đối không dễ tin nữa
Giá trị mặc định hợp lý và cơ chế tự bắn vào chân chỉ là khác biệt về góc nhìn mà thôi
Tôi từng thấy ở các công ty lớn, khi một lỗi tinh vi hay một thiết kế nào đó làm doanh thu trông cao hơn, không ai muốn đụng vào để rồi phải chịu trách nhiệm vì doanh thu giảm
Ví dụ như ở độ phân giải trung bình, nút gói miễn phí nằm dưới phần màn hình phải cuộn mới thấy; hoặc tính toán state bị sai khiến giảm giá không được áp dụng; hoặc ai đó bỏ sót
false, khiến hệ thống yêu cầu đăng ký dù về mặt kỹ thuật không cần đăng kýTôi tự hỏi họ có cảm giác tương tự, sợ bị quy trách nhiệm vì con số giảm xuống không
Khi triển khai các luồng logic phức tạp, phần khó không phải là gõ code vào IDE, mà là năng lực mô hình hóa vấn đề và thiết kế thuật toán hiệu quả
Các công cụ này nhắm tới người dùng phi kỹ thuật bằng lời hứa rằng họ không cần viết code, nhưng người dùng vẫn không hiểu phần phức tạp là thiết kế lời giải theo cách kỹ thuật, nên bị lạc hướng hoặc tạo ra kết quả sai
Nỗ lực phát triển một quy trình kinh doanh phức tạp bằng công cụ no-code cuối cùng sẽ va vào tường sau rất nhiều thử-sai, và cuối cùng được chuyển sang cho kỹ sư thực thụ
Nhưng kỹ sư khi đó phải làm việc trong tình trạng mất những hỗ trợ hiển nhiên khi viết code bằng ngôn ngữ lập trình thật
Khi bị nhốt trong trình dựng luồng trực quan, gần như không thể có kho lưu trữ chung, quản lý phiên bản đúng nghĩa, code review, kiểm thử tự động hay CI/CD
Người dùng về cơ bản chỉ nhìn từ góc nhìn của họ, nên cần chuẩn bị các cách thay thế để họ cũng có thể nhìn theo cách họ nghĩ
Tôi biết một sản phẩm xử lý điểm danh giáo dục theo thời gian, vì mỗi trường, campus và ngày lại có tổ hợp thời khóa biểu khác nhau, và cần linh hoạt cho sự kiện thể thao, ca làm thay thế, hoạt động gộp lớp, thời khóa biểu xoay vòng 14 ngày
Nhưng điều đó không có nghĩa là không thể tạo view tổng hợp thời khóa biểu phức tạp đó thành điểm danh theo lớp học hoặc điểm danh sáng/chiều
Giả định rằng người dùng kinh doanh không thể học, hoặc quá nóng vội để học, mối quan hệ giữa câu hỏi của họ, mô hình dữ liệu và các menu thả xuống là điều vô lý
Trái lại, theo kinh nghiệm của tôi họ muốn học, nhưng thường là người mô hình hóa dữ liệu không hiểu đủ domain nên không nắm bắt được sắc thái trong câu hỏi
Kết quả là, dưới danh nghĩa đơn giản hóa self-service, họ che giấu sắc thái làm tăng thời gian để có câu trả lời, hoặc loại bỏ hẳn nó và tạo ra những câu trả lời không chính xác, dễ gây hiểu lầm
Tôi cũng không thích lối nói giảm nói tránh phi kỹ thuật. Giữa LLM, công cụ tạo truy vấn BI và SQL có đủ các điểm trung gian, không cần tuyên bố rằng bức tường năng lực là tuyệt đối
Trở thành chuyên gia về máy tính, lập trình và phân tích dữ liệu là tốt, nhưng nếu có thể, hãy đặt domain mà mình học hoặc làm việc ở trung tâm và phát triển các năng lực đó như kỹ năng bổ trợ
Lời giải cho vấn đề chuyên gia domain không biết dữ liệu, còn chuyên gia dữ liệu không biết domain, là để hai người đó trở thành cùng một người
Giờ đây sự kém năng lực ở cấp tổ chức dường như đã đạt một cấp độ mới
Từng có một truyện tranh Dilbert phê phán spreadsheet, và nó áp dụng y nguyên cho cả công cụ BI lẫn công cụ AI
Đại loại là: “Các spreadsheet trong bài thuyết trình này đương nhiên đầy lỗi và thông tin sai. Dù sao cũng chẳng ai xem lại trừ khi nó củng cố quyết định mà ban lãnh đạo đã đưa ra rồi, nên không sao cả”
Ngoài đời cũng đầy rẫy báo cáo và dashboard hỏng
Có những thứ không được cập nhật trong nhiều tháng, đôi khi nhiều năm, nhưng vẫn được dùng trong quy trình, ra quyết định và luồng công việc mà không ai biết
Có trường hợp dữ liệu không được cập nhật, nhưng vì được pivot theo ngày/giờ và mỗi lần chạy lại sắp xếp lại cùng một dữ liệu, nên dù hỏng nặng vẫn khó nhận ra
Cũng có nhiều trường hợp đủ loại công thức và “toán học” hoàn toàn sai, xuất ra những con số tưởng tượng
Chỉ là khi thế giới rời xa các hệ thống EDW và ERP tập trung, vấn đề dữ liệu trở nên khó hơn theo cấp số nhân, còn mức đầu tư thì không theo kịp
Trong 24 năm qua tôi đã cung cấp dữ liệu cho người dùng nghiệp vụ, nhưng dù là công cụ truy vấn, MS Access, Power BI hay data cube trong Excel, thực tế chỉ có một số ít người sử dụng
Có lẽ họ cũng chính là những người 40 năm trước đã cào dữ liệu từ terminal và báo cáo in ra để phân tích
Dù vậy, các lãnh đạo vẫn thích dashboard chỉ số cốt lõi, và các công cụ BI mới giúp việc tạo và duy trì dashboard KPI dễ hơn rất nhiều
Chức danh của họ có thể là kiểu “trợ lý cá nhân”, nhưng họ xử lý SharePoint form, Access, Excel như hack để tạo ra những thứ rất hay
Công nhận năng lực thông minh đó và đưa cho họ công cụ mạnh hơn thì rất tuyệt. Rồi đôi khi họ sẽ chuyển sang công việc tốt hơn, và điều đó cũng rất tuyệt
Máy tính quá đắt nên “phòng máy tính” là một bộ phận riêng trong công ty; ví dụ nếu bộ phận kinh doanh miền Tây cần tài nguyên tính toán, họ sẽ ký hợp đồng với phòng máy tính có mainframe đặt tại hiện trường
Nhóm của chúng tôi là một nhóm phân tích nội bộ nhỏ, linh hoạt, dùng các minicomputer mới và “rẻ”
Lợi thế là nhờ cấu trúc tài trợ, chúng tôi có thể phản ứng với nhu cầu người dùng nhanh hơn nhiều
Một ngày nọ, khi đi qua nhà máy, tôi thấy một người dùng cắt các dòng từ bản báo cáo sọc xanh do chúng tôi tạo ra, dán sang tờ giấy khác rồi photo
Hóa ra họ đang sắp xếp báo cáo theo một tiêu chí khác, nên tôi nói “Việc đó chúng tôi làm được cho anh/chị!”, và nhận lại phản ứng “Thật sao?”
Người cần hoàn thành việc thì bằng cách nào cũng sẽ hoàn thành. Mục tiêu của nhóm hệ thống máy tính phục vụ khách hàng nội bộ là làm cho quá trình đó hiệu quả nhất có thể
Một người khác dùng PC, tablet digitizer và AutoCAD để ghi lại các điểm trên máy bay và tạo radar profile
Đó không hẳn là mục đích gốc của CAD, mà là một cách dùng sáng tạo để thu thập dữ liệu từ các bản vẽ trong Jane's Combat Aircraft
Họ không tin rằng dữ liệu đó vốn đã tồn tại từ trước
Tích hợp là một hoạt động nghiệp vụ cần thiết, nhưng dữ liệu dễ hiểu thì các bên liên quan thực sự rất thích. Đó là một phần gia tăng giá trị rất dễ làm
Giao diện BI truyền thống được nói đến trong bài là Metabase, và hiện nay nó thuộc nhóm giao diện khá tốt cho BI
Metabase cho phép xem SQL do GUI tạo ra, và cũng có thể chuyển câu hỏi đó thành SQL thuần, nên rất phù hợp để đi từ self-service sang governance
Dễ sửa và kiểm chứng logic, đồng thời tạo ra lộ trình để những người ít thành thạo kỹ thuật nâng cao năng lực
Tuy nhiên, ý chính của bài là đúng. Ngay cả nhìn từ góc độ người làm dữ liệu chuyên nghiệp, hiếm khi công cụ BI trao cho nhiều người hơn sự hiểu biết chính xác về dữ liệu hoặc kỹ năng cần thiết để sử dụng đúng
Khi dữ liệu được quản lý tốt thì công cụ dễ dùng và mọi người cũng có thể tự tìm hiểu, nhưng thế giới phức tạp nên dữ liệu cũng trở nên phức tạp
Chi phí quản lý dữ liệu thì rất dễ thấy, còn lợi ích lại khó thấy
Tôi cũng đi đến kết luận tương tự về “self-service BI”, nhưng giải pháp thì hơi khác
Theo tôi nên nâng lớp trừu tượng lên cao hơn: tạo các dashboard có khả năng tùy biến rất cao nhưng không để người dùng nghiệp vụ tiếp xúc với SQL
Ví dụ là một dashboard có 20 bộ lọc, các chiều để phân rã dữ liệu, và 20 tham số kiểm soát “các giả định được sử dụng”
Câu hỏi “tôi muốn xem hiệu quả quảng cáo Google tháng trước theo nhóm tuổi” sẽ trở thành việc thay đổi 3–4 dropdown đã định sẵn
Ở đây tham số rất quan trọng, vì chỉ phơi bày những mục điều chỉnh đã được kiểm chứng và không cho phép SQL tùy ý
Tất nhiên loại dashboard này khó xây dựng và cần khá nhiều chuyên môn trực quan hóa với Looker, Tableau, Excel, nhưng kết quả là 70% câu hỏi có thể self-service
30% còn lại thì tốt hơn là chấp nhận không self-service, và cần người dịch câu hỏi nghiệp vụ thành câu hỏi dữ liệu. Đó là vấn đề con người
Khi đó CFO hay bất kỳ ai cần câu trả lời cho một khoảng thời gian cụ thể chỉ cần mở dashboard đó và chỉnh nhẹ các tham số mặc định
Tôi đang dùng Metabase như trong ảnh, và nhìn chung người dùng không chuyên kỹ thuật cũng thực sự sử dụng nó
Điều giúp việc triển khai là mở “office hours” để trực tiếp trình bày các ví dụ như “cách lấy doanh thu của một chi nhánh hoặc một tuần cụ thể”
Nó không giải quyết hết mọi vấn đề, truy vấn hay nhu cầu xuất dữ liệu, nhưng nhiều yêu cầu trước đây gửi sang engineering giờ không còn đi đến bước đó nữa
Một lý do khác khiến Metabase tốt là có thể self-host và dùng GSuite SSO
Chỉ số cốt lõi không phải là “yêu cầu trợ giúp giảm nên người dùng độc lập hơn”
Vì rất có khả năng những người dùng đó đang rút ra và diễn giải các chỉ số hoàn toàn sai
Tôi đã nhiều lần thấy người dùng ít kỹ thuật, khi được tiếp cận dữ liệu, tin rằng “cũng không khó như mình tưởng” rồi xây cả kim tự tháp phân tích sai bét
Phân tích đúng luôn cần bối cảnh
Ví dụ, doanh thu định kỳ không được dùng ngày giao hàng để tính doanh thu tháng, vì đội tài chính sẽ điền lại ngày giao hàng
Giá catalog được lưu bằng USD nhưng thực tế tỷ giá được điều chỉnh hằng tháng theo bảng
monthly_discountDo quy ước hiển thị hàng tồn chưa bán từ năm trước, các mục có ngày mua là null phải bị loại khỏi báo cáo doanh thu
Vì giá là nội tệ, không được cộng doanh thu nếu chưa join với bảng tỷ giá
Tôi đã thiết lập nó cho những người không lập trình trong công ty, và nói thật là họ hầu như không dùng gì ngoài việc xem các dashboard tôi đã tạo sẵn, nhưng phản hồi rất tốt
Đây là một công cụ thực sự hữu ích
Tôi luôn thấy buồn cười khi các quản lý cấp cao nhận lương rất cao mà lại không chạy được truy vấn BI SQL
Trong khi SQL vốn được tạo ra để giúp các nhà quản lý truy vấn dữ liệu dễ dàng hơn
Từ góc nhìn của một nhân viên/quản lý bán hàng trước đây, tôi không có nhiều cảm thông với những người như vậy
Nhưng ông ấy không tự làm. Vì ông ấy hiểu các nguyên lý kinh tế cơ bản
Ngay cả khi việc người khác làm mất 3 ngày mà bản thân ông ấy có thể làm trong nửa ngày, thì nửa ngày đó lại là thời gian ông ấy không làm được những việc chỉ CEO mới có thể làm
Một CxO giỏi cũng biết rằng phần thật sự tốn thời gian nằm ở việc làm cho các chi tiết khớp hoàn hảo
Dù SQL là “cấp cao”, để có câu trả lời đáng tin cậy vẫn cần thời gian và sự tập trung cho những thứ như các trường hợp đặc biệt khi xử lý null, xử lý ngày tháng, hay xử lý các phép gộp không khớp
Nếu có người chuyên làm việc đó thì nên giao cho người ấy
Tôi nghĩ dashboard BI có thể hoạt động tốt với những truy vấn rất đơn giản
Nếu đã đến mức yêu cầu người dùng phi kỹ thuật thực hiện join dữ liệu thì đã đi quá sâu rồi, lúc đó cứ dùng SQL thì hơn
Join có thể trông như điều cơ bản với một số người, nhưng cá nhân tôi đôi khi cũng thấy khó hiểu, và trong UI dashboard vốn kém biểu đạt hơn SQL thì đó là sự kết hợp dễ gây rối
Cuối cùng đây là một sự đánh đổi. Có thể làm cho nó dễ tiếp cận hơn SQL đối với người dùng phi kỹ thuật, nhưng tất yếu nó sẽ kém mạnh mẽ hơn SQL
Dù vậy, khoảng giữa đó vẫn có nhiều giá trị sử dụng. Trên thực tế, phần lớn “BI” chỉ ở mức “có vài cột dữ liệu, hãy vẽ một cột theo một cột khác”
Tác giả nói SQL là công cụ BI “self-service” duy nhất, nhưng thành thật mà nói tôi nghĩ đó là Excel
Nhiều công cụ BI gần như chỉ là tạo lại Excel với một giao diện mới hơn và vì thế kém quen thuộc hơn
Tôi nghĩ meme ghét Excel xuất phát từ quá khứ khi người ta cố làm những việc phức tạp bằng Excel
Nếu thao tác dữ liệu phức tạp thì dùng SQL, còn “hãy hiển thị cái này bằng biểu đồ tròn” thì dùng Excel, có khi thật sự không cần công cụ BI
Nếu nguồn dữ liệu nền đã được làm sạch, chuyển đổi và kiểm soát truy cập tốt, chỉ với VLOOKUP và pivot thôi cũng có thể đi xa một cách đáng kinh ngạc
Khi có từ hai nguồn dữ liệu trở lên, việc trao cơ hội self-service cho người dùng phi kỹ thuật luôn dẫn đến việc trộn dữ liệu ngoại tuyến
Rồi câu hỏi sẽ là “Đội dữ liệu ơi, tại sao dữ liệu của ‘các bạn’ không khớp với dữ liệu của ‘tôi’?”, và luôn kèm giả định rằng phía mình là đúng
Vấn đề cốt lõi là các công cụ hiện đại khác với desktop cổ điển như workstation Smalltalk hay Emacs
Những môi trường đó là một môi trường tích hợp hoàn chỉnh, mọi thứ đều nằm trong tay người dùng, và khái niệm lập trình cho người dùng cuối đã được tích hợp sẵn
Trong org-mode, bạn có thể tạo slide đẹp mắt trong chớp mắt, nhanh chóng viết và chạy các đoạn mã rồi lấy kết quả
Tuy nhiên xét từ góc độ dashboard thì có nhiều giới hạn. Dù có thể vẽ dữ liệu nhanh, kết quả gần như chỉ là một ảnh tĩnh thô; còn nếu muốn làm cho đẹp bằng PGF/TikZ thì mất quá nhiều thời gian nên khó trở thành lựa chọn, và vẫn là tĩnh
Bản thân Emacs là công cụ phù hợp, nhưng là công cụ của một thời đại cũ hơn
Công cụ hiện đại cung cấp thao tác hào nhoáng và nhanh hơn, nhưng chỉ cho phép những hành vi rất hạn chế, bị mắc kẹt trong UI không linh hoạt và cũng không tích hợp với thứ khác
R cùng với RStudio/quarto có lẽ là cách nhanh nhất để tạo nội dung nhanh, bừa bộn nhưng đẹp mắt, nhưng vẫn còn rất xa mới đạt được độ linh hoạt của Emacs
Cuối cùng, dường như không có giải pháp nào trừ khi viết lại toàn bộ stack phần mềm hiện đại dựa trên mô hình cổ điển và hiệu năng phần cứng hiện đại