AI đang ngày càng xuất hiện nhiều hơn trong môi trường làm việc. Từ việc soạn thảo văn bản, tổng hợp thông tin, nghiên cứu, hỗ trợ lập kế hoạch cho đến phân tích dữ liệu, AI đang dần trở thành một phần trong cách nhiều nhân viên thực hiện công việc hằng ngày. Tuy nhiên, một câu hỏi đáng quan tâm hơn việc “doanh nghiệp có sử dụng AI hay không?” là: Vì sao một công cụ AI lại được sử dụng thường xuyên, trong khi rất nhiều công cụ khác chỉ được thử nghiệm một vài lần rồi bị bỏ quên?
Một bài thuyết trình được chia sẻ trên Speaker Deck vào ngày 05/08/2026 với tiêu đề “ふとした出会いで生まれたSkillが、社内利用1位になるまで”, có thể hiểu là “Một Skill ra đời từ một cuộc gặp gỡ tình cờ và trở thành công cụ được sử dụng nhiều nhất trong công ty”, đưa ra một trường hợp khá thú vị để trả lời câu hỏi này. Bài trình bày kể về quá trình ra đời và phát triển của bq-analysis, một Skill hỗ trợ phân tích dữ liệu bằng AI trong môi trường của Timee.
Điều thú vị nhất của câu chuyện nằm ngay trong thông điệp trung tâm của bài thuyết trình: công cụ này được tạo ra một cách tình cờ, nhưng việc nó lan rộng thì không hề tình cờ. Một ý tưởng có thể xuất hiện rất ngẫu nhiên, nhưng để biến ý tưởng đó thành một công cụ được nhiều người sử dụng cần cả một quá trình thử nghiệm, cải tiến, giảm rào cản tiếp cận và đặc biệt là lắng nghe người dùng.
Từ góc nhìn của một nhân viên hành chính, tôi cho rằng đây không chỉ là câu chuyện dành cho kỹ sư hay những người làm dữ liệu. Phương pháp phát triển công cụ trong bài trình bày có thể gợi ra nhiều cách tiếp cận thực tế cho các công việc văn phòng: bắt đầu từ một vấn đề cụ thể, thử nghiệm ở quy mô nhỏ, cải thiện dựa trên nhu cầu thực tế và biến những cách làm hiệu quả thành quy trình có thể chia sẻ cho nhiều người.
1. Bq-analysis là gì và giải quyết vấn đề nào?
Theo phần trình bày, bq-analysis là một Skill hỗ trợ phân tích dữ liệu trên BigQuery bằng ngôn ngữ tự nhiên. Thay vì phải tự xác định bảng dữ liệu, viết SQL rồi thực hiện truy vấn, người dùng có thể bắt đầu bằng một yêu cầu thông thường. Công cụ hỗ trợ xác định bảng phù hợp, tạo SQL, thực hiện truy vấn và đưa kết quả về để người dùng tiếp tục phân tích.
Quy trình này có thể hiểu đơn giản là: người dùng đặt câu hỏi, AI xác định dữ liệu cần thiết, tạo câu truy vấn, thực hiện truy vấn và cuối cùng hỗ trợ người dùng đi đến bước phân tích hoặc đưa ra nhận định.
Điểm đáng chú ý là tác giả không trình bày bq-analysis như một công nghệ có cơ chế kỹ thuật đặc biệt phức tạp. Phần cốt lõi của Skill thực chất nằm ở việc AI có thể thực hiện những thao tác BigQuery cần thiết. Điều tạo nên sự khác biệt lại là lượng thông tin về bối cảnh nội bộ được cung cấp cho AI. Theo slide, hệ thống này có khoảng 4.400 dòng Markdown, bao gồm các thông tin về thuật ngữ, định nghĩa chỉ số, cấu trúc dữ liệu, logic nghiệp vụ, quy trình đo lường và những hướng dẫn liên quan.
Đây là một chi tiết rất đáng chú ý khi nhìn từ góc độ ứng dụng AI. AI có thể có lượng kiến thức rất lớn, nhưng không mặc nhiên hiểu được “ngôn ngữ riêng” của một tổ chức. Một từ ngữ quen thuộc trong giao tiếp thông thường có thể mang một ý nghĩa khác trong môi trường doanh nghiệp. Bài trình bày đưa ra ví dụ về thuật ngữ “client”: trong bối cảnh nội bộ, từ này được dùng để chỉ cửa hàng, trong khi AI nếu chỉ dựa trên kiến thức phổ thông có thể hiểu theo nghĩa rộng hơn là khách hàng hoặc doanh nghiệp. Việc mô tả rõ những khác biệt như vậy giúp giảm khoảng cách giữa cách AI hiểu thông tin và cách nhân viên trong tổ chức thực sự sử dụng thông tin đó.
Theo tôi, đây là một bài học rất quan trọng đối với việc sử dụng AI trong công việc văn phòng. Chúng ta thường tập trung vào việc viết prompt sao cho thật rõ ràng, nhưng prompt chỉ là một phần của vấn đề. Nếu AI không có đủ bối cảnh, ngay cả một câu hỏi được viết rất tốt vẫn có thể dẫn đến kết quả chưa phù hợp. Ngược lại, khi AI được cung cấp những quy tắc, thuật ngữ, tiêu chuẩn và cách hiểu thống nhất, khả năng hỗ trợ công việc sẽ tốt hơn đáng kể.
2. Một ý tưởng nhỏ có thể trở thành điểm khởi đầu của một công cụ lớn
Câu chuyện về bq-analysis bắt đầu khá đơn giản. Tác giả tình cờ nhìn thấy một cách sử dụng Claude Code Skills và nhận ra rằng phương pháp này có thể áp dụng cho công việc phân tích dữ liệu. Thay vì bắt đầu bằng một dự án quy mô lớn, tác giả thử xây dựng một phiên bản đầu tiên để kiểm chứng ý tưởng.
Kết quả là chỉ sau khoảng 2 đến 3 giờ làm việc thực tế, phiên bản đầu tiên đã được tạo ra. Ngày 09/02, phiên bản 582 dòng được merge và bq-analysis chính thức ra đời.
Điểm này khiến tôi liên tưởng đến một cách tiếp cận rất khác với tư duy triển khai dự án truyền thống. Khi nghe đến một giải pháp mới, chúng ta thường nghĩ ngay đến việc phải xác định đầy đủ yêu cầu, lập kế hoạch, xin phê duyệt, phân bổ nguồn lực và sau đó mới bắt đầu triển khai. Với những hệ thống lớn, cách làm này hoàn toàn cần thiết. Nhưng với những thử nghiệm AI nhỏ, việc bắt đầu từ một phiên bản tối thiểu có thể mang lại nhiều lợi ích.
Thay vì phải trả lời ngay câu hỏi “giải pháp hoàn chỉnh sẽ như thế nào?”, chúng ta chỉ cần trả lời một câu hỏi nhỏ hơn: “Nếu thử cách này, nó có thực sự giúp công việc tốt hơn không?”
Nếu câu trả lời là có, chúng ta tiếp tục đầu tư. Nếu câu trả lời là không, chúng ta có thể thay đổi hoặc dừng lại mà không phải tiêu tốn quá nhiều nguồn lực.
Đây là một phương pháp tôi cho rằng rất phù hợp với công việc hành chính. Chẳng hạn, nếu mỗi tháng phải thực hiện một loại báo cáo giống nhau, không nhất thiết phải xây dựng ngay một hệ thống tự động hóa hoàn chỉnh. Có thể bắt đầu bằng việc sử dụng AI để tạo bản nháp, tổng hợp thông tin hoặc kiểm tra dữ liệu. Sau một vài lần sử dụng, chúng ta sẽ biết chính xác bước nào AI làm tốt, bước nào vẫn cần con người xử lý và phần nào đáng để tiếp tục cải thiện.
3. Một tháng đầu tiên: thêm, sắp xếp, loại bỏ và hoàn thiện
Sau khi được tạo ra, bq-analysis không đứng yên ở phiên bản đầu tiên. Trong khoảng một tháng, lượng nội dung của Skill tăng từ 582 dòng lên 1.823 dòng, tương đương khoảng 3,1 lần. Số lượng file cũng tăng từ 3 lên 7 file.
Nhưng điều đáng nói không chỉ nằm ở việc “thêm nhiều nội dung hơn”. Trong quá trình này, nhóm phát triển bổ sung danh sách bảng dữ liệu, thông tin phục vụ phân tích, các đường dẫn liên quan, thống nhất thuật ngữ nội bộ, bổ sung từ điển thuật ngữ và đồng thời loại bỏ những khu vực không được sử dụng.
Nói cách khác, quá trình phát triển không đơn thuần là thêm tính năng. Nó bao gồm cả việc thêm, sắp xếp, loại bỏ và hoàn thiện.
Đây là một nguyên tắc rất đáng học hỏi khi xây dựng bất kỳ công cụ hoặc quy trình nội bộ nào. Khi mới tạo một tài liệu, chúng ta thường có xu hướng đưa vào thật nhiều thông tin để không bỏ sót. Tuy nhiên, nhiều thông tin không đồng nghĩa với dễ sử dụng. Một tài liệu dài hàng chục trang nhưng không giúp người đọc biết mình phải làm gì tiếp theo có thể kém hiệu quả hơn một checklist ngắn nhưng rõ ràng.
Tương tự, một công cụ có rất nhiều chức năng nhưng người dùng không biết bắt đầu từ đâu cũng khó được sử dụng thường xuyên.
Vì vậy, cải tiến không phải lúc nào cũng có nghĩa là bổ sung thêm. Đôi khi, cải tiến tốt nhất là loại bỏ một phần không cần thiết.
Trong công việc hành chính, nguyên tắc này có thể áp dụng vào rất nhiều loại tài liệu: quy trình tổ chức sự kiện, hướng dẫn onboarding, checklist chuẩn bị cuộc họp, quy trình đặt phòng, hướng dẫn thanh toán hay các biểu mẫu nội bộ. Nếu một tài liệu liên tục được bổ sung nhưng nhân viên vẫn phải hỏi lại những câu cơ bản, có thể vấn đề không nằm ở việc tài liệu thiếu thông tin. Vấn đề có thể nằm ở cách thông tin được tổ chức.
4. Một công cụ tốt vẫn có thể khó lan tỏa nếu người dùng khó tiếp cận
Trong giai đoạn đầu, bq-analysis được đặt trong một repository liên quan đến Rails. Điều này phù hợp với nhóm kỹ thuật nhưng khiến việc tiếp cận trở nên khó khăn hơn đối với những người không phải backend engineer.
Đến ngày 02/03, một repository chuyên dành cho các Skill, có tên agent-skills, được tạo ra. Hai ngày sau, bq-analysis được chuyển sang repository mới và có thể được cài đặt thuận tiện hơn thông qua npm.
Đây là một thay đổi về cách tiếp cận hơn là một thay đổi về bản thân công nghệ, nhưng nó lại đóng vai trò quan trọng trong quá trình lan tỏa.
Một công cụ có thể rất tốt về mặt chức năng nhưng nếu người dùng phải trải qua quá nhiều bước để bắt đầu thì họ có thể không muốn sử dụng. Nguyên tắc này không chỉ đúng với phần mềm. Nó cũng đúng với những quy trình rất quen thuộc trong công việc văn phòng.
Một biểu mẫu nằm trong một thư mục khó tìm sẽ ít được sử dụng hơn một biểu mẫu có đường dẫn rõ ràng. Một quy trình dài và phức tạp sẽ khó được thực hiện hơn một checklist được trình bày theo từng bước. Một công cụ mà chỉ người tạo biết cách sử dụng sẽ khó trở thành tài sản chung của tổ chức.
Vì vậy, khi đánh giá một công cụ nội bộ, tôi cho rằng không nên chỉ hỏi “Nó có hoạt động không?”. Một câu hỏi quan trọng khác là: “Một người chưa từng sử dụng công cụ này có thể bắt đầu như thế nào?”
Nếu câu trả lời quá phức tạp, đó có thể chính là rào cản cần được giải quyết trước khi tiếp tục bổ sung thêm tính năng.
5. Từ một công cụ của nhóm kỹ thuật đến công cụ được nhiều bộ phận sử dụng
Sau khi được đưa sang repository riêng và trở nên dễ tiếp cận hơn, bq-analysis bắt đầu lan rộng với tốc độ khá nhanh.
Theo bài trình bày, ngay trong ngày được chia sẻ, công cụ đã được nhắc đến ở nhiều kênh nội bộ. Một số Product Manager thậm chí chủ động đăng ký tài khoản để có thể sử dụng bq-analysis. Chỉ khoảng 5 ngày sau, vào ngày 10/03, công cụ đã lan sang nhóm marketing và bắt đầu vượt ra ngoài phạm vi tổ chức sản phẩm.
Điều đáng chú ý là quá trình lan tỏa này không chỉ đến từ nhóm phát triển. Các Product Manager chủ động tổ chức những buổi chia sẻ vào ngày 28/04, 12/05 và 05/06. Đây đều là những hoạt động do phía người dùng tự tổ chức.
Một ví dụ khác cho thấy vai trò của người dùng trong quá trình phát triển là đề xuất bổ sung khả năng đưa ra những gợi ý mang tính thống kê. Thay vì đưa ngay tất cả khả năng này vào công cụ, nhóm phát triển nhận thấy việc đưa quá nhiều ngữ cảnh vào một chỗ có thể làm hệ thống trở nên nặng hơn. Vì vậy, họ lựa chọn tách phần lấy dữ liệu và phần phân tích thành hai bước, sau đó triển khai thay đổi này vào tháng 6.
Điều này cho thấy người dùng không chỉ “nhận” sản phẩm. Họ đưa ra vấn đề thực tế, còn người phát triển sử dụng những phản hồi đó để điều chỉnh thiết kế.
Theo số liệu trong bài trình bày, trong tổng số 29 commit của repository agent-skills, tác giả ban đầu thực hiện 9 commit, tương đương khoảng 31%. Điều đó có nghĩa phần lớn các thay đổi còn lại đến từ những người khác trong quá trình sử dụng.
Tôi cho rằng đây là một trong những yếu tố quan trọng nhất để một công cụ nội bộ có thể phát triển bền vững: người sử dụng trở thành một phần của quá trình cải tiến.
6. Vì sao Product Manager lại sử dụng nhiều hơn nhóm kỹ thuật?
Một điểm khá thú vị trong số liệu của bài trình bày là bq-analysis lại có mức độ tiếp cận và sử dụng nổi bật ở nhóm Product Manager, dù đây là công cụ liên quan trực tiếp đến dữ liệu và SQL.
Theo số liệu được ghi nhận trong khoảng thời gian từ 08/06 đến 04/08/2026, trên khoảng 200 thành viên sử dụng Claude Code, tỷ lệ tiếp cận bq-analysis của Product Manager là 65%, trong khi Data Analyst là 45% và Engineer là 36%. Tỷ lệ người sử dụng ít nhất một ngày mỗi tuần lần lượt là 77%, 40% và 41%. Số ngày sử dụng trung vị cũng cao hơn đáng kể ở nhóm Product Manager: 10 ngày, so với 5 ngày ở Data Analyst và 4 ngày ở Engineer.
Lý do có thể nằm ở chính “nỗi đau” mà công cụ giải quyết.
Một người thường xuyên sử dụng SQL vốn đã có khả năng truy vấn dữ liệu. Với họ, AI chủ yếu giúp giảm một phần thời gian và thao tác. Nhưng đối với những người không viết SQL thường xuyên, rào cản trước khi có bq-analysis lớn hơn nhiều.
Nếu muốn trả lời một câu hỏi bằng dữ liệu, họ có thể phải tìm đúng bảng dữ liệu, xác định người có thể hỗ trợ, giải thích câu hỏi, chờ truy vấn và sau đó mới bắt đầu phân tích.
Nếu AI có thể rút ngắn khoảng cách giữa “tôi có một câu hỏi” và “tôi có thể bắt đầu xem dữ liệu”, giá trị đối với nhóm này sẽ rất lớn.
Bài trình bày cũng cho biết tác giả đã từng nhận được những trao đổi từ Product Manager và Designer về mong muốn có thể hoàn thành phần SQL bằng AI. Điều này phù hợp với giả thuyết rằng bq-analysis đáp ứng đúng một rào cản cụ thể: không biết SQL hoặc phải mất nhiều công sức để thực hiện SQL khiến người dùng khó bắt đầu công việc phân tích.
Đây là một bài học quan trọng khi đánh giá một công cụ AI. Đừng chỉ hỏi công cụ làm được bao nhiêu việc. Hãy hỏi công cụ đang loại bỏ rào cản nào cho người sử dụng.
7. Vì sao bq-analysis trở thành công cụ được sử dụng rộng rãi?
Từ câu chuyện trên, có thể thấy ít nhất năm yếu tố góp phần vào khả năng lan tỏa của bq-analysis.
Đầu tiên, công cụ giải quyết một nhu cầu thực tế. Nó không được tạo ra chỉ vì AI đang là xu hướng. Nó xuất hiện từ một nhu cầu cụ thể liên quan đến phân tích dữ liệu.
Thứ hai, công cụ có thể được thử nghiệm rất nhanh. Phiên bản đầu tiên được tạo ra chỉ trong khoảng 2 đến 3 giờ. Điều này làm giảm đáng kể chi phí của việc kiểm chứng một ý tưởng.
Thứ ba, AI được cung cấp đầy đủ bối cảnh nội bộ. Hệ thống tài liệu khoảng 4.400 dòng giúp AI hiểu thuật ngữ, chỉ số, cấu trúc dữ liệu và logic nghiệp vụ. Đây chính là phần giúp một công cụ AI tổng quát trở nên hữu ích hơn trong một môi trường cụ thể.
Thứ tư, rào cản sử dụng được giảm xuống. Việc chuyển sang repository riêng và đơn giản hóa cách cài đặt giúp nhiều nhóm khác nhau có thể tiếp cận công cụ.
Cuối cùng, và có lẽ cũng là yếu tố quan trọng nhất, người sử dụng tham gia vào quá trình cải tiến. Họ chia sẻ, tổ chức các buổi hướng dẫn, đưa ra đề xuất và thậm chí trực tiếp đóng góp vào repository.
Những yếu tố này tạo thành một vòng lặp rất tự nhiên: có vấn đề → thử nghiệm → sử dụng → nhận phản hồi → cải tiến → có thêm người sử dụng → tiếp tục nhận phản hồi.
Khi vòng lặp này hoạt động tốt, công cụ không cần phải được “đẩy” đến người dùng quá nhiều. Giá trị của nó tự tạo ra động lực để người dùng tiếp tục sử dụng và giới thiệu cho người khác.
8. Được sử dụng nhiều không có nghĩa là phải bắt tất cả mọi người sử dụng
Một quan điểm khác trong bài trình bày cũng rất đáng chú ý: không nhất thiết phải đưa một Skill đến 100% nhân viên.
Điều này có vẻ trái với cách chúng ta thường đánh giá một sáng kiến trong doanh nghiệp. Khi triển khai một công cụ mới, chúng ta thường quan tâm đến tỷ lệ adoption: bao nhiêu người đã sử dụng, bao nhiêu bộ phận đã triển khai và bao nhiêu người đang hoạt động trên hệ thống.
Tuy nhiên, tỷ lệ sử dụng không phải lúc nào cũng phản ánh giá trị thực.
Một công cụ được 30 người sử dụng thường xuyên và thực sự giúp họ giải quyết một vấn đề quan trọng có thể có giá trị hơn một công cụ được 300 người sử dụng một lần rồi không quay lại.
Với AI, điều này càng rõ ràng bởi mỗi vị trí có nhu cầu khác nhau. Một công cụ phân tích dữ liệu có thể cực kỳ hữu ích với Product Manager nhưng không nhất thiết cần thiết đối với một nhân viên hành chính. Ngược lại, một công cụ hỗ trợ quản lý sự kiện hoặc tổng hợp thông tin có thể rất hữu ích với bộ phận hành chính nhưng không mang lại nhiều giá trị cho kỹ sư.
Vì vậy, thay vì cố gắng khiến tất cả mọi người sử dụng cùng một công cụ, có thể hợp lý hơn nếu tạo ra một môi trường để mỗi nhóm có thể tìm thấy những cách ứng dụng AI phù hợp với công việc của mình.
9. Bài học đầu tiên cho công việc hành chính: Bắt đầu từ vấn đề, không phải từ công cụ
Là một nhân viên hành chính, tôi không trực tiếp làm công việc phân tích dữ liệu hoặc phát triển phần mềm. Nhưng chính vì vậy, câu chuyện về bq-analysis lại khiến tôi nghĩ nhiều hơn về cách AI có thể được ứng dụng vào những công việc tưởng như rất thông thường.
Thay vì bắt đầu bằng câu hỏi “Hôm nay tôi có thể dùng AI để làm gì?”, tôi cho rằng câu hỏi hiệu quả hơn là: “Trong công việc của mình, việc gì đang lặp đi lặp lại và tiêu tốn nhiều thời gian?”
Có thể đó là việc soạn thông báo nội bộ, tổng hợp danh sách tham dự, chuẩn bị agenda cho cuộc họp, tạo checklist sự kiện, tổng hợp phản hồi, chuẩn bị biên bản, theo dõi đầu việc sau cuộc họp hoặc xử lý thông tin đến từ nhiều nguồn khác nhau.
Không phải tất cả những nhiệm vụ đó đều cần AI. Nhưng một số bước trong mỗi nhiệm vụ có thể được AI hỗ trợ.
Điểm quan trọng là xác định đúng “nỗi đau” trước khi lựa chọn công cụ.
Nếu một công việc chỉ mất 2 phút mỗi tuần thì việc tự động hóa có thể không đáng. Nhưng nếu một công việc mất 30 phút và phải thực hiện hàng chục lần mỗi tháng, đó có thể là một ứng viên rất tốt để thử nghiệm.
Đây chính là cách tôi nghĩ bq-analysis đã tạo ra giá trị: nó không bắt đầu bằng câu hỏi “AI có thể làm gì?”, mà bắt đầu từ một nhu cầu cụ thể liên quan đến dữ liệu.
10. Bài học thứ hai: Cung cấp bối cảnh để AI hiểu đúng công việc
Một trong những bài học rõ ràng nhất từ bq-analysis là AI cần được cung cấp ngữ cảnh.
Trong công việc hành chính, điều này có thể bắt đầu từ những thứ rất đơn giản.
Nếu thường xuyên sử dụng AI để soạn thông báo nội bộ, có thể chuẩn hóa cách viết tiêu đề, cách trình bày thời gian và địa điểm, cách xưng hô, cấu trúc nội dung, cách viết song ngữ và những thông tin bắt buộc phải có.
Nếu sử dụng AI để hỗ trợ tổ chức sự kiện, có thể xây dựng checklist về địa điểm, thời gian, số lượng người tham dự, thiết bị, đồ ăn, truyền thông, hậu cần và những công việc cần hoàn thành trước ngày diễn ra.
Nếu sử dụng AI để tổng hợp báo cáo, có thể thống nhất định nghĩa của từng chỉ tiêu và cách trình bày kết quả.
Điều này không chỉ giúp AI trả lời tốt hơn. Nó còn giúp con người làm việc nhất quán hơn.
Theo tôi, đây là một lợi ích rất đáng chú ý của việc chuẩn hóa thông tin cho AI. Khi phải giải thích cho AI một quy trình, chúng ta cũng có cơ hội nhìn lại quy trình đó và nhận ra những điểm trước đây chưa được viết thành quy tắc rõ ràng.
11. Bài học thứ ba: Đừng cố tạo ra giải pháp hoàn hảo ngay từ đầu
Bq-analysis không bắt đầu với một hệ thống hoàn chỉnh. Nó bắt đầu với 582 dòng và sau đó được phát triển thành 1.823 dòng trong khoảng một tháng. Trong quá trình đó, có thông tin được bổ sung, có nội dung được chuẩn hóa và có những phần không được sử dụng bị loại bỏ.
Đây là cách tiếp cận tôi cho rằng rất phù hợp với những thử nghiệm AI trong công việc hằng ngày.
Ví dụ, nếu muốn dùng AI để hỗ trợ tổ chức một sự kiện nội bộ, không nhất thiết phải xây dựng ngay một “trợ lý sự kiện AI” với hàng chục chức năng. Có thể bắt đầu bằng một nhiệm vụ rất nhỏ: cung cấp thông tin về sự kiện và yêu cầu AI tạo checklist chuẩn bị.
Sau một vài lần sử dụng, chúng ta sẽ biết checklist thường thiếu gì, thông tin nào cần được cung cấp ngay từ đầu, bước nào vẫn phải làm thủ công và phần nào có thể tiếp tục tự động hóa.
Khi đó, phiên bản thứ hai sẽ được xây dựng dựa trên trải nghiệm thực tế thay vì giả định.
Đây chính là tinh thần của việc thử nghiệm nhanh: không cần hoàn hảo ngay từ đầu, nhưng phải có khả năng học từ mỗi lần sử dụng.
12. Bài học thứ tư: Giảm rào cản để tăng khả năng áp dụng
Câu chuyện chuyển bq-analysis sang repository riêng cũng có thể được áp dụng vào những công việc rất đời thường.
Nếu có một mẫu báo cáo thường xuyên được sử dụng, hãy đặt nó ở nơi dễ tìm.
Nếu có một quy trình thường xuyên được hỏi lại, hãy biến nó thành một hướng dẫn ngắn hoặc checklist.
Nếu có một prompt AI thường xuyên được sử dụng, hãy chuẩn hóa thành một mẫu chung thay vì để từng người tự viết lại từ đầu.
Nếu có một tài liệu quan trọng, hãy đặt tên và cấu trúc thư mục sao cho người khác có thể tìm thấy mà không cần hỏi người tạo.
Những thay đổi này không mang tính “công nghệ cao”, nhưng chúng có thể tạo ra tác động rất lớn đến adoption.
Một giải pháp càng dễ bắt đầu, khả năng được thử nghiệm càng cao. Khi người dùng thử nghiệm và nhận thấy giá trị, khả năng họ tiếp tục sử dụng cũng cao hơn.
Vì vậy, nếu muốn một công cụ hoặc quy trình được sử dụng rộng rãi, chúng ta không chỉ cần quan tâm đến chất lượng của giải pháp mà còn phải quan tâm đến trải nghiệm của người sử dụng.
13. Bài học thứ năm: Người dùng nên là một phần của quá trình phát triển
Tôi đặc biệt ấn tượng với việc bq-analysis được cải thiện không chỉ bởi người tạo ra nó mà còn bởi những người sử dụng.
Các Product Manager chủ động tổ chức những buổi chia sẻ. Họ đưa ra đề xuất mới. Một số thay đổi trong repository cũng đến từ những người khác ngoài tác giả ban đầu.
Điều này tạo ra một mô hình phát triển khá khác so với cách làm “một nhóm xây dựng, những nhóm khác chỉ sử dụng”.
Trong mô hình mới, người sử dụng có thể phát hiện vấn đề nhanh nhất bởi họ đang trực tiếp làm việc với công cụ. Họ biết bước nào gây khó khăn, tính năng nào thực sự hữu ích và tính năng nào không cần thiết.
Đối với các công cụ nội bộ, đây là một nguồn phản hồi rất giá trị.
Trong công việc hành chính, chúng ta có thể áp dụng điều này bằng một cách rất đơn giản: sau khi đưa một biểu mẫu, checklist hoặc quy trình mới vào sử dụng, hãy hỏi người sử dụng xem điểm nào gây khó khăn.
Có thể chỉ cần ba câu hỏi:
“Điểm nào khiến bạn mất thời gian nhất?”
“Có thông tin nào bạn thường xuyên phải hỏi lại không?”
“Nếu được thay đổi một điều, bạn muốn thay đổi điều gì?”
Ba câu hỏi này có thể cung cấp nhiều thông tin hơn một lần đánh giá mang tính hình thức.
14. AI nên giúp mở rộng năng lực, không chỉ giúp tiết kiệm thời gian
Từ câu chuyện của bq-analysis, tôi cho rằng một cách nhìn rất đáng chú ý về AI là: AI không chỉ giúp một người làm công việc nhanh hơn, mà còn có thể giúp họ bắt đầu làm những việc trước đây gặp rào cản về chuyên môn.
Một Product Manager không nhất thiết phải trở thành chuyên gia SQL chỉ để trả lời một câu hỏi dữ liệu đơn giản. Một nhân viên hành chính không nhất thiết phải trở thành chuyên gia phân tích để hiểu một bảng dữ liệu cơ bản. Một người không chuyên về viết nội dung có thể dùng AI để tạo bản nháp đầu tiên rồi dành thời gian cho việc kiểm tra và chỉnh sửa.
Trong những trường hợp như vậy, AI không thay thế chuyên môn của con người. Nó giúp thu hẹp khoảng cách giữa “tôi chưa biết làm việc này” và “tôi có thể bắt đầu từ đâu?”.
Theo tôi, đây mới là một trong những giá trị lớn nhất của AI trong môi trường doanh nghiệp.
Nếu chỉ đo hiệu quả AI bằng số phút tiết kiệm được, chúng ta có thể bỏ qua một tác động lớn hơn: AI có thể làm cho một số năng lực trở nên dễ tiếp cận hơn đối với nhiều người.
15. Tuy nhiên, AI không thể thay thế bước kiểm tra của con người
Càng sử dụng AI trong công việc, một nguyên tắc càng trở nên quan trọng: kết quả do AI tạo ra không mặc nhiên đồng nghĩa với kết quả chính xác.
Bản thân nhóm phát triển bq-analysis cũng đang tiếp tục xây dựng cơ chế kiểm tra độ chính xác và theo dõi các vấn đề phát sinh từ kết quả phân tích. Bài trình bày cho biết một trong những câu hỏi đang được quan tâm là liệu kết quả mà công cụ đưa ra có thực sự chính xác hay không.
Điều này đặc biệt quan trọng trong công việc hành chính.
Nếu AI hỗ trợ viết một thông báo, con người cần kiểm tra ngày, giờ, địa điểm và các thông tin quan trọng.
Nếu AI hỗ trợ tổng hợp dữ liệu, cần kiểm tra lại số liệu gốc.
Nếu AI hỗ trợ soạn một tài liệu liên quan đến quy trình hoặc chính sách, người phụ trách vẫn cần kiểm tra nội dung trước khi sử dụng.
AI có thể là người hỗ trợ xử lý, nhưng con người vẫn cần là người chịu trách nhiệm về kết quả cuối cùng.
Vì vậy, quy trình phù hợp không nên là:
Con người yêu cầu → AI trả lời → sử dụng ngay.
Thay vào đó nên là:
Con người yêu cầu → AI hỗ trợ → con người kiểm tra → chỉnh sửa → sử dụng.
Theo tôi, kỹ năng sử dụng AI tốt không chỉ nằm ở việc biết cách đặt câu hỏi mà còn nằm ở khả năng đánh giá đầu ra một cách có trách nhiệm.
16. Đừng quá phụ thuộc vào một công cụ cụ thể
Một điểm rất thú vị ở phần cuối bài trình bày là tác giả không xem việc duy trì bq-analysis mãi mãi là mục tiêu.
Bài trình bày thẳng thắn đề cập khả năng vài tháng sau công cụ có thể không còn được sử dụng. Một giải pháp tốt hơn có thể xuất hiện, hoặc bản thân BigQuery có thể được bổ sung những tính năng AI mạnh hơn.
Điều này không có nghĩa công cụ hiện tại thất bại.
Ngược lại, nó cho thấy mục tiêu thực sự không phải là bảo vệ một phần mềm cụ thể.
Mục tiêu lớn hơn là xây dựng một môi trường trong đó nhân viên có thể sử dụng AI để vượt qua một số ranh giới về chuyên môn và làm việc hiệu quả hơn.
Đây là tư duy rất phù hợp với tốc độ thay đổi của công nghệ hiện nay. Nếu một doanh nghiệp đặt mục tiêu “tất cả nhân viên phải sử dụng công cụ X”, mục tiêu đó có thể nhanh chóng trở nên lỗi thời.
Nhưng nếu mục tiêu là “nhân viên biết cách nhận diện vấn đề, thử nghiệm công cụ phù hợp, kiểm tra kết quả và cải thiện quy trình bằng AI”, thì năng lực này có thể tồn tại lâu hơn nhiều so với bất kỳ phần mềm cụ thể nào.
17. Từ câu chuyện của bq-analysis đến cách nhìn mới về AI trong công việc
Nhìn lại toàn bộ câu chuyện, bq-analysis bắt đầu từ một ý tưởng khá tình cờ. Một người nhìn thấy một cách làm mới và quyết định thử nghiệm. Chỉ trong vài giờ, phiên bản đầu tiên được tạo ra. Sau đó, công cụ được bổ sung thông tin, các thuật ngữ được thống nhất, những phần không cần thiết được loại bỏ và cách tiếp cận tiếp tục được điều chỉnh.
Khi rào cản sử dụng được giảm xuống, người dùng từ những nhóm khác bắt đầu tiếp cận. Họ không chỉ sử dụng mà còn chia sẻ cho nhau, tổ chức các buổi học hỏi và đưa ra những đề xuất mới. Những đề xuất đó tiếp tục được đưa trở lại quá trình phát triển.
Nếu tóm tắt toàn bộ quá trình bằng một chuỗi đơn giản, có thể hình dung như sau:
Vấn đề thực tế → Thử nghiệm nhỏ → Cải tiến → Giảm rào cản → Người dùng tham gia → Lan tỏa.
Theo tôi, đây mới là phần đáng học hỏi nhất của bài thuyết trình.
AI trong doanh nghiệp không nhất thiết phải bắt đầu bằng một dự án lớn. Một thay đổi nhỏ trong cách làm việc cũng có thể trở thành điểm khởi đầu cho một quy trình mới.
Đối với công việc hành chính, điều này càng có ý nghĩa bởi rất nhiều nhiệm vụ được lặp lại mỗi ngày. Nếu quan sát kỹ, chúng ta có thể nhận ra những bước đang tiêu tốn thời gian nhưng không nhất thiết tạo ra nhiều giá trị: nhập lại thông tin, tìm kiếm tài liệu, định dạng văn bản, tổng hợp phản hồi, chuẩn bị bản nháp hoặc kiểm tra checklist.
Đó có thể là những điểm bắt đầu phù hợp để thử nghiệm AI.
Tuy nhiên, việc ứng dụng AI cũng không nên trở thành mục tiêu tự thân. Không phải nhiệm vụ nào cũng cần AI và không phải công cụ nào cũng cần được đưa vào quy trình. Một giải pháp chỉ thực sự có giá trị khi nó giải quyết được một vấn đề rõ ràng, giúp công việc thuận tiện hơn và vẫn đảm bảo chất lượng cũng như trách nhiệm của người thực hiện.
18. Kết luận: Công cụ có thể thay đổi, nhưng cách tư duy có thể được giữ lại
Điều tôi rút ra từ câu chuyện về bq-analysis không phải là “chúng ta cần xây dựng một công cụ giống như vậy”. Bài học quan trọng hơn nằm ở cách một ý tưởng được biến thành một giải pháp có giá trị.
Một công cụ không nhất thiết phải bắt đầu hoàn hảo. Nó có thể bắt đầu từ một thử nghiệm rất nhỏ. Sau đó, chính người sử dụng sẽ cho chúng ta biết điều gì cần bổ sung, điều gì cần thay đổi và điều gì không thực sự cần thiết.
Một công cụ cũng không nhất thiết phải được triển khai cho tất cả mọi người ngay từ đầu. Nếu nó giải quyết đúng một vấn đề, nhóm người có nhu cầu sẽ có lý do để sử dụng. Nếu nó thực sự hữu ích, người dùng có thể trở thành người giới thiệu và thậm chí là người đóng góp cho quá trình cải tiến.
Đối với công việc hành chính, tôi cho rằng đây là một cách tiếp cận rất thực tế. Thay vì cố tìm một “công cụ AI hoàn hảo”, chúng ta có thể bắt đầu bằng việc quan sát chính công việc của mình.
Có bước nào đang lặp đi lặp lại? Có thông tin nào luôn phải tổng hợp thủ công? Có quy trình nào mọi người thường xuyên phải hỏi lại? Có công việc nào trước đây cần nhiều thời gian nhưng có thể được AI hỗ trợ ở một phần?
Nếu câu trả lời là có, đó có thể chính là nơi để bắt đầu một thử nghiệm nhỏ.
Sau đó, điều quan trọng là phải đánh giá kết quả một cách thực tế. AI có thực sự tiết kiệm thời gian không? Chất lượng công việc có được cải thiện không? Có phát sinh lỗi mới không? Người khác có dễ sử dụng lại không? Có thể chuẩn hóa thành một quy trình hay không?
Nếu câu trả lời tích cực, chúng ta tiếp tục cải thiện. Nếu không, chúng ta có thể thay đổi hoặc dừng lại.
Câu chuyện của bq-analysis cũng cho thấy một điều khác: chúng ta không nhất thiết phải biết trước công cụ nào sẽ tồn tại trong vài năm tới. Công nghệ thay đổi, sản phẩm thay đổi và những cách làm mới sẽ tiếp tục xuất hiện.
Điều cần được duy trì không phải là một phần mềm cụ thể.
Đó là khả năng nhận diện vấn đề, thử nghiệm nhanh, kiểm tra kết quả, học từ người sử dụng và liên tục cải thiện cách làm việc.
Từ một ý tưởng tình cờ đến một công cụ được sử dụng rộng rãi, bq-analysis cho thấy AI chỉ thực sự tạo ra giá trị khi nó gắn với một nhu cầu cụ thể và được đặt vào đúng bối cảnh.
Và có lẽ đây cũng là cách phù hợp nhất để chúng ta tiếp cận AI trong công việc hằng ngày: không bắt đầu bằng câu hỏi “AI có thể làm được gì?”, mà bắt đầu bằng câu hỏi đơn giản hơn:
“Công việc nào của tôi có thể được làm tốt hơn?”
Nếu trả lời được câu hỏi đó, việc tìm đến AI có thể trở nên tự nhiên hơn rất nhiều.
Nguồn tham khảo
1. Speaker Deck – “ふとした出会いで生まれたSkillが、社内利用1位になるまで”, tác giả earlgrayMK, đăng ngày 05/08/2026.
Xem bài trình bày trên Speaker Deck
2. Bài viết bổ sung và phần giải thích chi tiết của tác giả trên Zenn, được tác giả giới thiệu trực tiếp từ trang Speaker Deck để cung cấp thêm phần diễn giải cho nội dung thuyết trình.