---
title: "Bốn thứ AI làm được và ba thứ AI làm không được trong công việc BA"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong-cong-viec-ba"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Bốn thứ AI làm được và ba thứ AI làm không được trong công việc BA

> Bốn việc AI làm được trong công việc BA ERP kèm đầu vào phải chuẩn bị và chỗ phải kiểm lại, cùng ba việc không được giao cho AI và hậu quả nếu vẫn giao.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong-cong-viec-ba
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: AI trong công việc BA

Một buổi chiều trước hạn nộp tài liệu giải pháp, bạn dồn ghi chép khảo sát, lưu đồ và bảng khoảng trống vào một thư mục, mở công cụ AI trên máy, bảo nó viết theo đúng file mẫu, và mười lăm phút sau có một bản ba mươi trang đọc rất trôi.

Bản đó có mục lục, có mã yêu cầu, có mô tả từng màn hình, có cả phần đề xuất kế thừa đối tượng đối tác để thêm trường hạn mức công nợ kèm ghi chú là trường này không bắt buộc nhập. Bạn đọc lướt, thấy đúng mẫu, nên gửi đi.

Sáu tuần sau, tới buổi nghiệm thu, kế toán trưởng bên khách nói rằng mọi khách sỉ đều phải có hạn mức, không có hạn mức thì không được lên đơn. Trường đó lẽ ra phải bắt buộc, dữ liệu thì đã nhập hai trăm dòng theo trạng thái không bắt buộc, còn phần tích hợp với phần mềm kế toán đọc rất hợp lý nhưng không có bảng ánh xạ dữ liệu nào phía sau.

> Không dòng nào sai ngữ pháp, và cũng không dòng nào được ai xác nhận.

## Ranh giới của bài này

Trước khi vào từng việc, có ba chuyện cần thống nhất.

**Thứ nhất, tôi chỉ nói ở mức loại công cụ**, tức nhóm công cụ AI mà bạn mở trên máy, trỏ vào một thư mục rồi để nó tự đọc và tự viết file trong đó, chứ không nhận xét về một sản phẩm hay một mô hình cụ thể. Sản phẩm trong nhóm này đổi tên, đổi tính năng và đổi giá theo từng quý, nên một nhận định về sản phẩm cụ thể sẽ cũ đi trước khi bài này kịp cũ, và người đọc phải trả giá cho nhận định sai chứ không phải tôi.

**Thứ hai, công cụ chạy trên máy bạn không có nghĩa dữ liệu ở lại trên máy bạn.** Trừ khi mô hình cũng chạy trên chính máy đó, nội dung tài liệu vẫn được gửi đi để xử lý, và chuyện [đưa tài liệu dự án cho AI mà không lộ dữ liệu khách hàng](https://bahub.vn/khoa-hoc/erp-cho-ba/dua-tai-lieu-du-an-cho-ai-ma-khong-lo-du-lieu) đã có bài riêng.

**Thứ ba, tôi không phải chuyên gia AI**, và cách chia bốn với ba dưới đây chỉ là cách tôi sắp cho dễ nhớ, không phải chuẩn ngành.

## Việc thứ nhất, dựng khung tài liệu từ một dàn ý

Đây là việc AI làm ổn nhất và cũng dễ bị đánh giá quá cao nhất, bởi thứ nó tạo ra trông như tài liệu hoàn chỉnh trong khi mới là khung.

Đầu vào gồm ba thứ.

* **Thứ nhất là file mẫu của công ty bạn**, bỏ nguyên vào thư mục làm việc, bởi thiếu mẫu thì nó viết theo một cấu trúc nào đó nó từng thấy và bạn sửa lại còn lâu hơn tự viết.
* **Thứ hai là dàn ý bạn tự viết** ở mức tên mục kèm một dòng nội dung.
* **Thứ ba là dữ liệu nền có thật**, gồm thông tin doanh nghiệp, danh sách phân hệ và các mốc bàn giao.

Phần phải kiểm lại nằm đúng ở những chỗ bạn không đưa dữ liệu. **Thiếu đầu vào chỗ nào thì công cụ điền vào đó một ví dụ nghe rất hợp lý**, và mục danh sách bên liên quan là chỗ hay gặp nhất, nơi nó tự nghĩ ra tên vai trò cùng quyền hạn mà bên khách chưa từng nói ra. Đồng thời hãy đọc ngược phần mốc thời gian, tức hỏi mốc này đã có trong biên bản nào chưa và do ai chốt. Riêng chuyện [dự án cần bao nhiêu tài liệu](https://bahub.vn/khoa-hoc/erp-cho-ba/bo-tai-lieu-du-an-erp) thì đã có bài riêng, đừng để công cụ quyết hộ.

![Thiếu đầu vào chỗ nào, công cụ tự điền vào đó một ví dụ nghe rất hợp lý](https://bahub.vn/uploads/2026/11/1793631903723-pk1heh-bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong.webp "Thiếu đầu vào chỗ nào, công cụ tự điền vào đó một ví dụ nghe rất hợp lý")

## Việc thứ hai, chuyển biên bản họp thành danh sách yêu cầu nháp

Việc này tiết kiệm công nhất, vì nó thay bạn đọc mười trang ghi chép rời rạc rồi tách thành từng dòng có mã.

Đầu vào gồm biên bản đầy đủ chứ không phải bản tóm tắt, danh sách người dự họp kèm chức vụ và bộ phận để nó biết câu nào do ai nói, lưu đồ quy trình nếu đã vẽ, và quy ước mã yêu cầu của công ty bạn. **Thiếu danh sách người dự họp thì mọi câu trong biên bản nặng ngang nhau**, trong khi câu của người phụ trách kho khác hẳn câu của một bạn mới vào.

Phần phải kiểm lại có ba chỗ.

* **Chỗ thứ nhất là những câu khách nói dưới dạng giải pháp mà thực chất là mong muốn**, kiểu thêm cho anh cái nút duyệt ở đây, và công cụ chép thẳng thành một dòng yêu cầu; [cách bóc lời khách ra thành dòng yêu cầu thật](https://bahub.vn/khoa-hoc/erp-cho-ba/tu-loi-khach-noi-toi-dong-yeu-cau) là chủ đề của một bài khác.
* **Chỗ thứ hai là các dòng bị gộp**, khi hai nhu cầu khác nhau về người thực hiện bị gói chung, và tới lúc ước lượng thì không tách ra được.
* **Chỗ thứ ba là trạng thái xác nhận**, tức mỗi dòng phải ghi ai xác nhận và đã xác nhận chưa, bởi bản nháp do máy sinh ra không phân biệt nổi điều khách đã chốt với điều ai đó nói cho vui lúc giải lao.

## Việc thứ ba, sinh kịch bản kiểm thử từ mô tả luồng

Nếu tài liệu giải pháp viết đủ luồng chính, luồng thay thế, luồng ngoại lệ và quy tắc nghiệp vụ, thì sinh bộ ca kiểm thử từ đó là phần lặp đi lặp lại rất hợp với công cụ.

Đầu vào gồm tài liệu giải pháp đủ bốn mục vừa nêu, bảng mô tả trường có cột bắt buộc và có danh sách giá trị của các trường lựa chọn, cùng bộ dữ liệu mẫu để mỗi ca có thứ nhập vào. **Bảng trường không ghi trường nào bắt buộc thì bộ ca sinh ra bỏ hẳn nhóm kiểm tra ràng buộc nhập liệu.**

Phần phải kiểm lại nằm ở hai chỗ. **Một là kết quả mong đợi của mỗi ca phải viết ở tầng nghiệp vụ chứ không ở tầng màn hình**, trong khi công cụ hay viết ở tầng màn hình vì đó là thứ dễ suy ra từ mô tả giao diện. **Hai là nhóm ca ngoại lệ, chỗ nó gần như luôn sinh thiếu**, bởi mỗi quy tắc nghiệp vụ phải đẻ ra ít nhất một nhánh ngoại lệ và việc lật ngược từng quy tắc là việc của người viết.

Cần lưu ý rằng [kịch bản cho buổi nghiệm thu với người dùng](https://bahub.vn/khoa-hoc/erp-cho-ba/uat-va-pilot-trong-du-an-erp) khác hẳn ca kiểm thử của đội phát triển và đã có bài riêng. Tương tự, [việc sinh tài liệu hướng dẫn sử dụng từ tài liệu giải pháp](https://bahub.vn/khoa-hoc/erp-cho-ba/tu-srs-toi-user-guide-bang-ai) chỉ chạy được khi trong đó có ảnh màn hình và các thành phần đã đánh số, và đó cũng là một bài riêng.

## Việc thứ tư, rà soát tài liệu tìm chỗ thiếu và mâu thuẫn

Đây là việc trả về nhiều giá trị nhất trên mỗi phút bỏ ra, và cũng ít người dùng tới nhất.

Đầu vào là toàn bộ tài liệu của một tính năng nằm chung một thư mục, gồm lưu đồ, bảng khoảng trống, tài liệu giải pháp và bảng trường, cộng danh sách các điểm bạn muốn nó soi. Danh sách đó nên viết thành file riêng rồi dùng lại cho mọi dự án:

* mỗi quy tắc nghiệp vụ đã có nhánh ngoại lệ chưa
* mỗi trường trong bảng đã có trên ảnh màn hình chưa
* một đối tượng có bị gọi bằng hai cái tên không

![Rà soát chéo cả bộ tài liệu theo một danh sách điểm soi dùng lại được](https://bahub.vn/uploads/2026/11/1793631904396-qu252p-bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong.webp "Rà soát chéo cả bộ tài liệu theo một danh sách điểm soi dùng lại được")

Phần phải kiểm lại bắt đầu từ chỗ dễ bỏ sót nhất, là một ràng buộc phải nói ngay trong câu lệnh: **chỉ báo cáo, không được tự sửa, muốn sửa phải hỏi trước**. Với loại công cụ được quyền ghi vào thư mục, quên câu này thì nó có thể sửa luôn tài liệu của bạn, và cái nguy hiểm không phải bản sửa dở mà là bản sửa nghe hay hơn bản gốc trong khi đã lặng lẽ đổi một quy tắc khách chốt rồi.

Ngoài ra còn phải soát các cảnh báo sai, và theo tôi chúng dễ rơi vào những chỗ bạn cố tình không viết vì đã khai báo ngay đầu tài liệu rằng phần đó giữ nguyên hành vi mặc định của nền tảng.

## Chỗ khung trông đầy nhưng rỗng

Có một phần mà bốn việc trên không chạm tới, và cũng là chỗ người mới bị lừa nhiều nhất, đó là phần tích hợp với hệ thống bên ngoài.

Với hạng mục tích hợp, công cụ vẫn viết được vài trang gồm luồng đồng bộ, tần suất, cách xử lý lỗi, thậm chí gợi ý tên phương thức. Nhưng phần quyết định của một tài liệu tích hợp là **lấy tài liệu giao tiếp của bên kia ở đâu và ánh xạ từng trường dữ liệu ra sao**, mà hai thứ đó chỉ nằm trong tài liệu kỹ thuật của bên đối tác và trong danh mục thật của khách.

Không ai đưa chúng vào thư mục thì không công cụ nào bịa ra đúng được, nên phần này bạn phải đi xin tài liệu rồi tự lập bảng ánh xạ, và **đó là ranh giới rõ nhất giữa thứ suy ra được từ văn bản với thứ phải đi hỏi người**.

## Việc thứ nhất không giao được, quyết định phạm vi

Phạm vi không nằm trong tài liệu bạn đưa cho công cụ, mà nằm trong hợp đồng, trong phụ lục, trong những gì đội sale đã hứa lúc chốt deal.

Do đó khi công cụ đọc một biên bản khảo sát rồi liệt kê hai mươi yêu cầu, **nó không có cách nào biết ba trong số đó nằm ngoài phạm vi đã ký**. Hậu quả rất cụ thể:

1. yêu cầu ngoài phạm vi được viết thẳng vào tài liệu giải pháp
2. tài liệu gửi đi mà không ai phản đối
3. đội phát triển làm
4. và tới lúc quyết toán thì bạn hết căn cứ để gọi nó là yêu cầu phát sinh, vì chính tài liệu của bạn đã nhận nó là phần phải làm

[Ranh giới giữa lỗi và yêu cầu phát sinh](https://bahub.vn/khoa-hoc/erp-cho-ba/defect-hay-change-request) đã có bài riêng.

## Việc thứ hai không giao được, xác nhận quy tắc nghiệp vụ

> Điểm sắc nhất của toàn bộ chuyện dùng AI làm tài liệu gọn trong một câu: công cụ đoán được kiểu dữ liệu của một trường, nhưng không đoán được quy tắc nghiệp vụ đứng sau trường đó.

Quay lại trường hạn mức công nợ ở đầu bài. Chọn kiểu tiền tệ cho nó thì suy ra được từ ngữ nghĩa, và công cụ làm đúng. Nhưng trường đó có bắt buộc nhập hay không thì không tài liệu nào suy ra được, vì nó phụ thuộc chính sách bán hàng của doanh nghiệp: khách nói không phải ai cũng có hạn mức thì để không bắt buộc là đúng, còn mọi khách sỉ đều phải có hạn mức thì để không bắt buộc là sai.

**Hai lựa chọn trên giấy chỉ khác nhau một ô, còn hậu quả thì khác hẳn**, bởi phát hiện muộn nghĩa là sửa cấu hình trường, dọn lại dữ liệu đã nhập, rà lại chứng từ đã tạo trong lúc quy tắc còn lỏng.

![Bắt buộc hay không chỉ khác một ô, phát hiện muộn thì phải dọn cả đống dữ liệu](https://bahub.vn/uploads/2026/11/1793631906886-k80kgq-bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong.webp "Bắt buộc hay không chỉ khác một ô, phát hiện muộn thì phải dọn cả đống dữ liệu")

Ví dụ này còn một lớp nữa. Trên Odoo 19, phân hệ kế toán đã có sẵn hạn mức công nợ theo từng khách hàng, bật bằng thiết lập Sales Credit Limit, và **khi đơn bán vượt hạn mức thì hệ thống chỉ hiện cảnh báo chứ không chặn xác nhận đơn**.

Nghĩa là đề xuất kế thừa đối tác để thêm một trường mới ở đầu bài sai ngay từ gốc, bởi công cụ không biết nền tảng đã có gì, còn câu hỏi thật thì vẫn là câu hỏi nghiệp vụ, tức không có hạn mức hoặc vượt hạn mức thì cảnh báo là đủ hay phải chặn, và câu đó chỉ khách trả lời được.

Nên nhớ rằng **người xác nhận cũng phải đúng người**: một quy tắc do nhân viên nghiệp vụ mô tả mà người có thẩm quyền chưa duyệt thì chưa phải quy tắc, và công cụ không phân biệt được ai trong biên bản có quyền chốt.

## Việc thứ ba không giao được, chịu trách nhiệm khi tài liệu sai

Khi một con số hiển thị sai ở buổi nghiệm thu, câu hỏi đầu tiên luôn là tài liệu đã mô tả trường hợp này chưa, và người trả lời là bạn.

**Trách nhiệm không chuyển được sang công cụ**, vì thứ nằm trên trang ký là tên bạn và tên người duyệt bên khách. Hậu quả của việc quên điều này không nằm ở chỗ tài liệu sai, mà ở chỗ bạn phải giải trình một tài liệu mình chưa đọc kỹ, và không giải thích nổi vì sao mình viết một quy tắc như vậy còn mất uy tín hơn cả viết sai.

> Vì vậy quy ước đáng giữ là không gửi đi trang nào mình chưa đọc hết từng dòng, kể cả khi hạn nộp là chiều nay.

## Bốn thao tác cho mỗi lần dùng

Mỗi lần giao việc, hãy chạy qua bốn thao tác:

* Đưa file mẫu và dữ liệu nền vào thư mục trước khi ra câu lệnh
* Ghi rõ đầu ra cần gì, dài bao nhiêu, theo mẫu nào
* Ràng buộc chỉ báo cáo, muốn sửa phải hỏi trước
* Đọc lại toàn bộ output và đánh dấu chỗ chưa ai xác nhận

Trong trường hợp dự án gấp tới mức không kịp làm gì khác, thứ tự ưu tiên đổi lại: **bỏ việc nhờ dựng khung và giữ việc rà soát**, bởi viết vội thì cái thiếu và cái mâu thuẫn sinh ra nhiều hơn hẳn, mà một lượt soi chéo mười phút vẫn rẻ hơn một buổi nghiệm thu hỏng. Một số trường hợp khác thì ngược lại, chẳng hạn hạng mục thuần cấu hình, khi đó tự viết bản mô tả ngắn còn nhanh hơn chuẩn bị đầu vào cho công cụ.

Cuối cùng, có một chuyện đứng ngoài cả bảy mục trên: **đích đến không phải bộ tài liệu đẹp mà là hệ thống chạy được**, nên xong tài liệu thì việc tiếp theo vẫn là dựng thật phần đã mô tả rồi tự xem nó chạy có đúng như mình viết không. Và trước khi đưa bất kỳ tài liệu dự án nào vào một công cụ như vậy, còn một câu phải trả lời trước, đó là dữ liệu của khách nằm ở đâu sau khi bạn bấm gửi.

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/bon-thu-ai-lam-duoc-ba-thu-ai-lam-khong-duoc-trong-cong-viec-ba — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.