AI Agent cảnh báo tồn kho thấp và đề xuất nhập hàng có đáng tin không?

Nhiều doanh nghiệp chỉ phát hiện hàng sắp hết khi khách đã đặt mà kho không còn để giao. Ngược lại, có mã hàng được nhập thêm chỉ vì báo cáo ghi tồn thấp, trong khi một lô khác đang trên đường về. Cả hai tình huống đều bắt nguồn từ việc con số tồn kho được nhìn riêng lẻ, không đặt cạnh đơn đang về, tốc độ bán và thời gian nhà cung cấp cần để giao.

AI cảnh báo tồn kho hứa hẹn gom những dữ liệu đó lại, báo sớm mã nào sắp thiếu và gợi ý nên nhập bao nhiêu. Câu hỏi là đề xuất ấy đáng tin tới đâu. Câu trả lời ngắn: đáng tin ở mức dữ liệu đầu vào cho phép, và chỉ khi mọi giả định đều hiện ra để người mua hàng kiểm tra.

Bài viết đi qua các dữ liệu cần có, cách thiết kế cảnh báo và đề xuất, quy trình triển khai, các rủi ro thường gặp và cách chia việc giữa kho, mua hàng và kỹ thuật.

1. Bản chất của AI cảnh báo tồn kho

Phần tính toán cốt lõi của cảnh báo tồn kho không cần AI. Điểm đặt hàng lại, mức tồn an toàn hay số ngày còn đủ bán đều là công thức có thể kiểm tra bằng tay. AI có ích ở những phần xung quanh: đọc dữ liệu từ nhiều nguồn có cách ghi khác nhau, nhận ra mã hàng có nhu cầu bất thường, giải thích bằng lời vì sao một mã bị cảnh báo và trả lời câu hỏi của quản lý như “mã nào sẽ thiếu trong đợt khuyến mãi tới”. Con số nên do công thức tính; AI trình bày, đối chiếu và gợi ý.

Áp ba mức việc vào tồn kho sẽ thấy rõ ranh giới. Mức hỏi đáp là giải thích chính sách tồn an toàn hay cách tính điểm đặt hàng. Mức tra cứu thời gian thực là đọc tồn khả dụng, đơn đang về và lịch giao từ phần mềm kho hoặc ERP; dữ liệu này phải lấy thẳng từ nguồn, không dùng bản xuất file từ hôm trước (xem thêm AI Agent và dữ liệu thời gian thực). Mức ghi là tạo đề xuất mua hoặc phiếu yêu cầu; ở giai đoạn đầu, AI chỉ nên tạo bản nháp để người mua hàng duyệt.

2. Các yếu tố cần thiết kế

1. Tồn kho khả dụng

Tồn khả dụng không phải con số hàng đang nằm trên kệ. Nó phải trừ hàng đã giữ cho đơn chưa xuất, hàng lỗi chờ xử lý và hàng đang kiểm kê. Nếu hệ thống lấy nhầm tồn vật lý, cảnh báo sẽ đến muộn đúng lúc bận nhất. Cần thống nhất công thức với thủ kho và ghi thời điểm cập nhật số liệu trên từng cảnh báo.

2. Đơn đang về

Đơn mua đã đặt nhưng chưa nhập kho là lý do phổ biến nhất khiến đề xuất nhập hàng bị trùng. AI cần đọc được số lượng còn chờ giao, ngày dự kiến về và trạng thái xác nhận của nhà cung cấp. Đơn chưa được xác nhận nên tính riêng, không cộng thẳng vào lượng hàng chắc chắn sẽ có.

3. Tốc độ bán

Tốc độ bán nên tính trên một khoảng thời gian thống nhất và loại bỏ những ngày bất thường như một đơn sỉ lớn hay giai đoạn hết hàng. Khi một mã hết hàng nhiều ngày, doanh số thấp của giai đoạn đó không phản ánh nhu cầu thật. Mỗi cảnh báo nên ghi rõ tốc độ bán dùng để tính lấy từ giai đoạn nào.

4. Thời gian cung ứng

Thời gian cung ứng là khoảng từ lúc quyết định đặt đến lúc hàng sẵn sàng bán, gồm cả thời gian duyệt nội bộ, vận chuyển và kiểm hàng. Sai lầm thường gặp là dùng con số nhà cung cấp cam kết thay vì thời gian thực tế của các lần trước. Nếu một nhà cung cấp hay giao trễ, hệ thống nên dựa vào lịch sử và cho người mua hàng chỉnh tay.

5. Mức tồn an toàn

Mức tồn an toàn là phần đệm cho những biến động không lường trước. Nó nên được đặt theo nhóm hàng và do người phụ trách mua hàng hoặc kế hoạch phê duyệt, không để AI tự nâng hạ. Khi thấy mức hiện tại có vẻ thấp so với biến động gần đây, AI chỉ đề xuất điều chỉnh kèm lý do.

6. Mùa vụ và khuyến mãi

Lịch sử bán hàng không biết tháng sau có chương trình khuyến mãi hay mùa cao điểm. Thông tin này thường nằm trong kế hoạch của marketing hoặc kinh doanh, nên cần một nguồn chính thức để hệ thống đọc. Với những mã chịu ảnh hưởng mạnh, cảnh báo nên gắn cờ để người phụ trách xem lại trước khi dùng đề xuất.

7. Đề xuất số lượng

Số lượng đề xuất tính theo công thức mà bộ phận mua hàng đã đồng ý, rồi làm tròn theo quy cách đóng gói và số lượng đặt tối thiểu của nhà cung cấp. Mỗi đề xuất hiển thị các thành phần tạo ra con số: tồn khả dụng, hàng đang về, nhu cầu dự kiến trong thời gian cung ứng và mức tồn an toàn. Người duyệt nhìn vào là biết đề xuất dựa trên giả định nào.

8. Phê duyệt mua hàng

Đề xuất nhập hàng chỉ là đầu vào cho quyết định mua. Nên đặt hạn mức theo giá trị và nhóm hàng: trong hạn mức thì người mua hàng duyệt, vượt thì chuyển quản lý. AI không tự gửi đơn cho nhà cung cấp. Bước biến đề xuất thành phiếu yêu cầu mua được trình bày trong bài AI tạo yêu cầu mua hàng.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chọn một nhóm hàng có dữ liệu tương đối sạch và thường xuyên gặp tình trạng thiếu hoặc thừa. Ghi rõ điều muốn cải thiện: số lần hết hàng, lượng tồn chậm luân chuyển hay thời gian người mua hàng rà báo cáo mỗi tuần. Trưởng bộ phận mua hàng và thủ kho cùng chốt phạm vi này.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Đối chiếu mã hàng giữa phần mềm kho, ERP và bảng theo dõi đơn mua; một mặt hàng mang hai mã là nguồn lỗi kinh điển. Đầu ra là bảng ánh xạ mã hàng, danh sách trường dữ liệu dùng để tính và quyền đọc của agent với từng hệ thống. Agent chỉ cần quyền đọc tồn và đơn mua, không cần quyền sửa số liệu kho.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Xác định agent làm gì khi thiếu dữ liệu: mã hàng mới chưa có lịch sử bán, nhà cung cấp chưa có thời gian giao, hay đồng bộ tồn bị trễ. Thay vì đoán, cảnh báo ghi “chưa đủ dữ liệu” và chuyển người phụ trách. Luồng duyệt, hạn mức và người nhận thông báo được viết thành tài liệu để bên kỹ thuật cấu hình.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Chạy song song một thời gian: agent đưa cảnh báo, người mua hàng vẫn làm như cũ và ghi lại đề xuất nào họ dùng, sửa hay bỏ. Log của giai đoạn này cho biết cảnh báo nào bị bỏ qua vì sai và sai ở đâu. Chỉ khi tỷ lệ đề xuất phải sửa đạt tiêu chí đã chốt mới mở rộng sang nhóm hàng khác.

4. Ví dụ giả định

Một SKU xuống dưới mức an toàn nhưng đơn nhập đã sắp về. AI kết hợp tồn khả dụng, lịch giao và nhu cầu dự kiến nên chỉ cảnh báo theo dõi, không đề xuất mua thêm. Quản lý xem giả định trước khi duyệt.

Từ tình huống này có thể dựng ít nhất bốn ca thử: đơn đang về đúng hạn, đơn đang về bị nhà cung cấp báo trễ, đơn đang về chưa được xác nhận và không có đơn nào đang về. Kết quả mong đợi lần lượt là theo dõi, đề xuất mua bổ sung, cảnh báo cần xác nhận và đề xuất mua. Nếu agent đề xuất mua ngay ở ca đầu tiên, cần xem lỗi nằm ở dữ liệu đơn mua, ở ngày dự kiến về hay ở công thức.

5. Rủi ro và giới hạn

• Dữ liệu tồn chậm làm sai cảnh báo
• Không dùng dự báo như cam kết
• Ngoại lệ mùa vụ cần người kiểm tra
• Không tự đặt hàng nếu chưa có hạn mức

Rủi ro lớn nhất không nằm ở mô hình mà ở độ trễ và độ sạch của dữ liệu tồn. Một lần đồng bộ lỗi có thể khiến hàng loạt mã bị cảnh báo sai, vì vậy cảnh báo nên hiển thị thời điểm dữ liệu và tự tạm dừng khi nguồn không cập nhật. Dự báo nhu cầu luôn có sai số; nó giúp ưu tiên việc cần xem, không phải lời hứa với nhà cung cấp hay khách hàng. Quyền tạo đơn mua thật chỉ nên mở khi đã có hạn mức, người duyệt và mã chống tạo trùng.

6. Phân chia trách nhiệm vận hành

Bộ phận mua hàng hoặc kế hoạch sở hữu công thức, mức tồn an toàn và quyết định nhập hàng. Thủ kho chịu trách nhiệm để tồn khả dụng đúng, xử lý chênh lệch kiểm kê và báo khi có hàng lỗi hay hàng giữ chỗ. Kinh doanh hoặc marketing cập nhật lịch khuyến mãi và mùa vụ vào nguồn mà agent đọc. Đội kỹ thuật lo đồng bộ dữ liệu, cảnh báo khi đồng bộ lỗi và quyền truy cập của agent.

Mỗi lần đổi công thức, đổi mức tồn an toàn hoặc thêm nguồn dữ liệu, cần ghi phiên bản và chạy lại bộ ca thử tồn kho trước khi áp dụng. Khi cảnh báo sai hàng loạt, người phụ trách mua hàng có quyền tắt đề xuất tự động và quay về báo cáo thủ công cho tới khi tìm ra nguyên nhân.

7. Chỉ số nên theo dõi

• Tỷ lệ cảnh báo đúng theo tiêu chí đã duyệt
• Tỷ lệ chuyển người phụ trách khi thiếu dữ liệu
• Lỗi đồng bộ tồn, độ trễ và số đề xuất phải sửa
• Chi phí cùng tác động tới hết hàng và tồn chậm

Số cảnh báo gửi đi nhiều hay ít không nói lên điều gì. Nên đo số lần hết hàng ở nhóm hàng thí điểm, số đề xuất bị người mua hàng sửa hoặc bỏ, và số cảnh báo đến khi hàng đã hết. Tách theo nhóm hàng và nhà cung cấp để biết cần sửa dữ liệu, công thức hay thời gian cung ứng.

8. Checklist trước khi vận hành

• Nguồn dữ liệu tồn kho và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có thể dùng AI cảnh báo tồn kho ngay không? Có thể khi tồn khả dụng và đơn mua đang về đọc được trực tiếp từ hệ thống nguồn, và mã hàng đã thống nhất giữa kho với mua hàng. Nếu số tồn vẫn cập nhật bằng file thủ công, nên chuẩn hóa phần đó trước, vì cảnh báo không thể đúng hơn dữ liệu nó đọc.

Nên bắt đầu cảnh báo tồn kho từ nhóm hàng nào? Chọn nhóm hàng bán đều, hay bị thiếu và có nhà cung cấp giao tương đối ổn định. Hàng mới chưa có lịch sử bán hoặc hàng phụ thuộc mạnh vào mùa vụ nên để sau, khi công thức đã được kiểm chứng trên nhóm đầu tiên.

Khi nào đề xuất nhập hàng cần người duyệt? Mọi đề xuất trở thành đơn mua đều cần người duyệt, nhất là khi vượt hạn mức, mã hàng chịu ảnh hưởng khuyến mãi hoặc đơn đang về chưa được nhà cung cấp xác nhận. AI chỉ chuẩn bị đề xuất và nêu rõ giả định.

AI có thay được người lập kế hoạch mua hàng không? Không. AI giúp rà nhanh và báo sớm, còn quyết định số lượng, nhà cung cấp và thời điểm đặt vẫn thuộc người lập kế hoạch, vì họ nắm những thông tin mà dữ liệu chưa ghi lại như thỏa thuận với nhà cung cấp hay thay đổi sắp tới của thị trường.

Kết luận

Đề xuất nhập hàng của AI đáng tin khi mỗi con số truy ngược được về tồn khả dụng, hàng đang về, tốc độ bán và thời gian cung ứng. Hãy bắt đầu bằng một nhóm hàng, chạy song song với cách làm hiện tại và chỉ giao thêm quyền khi đề xuất ít phải sửa.

Trao đổi với Naventic để khảo sát dữ liệu tồn kho và thiết kế cảnh báo phù hợp. Đọc thêm: AI Data Analyst Agent.