Phần 01
Thay đổi thật nằm ở chỗ nào
Trong hai thập kỷ, ERP là nơi ghi lại việc đã xảy ra. Nhân viên nhập đơn, kế toán hạch toán, thủ kho ghi nhập xuất. Hệ thống không tự làm gì cả: không ai bấm thì không có gì chạy. Chi phí của mô hình đó không nằm ở tiền phần mềm, mà ở độ trễ giữa hai lần có người bấm — đơn nằm chờ duyệt qua đêm, cảnh báo tồn kho không ai đọc, công nợ quá hạn phát hiện vào kỳ đối soát sau.
Agentic ERP đảo chiều mặc định đó. Thay vì chờ thao tác, hệ thống phản ứng theo tín hiệu: một đơn hàng vừa xác nhận, một hoá đơn vừa quá hạn, một mã hàng vừa chạm tồn an toàn. Đây không phải chatbot gắn thêm bên cạnh — điểm khác biệt là agent nằm trong cùng cơ sở dữ liệu nghiệp vụ, nên nó đọc được ngữ cảnh và gọi được các tác vụ có sẵn.
Hai mô hình, cùng một bộ dữ liệu
Hệ thống biết, nhưng chờ người bấm.
Dữ liệu đầy đủ và chính xác, nhưng chỉ chuyển thành hành động khi có người mở màn hình, đọc, và quyết định. Mọi cải tiến vận hành đều phải đi qua việc thêm người hoặc thêm họp.
Hệ thống biết, và tự đề xuất hoặc tự làm.
Cùng dữ liệu đó, nhưng gắn thêm luật kích hoạt và quyền thao tác. Việc lặp lại, có quy tắc rõ ràng, khối lượng lớn thì chuyển cho máy; người tập trung vào ngoại lệ.
Đừng đọc bảng trên như “cũ và mới”. Một hệ thống ghi nhận sạch sẽ vẫn tốt hơn một hệ thống thực thi chạy trên dữ liệu bẩn. Thứ tự đúng là làm sạch trước, tự động sau — xem phần 07.
Phần 02
Bên trong một agent: bạn thật sự cấu hình cái gì
Bỏ hết từ ngữ tiếp thị đi thì một “nhân sự số” chỉ là bốn nhóm cấu hình. Biết tên bốn nhóm này là đủ để ngồi họp với nhà triển khai mà không bị dắt.
Chỉ dẫn hệ thống System prompt
Đoạn mô tả vai trò và giới hạn của agent: nó là ai, phục vụ việc gì, cái gì thì phải dừng lại hỏi người. Viết bằng tiếng thường, không phải mã.
Chủ đề và công cụ Topics và tools
Mỗi chủ đề gom một nhóm hướng dẫn hẹp cùng danh sách công cụ được phép gọi. Công cụ mới là thứ thật sự tạo ra thay đổi trên dữ liệu — agent chỉ chọn gọi công cụ nào.
Nguồn tri thức Sources
Tài liệu nội bộ mà agent được đọc để trả lời có căn cứ: quy chế, biểu giá, hướng dẫn xử lý khiếu nại. Nguồn sai thì câu trả lời sai một cách rất tự tin.
Tín hiệu kích hoạt Automation rules
Luật tự động gắn vào vòng đời bản ghi — vừa tạo, vừa đổi trạng thái, tới hạn — hoặc lịch chạy định kỳ. Đây là chỗ biến “trợ lý khi được hỏi” thành “chạy nền không ai nhìn”.
Chú ý cách gọi tên. Tài liệu bán hàng hay gộp bốn nhóm này thành “bốn trụ cột” và gọi công cụ là “kỹ năng”. Khi vào cấu hình thật, hãy hỏi đúng tên đối tượng trên màn hình — nếu nhà triển khai không chỉ được ra từng nhóm trên hệ thống của bạn, thì phần trình bày mới chỉ là slide.
Phần 03
Bốn điều ít khi có trong brochure
Bốn điểm dưới đây không phải lý do để hoãn dự án. Chúng là bốn câu hỏi mà nếu nhà triển khai trả lời được ngay trên hệ thống thật, bạn biết mình đang làm việc với người hiểu nghề; còn nếu họ chuyển sang nói về lợi ích, thì bạn vừa biết một điều quan trọng hơn.
Phần 04
Bốn điều đó, nói rõ ra
Phần này viết theo tài liệu kỹ thuật công khai của nhà cung cấp nền tảng và hai phân tích độc lập — nguồn liệt kê ở phần 09. Chỗ nào các nguồn chưa thống nhất, ghi chú ngay tại chỗ thay vì làm tròn.
Agent mượn quyền của một tài khoản
Không có bảng phân quyền riêng theo từng agent. Agent hành động trong khuôn khổ quyền của người dùng mà nó chạy dưới danh nghĩa — cấp cho tài khoản đó quyền quản trị là cấp cho agent quyền quản trị.
Việc phải làm: yêu cầu một tài khoản kỹ thuật riêng cho mỗi agent, quyền cắt hẹp tới từng phân hệ, và không bao giờ dùng tài khoản quản trị.
Quyền cộng dồn, mặc định là cho phép
Trong mô hình bảo mật của các nền tảng dạng này, các nhóm quyền cộng lại chứ không giao nhau: thêm một nhóm “chỉ đọc” lên trên nhóm sẵn có không lấy đi thứ gì. Và với luật lọc bản ghi, khi không có luật nào áp cho một mô hình thì thao tác được cho qua.
Việc phải làm: nghiệm thu bằng cách đăng nhập đúng tài khoản của agent rồi thử mở những gì nó không được xem. Đọc bảng cấu hình không thay thế được phép thử này.
Mặc định là đọc, không phải ghi
Trợ lý có sẵn khi mua về thường chỉ mở màn hình và tổng hợp báo cáo, không tạo hay sửa dữ liệu. Khả năng ghi đến từ các công cụ được gắn thêm — và phần chạy thật của công cụ là một tác vụ do người viết. AI chọn gọi công cụ nào; nó không tự bảo đảm nghiệp vụ đúng.
Việc phải làm: tách bạch trong hợp đồng đâu là tính năng có sẵn, đâu là phần phải phát triển — vì phần thứ hai mới là nơi phát sinh chi phí và rủi ro.
Nhật ký ghi cái gì đã đổi, không ghi vì sao
Thay đổi trên dữ liệu có thể ghi vết ở tầng cơ sở dữ liệu. Nhưng chuỗi suy luận dẫn tới quyết định đó — agent đã đọc gì, chọn công cụ nào, vì lý do gì — thì không mặc định được lưu lại. Khi cần giải trình một quyết định sai, đó chính là phần bị thiếu.
Việc phải làm: đưa yêu cầu lưu vết lời gọi công cụ vào phạm vi dự án ngay từ đầu. Ghi chú: điểm này lấy từ một nguồn có bán sản phẩm giải quyết đúng vấn đề đó, nên hãy đề nghị nhà triển khai chứng minh ngược lại trên hệ thống thật.
Phần 05
Chi phí thật nằm ở đâu
Câu “ERP mã nguồn mở nên rẻ” đúng với phần bản quyền phần mềm và sai với phần còn lại. Với dự án gắn AI, chi phí dịch chuyển sang bốn chỗ mà bảng báo giá thường không có dòng riêng.
| Khoản | Vì sao dễ bị bỏ sót | Hỏi gì trong đàm phán |
|---|---|---|
| Hạng giấy phép | Tính năng agent thường thuộc bản thương mại, không phải bản cộng đồng miễn phí. Các nguồn công khai chưa thống nhất về ranh giới này. | Yêu cầu ghi rõ trong hợp đồng: tính năng nào thuộc hạng nào, và giá khi số người dùng tăng gấp đôi. |
| Khoá API mô hình | Tuỳ cách bạn chạy hệ thống mà nhà cung cấp nền tảng lo phần kết nối, hoặc bạn phải tự mang khoá của mình và trả trực tiếp cho hãng mô hình. | Chạy trên hạ tầng nào thì ai trả tiền mô hình? Chi phí đó biến động theo lượng dùng, nên có trần không? |
| Làm sạch dữ liệu | Danh mục khách hàng trùng, mã hàng đặt tuỳ hứng, quy trình duyệt mỗi nơi một kiểu. Đây thường là khoản lớn nhất và ít khi nằm trong báo giá. | Ai làm, trong bao lâu, nghiệm thu bằng tiêu chí nào? Nếu câu trả lời là “vừa làm vừa chỉnh” thì đó là ngân sách mở. |
| Mã tuỳ biến | Mỗi dòng mã viết thêm là một khoản bảo trì và một rào cản khi nâng cấp phiên bản. Chi phí này hiện ra từ năm thứ hai. | Bao nhiêu phần trăm yêu cầu xử lý được bằng cấu hình chuẩn? Phần còn lại nâng cấp lên phiên bản sau thì ai chịu? |
Một dấu hiệu nhận biết nhanh. Nếu ai đó đưa bạn bảng so sánh chi phí 5 năm hoặc bảng tính hoàn vốn mà không kèm giả định đầu vào — quy mô, đơn giá, tỉ lệ việc tự động hoá được, nguồn của từng con số — thì đó là tài liệu tiếp thị, không phải mô hình tài chính. Hãy xin phần giả định. Không có phần đó thì con số cuối cùng không kiểm chứng được.
Phần 06
Bộ câu hỏi trước khi duyệt ngân sách
Mang đúng ba nhóm câu hỏi này vào buổi làm việc với nhà triển khai. Mục tiêu không phải bắt bí, mà là tách thứ chạy được hôm nay khỏi thứ sẽ phải làm thêm — trước khi ký, không phải sau.
Nhóm 1 — Dữ liệu, điều kiện tiên quyết
Nhóm 2 — Quyền và dấu vết
Nhóm 3 — Thương mại và nghiệm thu
Một tiêu chí nghiệm thu do chính bạn định nghĩa, đo trên dữ liệu của bạn, đáng giá hơn mọi con số phần trăm in trong tài liệu giới thiệu.
Phần 07
Lộ trình ba giai đoạn
Thứ tự này không phải để đi chậm, mà để mỗi giai đoạn có một cửa nghiệm thu cụ thể. Dự án hỏng thường không hỏng vì công nghệ — nó hỏng vì bật tự động trên nền dữ liệu chưa sạch, rồi mất niềm tin của chính người dùng nội bộ.
Giai đoạn 1 Chuẩn hoá
Dọn danh mục, thống nhất quy trình duyệt trên cấu hình chuẩn, chưa bật agent nào cả.
Cửa nghiệm thu: tỉ lệ bản ghi trùng và tỉ lệ trường bắt buộc bị bỏ trống giảm về ngưỡng do bạn đặt ra từ đầu.
Giai đoạn 2 Người vẫn duyệt
Agent chỉ đề xuất: soạn đơn mua nháp, gợi ý mức ưu tiên, tóm tắt hồ sơ. Người bấm nút cuối cùng vẫn là nhân sự nghiệp vụ.
Cửa nghiệm thu: theo dõi tỉ lệ đề xuất bị người sửa hoặc bác trong một số lượng ca đủ lớn — con số này chính là thước đo độ tin cậy.
Giai đoạn 3 Tự chạy có giới hạn
Chỉ mở tự động cho những quy trình đã qua giai đoạn 2 với kết quả ổn định, và mở từng quy trình một.
Cửa nghiệm thu: có ngưỡng giá trị bắt buộc chuyển người duyệt, có nút tắt khẩn, và có người được phân công đọc nhật ký hằng tuần.
Không có con số chuẩn cho “đủ tin cậy”. Ngưỡng phải do bạn đặt theo hậu quả của việc làm sai trong chính nghiệp vụ đó: sai một đề xuất chăm sóc khách hàng khác hẳn sai một lệnh khoá giao hàng. Nhà cung cấp không đặt hộ ngưỡng này được.
Phần 08
Chốt lại
Agentic ERP là hướng đi thật và đáng theo dõi. Nhưng giá trị của nó không đến từ việc mua đúng phần mềm — nó đến từ việc doanh nghiệp đã chuẩn hoá dữ liệu và quy trình tới đâu trước khi bật. Phần công nghệ là phần dễ. Phần khó vẫn nằm ở chỗ cũ.
Chương trình AI Enablement cho doanh nghiệp trong danh mục
Nếu doanh nghiệp của bạn đang cân nhắc một dự án dạng này, phần chuẩn bị năng lực nội bộ nên đi trước phần chọn nhà cung cấp. Chương trình đào tạo của ABBMB đi vào đúng phần đó.
Xem chương trình learn.abbmb.com/ai-enablement
Phần 09
Nguồn và ghi chú phương pháp
Ghi chú này do ABBMB tổng hợp ngày 05/09/2026 từ tài liệu công khai. Nội dung kỹ thuật mô tả nền tảng Odoo phiên bản 19 — nền tảng khác có mô hình phân quyền khác, đừng suy rộng. Chúng tôi không có quan hệ đại lý hay hoa hồng với bất kỳ nhà cung cấp ERP nào.
| Nguồn | Dùng cho phần nào | Cần lưu ý |
|---|---|---|
| Tài liệu chính thức Odoo 19 — AI agents odoo.com/documentation/19.0/applications/productivity/ai/agents.html | Phần 02: tên và vai trò của bốn nhóm cấu hình (system prompt, topics và tools, sources, automation rules). | ✓ |
| Phân tích độc lập về AI trong Odoo, 07/2026 usecarly.com/blog/odoo-ai | Phần 04 mục 3.3 và phần 05: trợ lý mặc định chỉ đọc; khả năng ghi đến từ công cụ; khoá API tuỳ mô hình vận hành. | ~ |
| Bài về quản trị và nhật ký AI trong Odoo heypinchy.com/odoo-ai-governance | Phần 04 mục 3.1 và 3.4: không có phân quyền riêng theo agent; thiếu nhật ký ở tầng suy luận. | ! |
| Mô hình bảo mật của Odoo — quyền truy cập và luật bản ghi | Phần 04 mục 3.2: quyền cộng dồn; không có luật nào áp thì thao tác được cho qua. | ✓ |
Trang này là ghi chú định hướng cho ban lãnh đạo, không phải tư vấn kỹ thuật hay tư vấn đầu tư. Trước mỗi quyết định ngân sách, hãy kiểm chứng lại từng điểm trên chính hệ thống và hợp đồng của doanh nghiệp mình.