Đồng bộ tồn kho đa kênh là việc để mọi kênh bán — cửa hàng, website, ứng dụng, sàn thương mại điện tử — cùng dựa trên một con số tồn kho khả dụng, được cập nhật đủ nhanh để không bán thứ không còn. Con số đưa ra cho khách không phải tồn kho trên sổ, mà là tồn sổ trừ hàng đã giữ cho đơn khác, trừ hàng hỏng chờ xử lý, trừ một lượng đệm để bù sai số.
Bán âm (overselling) — nhận đơn rồi phải huỷ vì hết hàng — là lỗi đắt nhất của bán hàng đa kênh. Nó làm mất khách, bị sàn phạt điểm uy tín, và làm nhân viên mất niềm tin vào hệ thống. Nguyên nhân hiếm khi nằm ở phần mềm đồng bộ chậm; phần lớn đến từ chính con số tồn kho ở cửa hàng vốn đã sai.
Bài này giải thích các khái niệm tồn kho cần phân biệt, kiến trúc đồng bộ, cách tính tồn đệm, cách đo và nâng độ chính xác tồn kho cửa hàng, và các quy tắc phân bổ tồn cho từng kênh.
Năm con số tồn kho cần tách bạch
Khi một quản lý hỏi “còn bao nhiêu”, câu trả lời đúng phụ thuộc vào việc hỏi con số nào. Hệ thống tồn kho đa kênh phải tách ít nhất các lớp sau:
| Khái niệm | Định nghĩa | Dùng vào việc gì |
|---|---|---|
| Tồn sổ (on hand) | Số lượng hệ thống ghi nhận đang nằm tại một điểm | Kế toán, kiểm kê, đối chiếu |
| Đã giữ (reserved/allocated) | Hàng đã gắn với đơn chưa xuất: đơn online chờ đóng gói, khách giữ hàng chờ đến lấy | Tránh bán cùng một món cho hai người |
| Không bán được (unavailable) | Hàng lỗi, hàng trưng bày mẫu, hàng chờ trả nhà cung cấp | Loại khỏi số hứa với khách |
| Đang về (in transit/on order) | Hàng đang điều chuyển hoặc đã đặt nhà cung cấp | Nhận đặt trước, hứa ngày giao muộn hơn |
| Khả dụng để hứa (available to promise) | Tồn sổ − đã giữ − không bán được − tồn đệm | Con số duy nhất hiển thị cho các kênh bán |
Nhiều hệ thống nhỏ chỉ có một cột “tồn”. Khi đó mỗi đơn online phải trừ ngay vào tồn sổ dù hàng vẫn nằm trên kệ, và cửa hàng không biết món nào trên kệ đã có người mua. Hệ quả quen thuộc: nhân viên bán món đó cho khách tại quầy, rồi đơn online bị huỷ.
Tách lớp “đã giữ” khỏi “tồn sổ” cũng giúp đối soát: tồn sổ chỉ giảm khi hàng thật sự rời điểm, khớp với chứng từ xuất, còn lớp giữ hàng phản ánh cam kết với khách.
Vì sao tồn kho cửa hàng thường sai và sai đến mức nào
Nghiên cứu được trích nhiều nhất về chủ đề này là của DeHoratius và Raman (Management Science, 2008). Phân tích dữ liệu kiểm đếm của một chuỗi bán lẻ lớn, họ thấy phần lớn bản ghi tồn kho ở cấp mặt hàng–cửa hàng không khớp với số đếm thực tế, và sai lệch có tính hệ thống chứ không chỉ ngẫu nhiên. Các nghiên cứu sau đó ở nhiều chuỗi khác cũng cho kết quả cùng chiều: sai lệch tồn kho cửa hàng là chuyện phổ biến, không phải ngoại lệ.
Nguồn sai lệch gồm: quét sai mã khi bán (quét một chai rồi bấm số lượng ba cho ba vị khác nhau), nhận hàng không kiểm (ký nhận theo phiếu giao thay vì đếm), hao hụt do mất cắp, hư hỏng, hết hạn mà không ghi, đổi trả nhập lại sai mã, và điều chuyển giữa cửa hàng ghi xuất mà bên kia chưa ghi nhập.
Một hiện tượng đặc biệt nguy hiểm là tồn ảo (phantom inventory): hệ thống ghi còn hàng nhưng kệ trống. Hệ thống bổ sung hàng tự động thấy “còn” nên không đặt thêm, kệ cứ trống mãi, doanh số mất mà không ai thấy. Với bán đa kênh, tồn ảo còn biến thành đơn online bị huỷ. Ngược lại, tồn ẩn — có hàng mà hệ thống ghi hết — làm mất doanh số online vì kênh số báo hết hàng.
Vì vậy, trước khi bàn đồng bộ nhanh hay chậm, chuỗi cần một câu trả lời trung thực: tồn kho cửa hàng của mình đúng đến đâu. Đồng bộ một con số sai thật nhanh chỉ làm lỗi lan nhanh hơn.
Kiến trúc đồng bộ: ba lựa chọn và đánh đổi
Đồng bộ định kỳ theo lô. Mỗi vài phút hoặc mỗi giờ, hệ thống tồn kho tính tồn khả dụng rồi đẩy lên các kênh. Đơn giản, ít tải, nhưng trong khoảng giữa hai lần đồng bộ, hai kênh có thể cùng bán món cuối cùng. Phù hợp khi lượng bán mỗi mặt hàng thấp và có tồn đệm.
Đồng bộ theo sự kiện. Mỗi giao dịch bán, giữ hàng, nhận hàng phát ra một sự kiện và hệ thống tồn kho cập nhật ngay, rồi đẩy thay đổi tới các kênh qua webhook hoặc hàng đợi tin nhắn. Gần thời gian thực, nhưng cần xử lý sự kiện đến trễ, trùng lặp, mất kết nối. Đây là hướng của đa số hệ thống hiện đại.
Giữ hàng tập trung khi đặt. Kênh bán không tự trừ tồn mà gọi về dịch vụ tồn kho trung tâm để xin giữ hàng trước khi xác nhận đơn. Chính xác nhất, chống bán âm triệt để cho kênh online, nhưng phụ thuộc kết nối và độ sẵn sàng của dịch vụ trung tâm. Cửa hàng mất mạng vẫn phải bán được, nên POS thường không áp dụng cơ chế này cho bán tại quầy.
Kết hợp trong thực tế. Nhiều chuỗi dùng giữ hàng tập trung cho đơn online, đồng bộ sự kiện cho bán tại quầy, và đối chiếu định kỳ theo lô mỗi đêm để sửa sai lệch tích luỹ. Đối với sàn thương mại điện tử, tần suất cập nhật còn bị giới hạn bởi giao diện lập trình của sàn, nên càng cần tồn đệm.
Tính tồn đệm: lượng hàng giữ lại để bù sai số
Tồn đệm (safety buffer) là số lượng không hiển thị cho kênh online dù hệ thống ghi còn. Nó bù cho ba thứ: độ trễ đồng bộ, sai lệch tồn kho cửa hàng, và tốc độ bán tại quầy trong khoảng chờ. Không có tồn đệm, món cuối cùng trên hệ thống thường là món đã mất hoặc đã nằm trong giỏ của khách tại quầy.
Một cách ước tính thực dụng cho mỗi nhóm hàng tại mỗi cửa hàng: tồn đệm ≈ tốc độ bán tại quầy mỗi giờ × độ trễ đồng bộ tính bằng giờ + sai lệch tồn kho điển hình. Ví dụ giả định: một mẫu giày bán trung bình 0,5 đôi mỗi giờ ở cửa hàng, độ trễ đồng bộ 15 phút, kiểm đếm cho thấy sai lệch điển hình một đôi. Tồn đệm ≈ 0,5 × 0,25 + 1 ≈ 1,1, làm tròn một đến hai đôi. Cửa hàng còn ba đôi trên hệ thống thì website chỉ thấy một hoặc hai.
Đánh đổi rất rõ: tồn đệm càng lớn, càng ít đơn bị huỷ nhưng càng nhiều lần website báo hết khi cửa hàng còn hàng. Với hàng giá trị cao, khách khó chịu khi bị huỷ, nên đệm lớn hơn. Với hàng thời trang theo cỡ, mỗi cửa hàng chỉ còn một hai món mỗi cỡ, nhiều chuỗi chọn không cho đặt online từ cửa hàng khi chỉ còn một món.
Tồn đệm nên được tính lại theo dữ liệu, không đặt một con số cố định cho mọi mặt hàng. Khi độ chính xác tồn kho cửa hàng tăng lên nhờ kiểm kê tốt hơn, đệm có thể giảm, và đó là cách đo lợi ích tài chính của việc kiểm kê.
Nâng độ chính xác tồn kho cửa hàng từng bước
Đây là phần việc ít hào nhoáng nhất nhưng quyết định thành bại. Một quy trình thường dùng:
- Đo hiện trạng bằng kiểm đếm mẫu ngẫu nhiên: chọn vài chục mặt hàng mỗi cửa hàng, đếm thật, so với hệ thống. Ghi tỷ lệ mặt hàng khớp chính xác và mức lệch trung bình.
- Chuyển từ kiểm kê toàn bộ cuối năm sang kiểm kê luân phiên (cycle counting): mỗi ngày đếm một phần nhỏ, ưu tiên hàng bán nhanh, giá trị cao và hàng hay lệch.
- Sửa quy trình nhận hàng: đếm khi nhận, ghi chênh lệch với phiếu giao ngay tại chỗ, không ký nhận theo phiếu.
- Khoá các thao tác dễ sai ở POS: hạn chế bấm số lượng nhiều cho hàng có biến thể, bắt buộc quét từng món khác mã.
- Ghi hao hụt có lý do: hàng hỏng, hết hạn, mất phải nhập với mã lý do, để phân tích được nguồn lệch.
- Điều chuyển hai chiều: phiếu điều chuyển chỉ hoàn tất khi bên nhận xác nhận, hàng đi đường nằm ở trạng thái riêng.
- Theo dõi chỉ số hằng tuần theo cửa hàng, gắn vào đánh giá quản lý cửa hàng, và giảm tồn đệm khi chỉ số tốt lên.
Công nghệ như nhãn RFID giúp đếm nhanh hơn nhiều với ngành thời trang, nhưng chỉ đáng đầu tư khi quy trình nền đã ổn; RFID không sửa được việc nhân viên nhập sai lý do hay nhận hàng không đếm.
Phân bổ tồn kho cho từng kênh
Khi tồn có hạn và nhiều kênh cùng muốn bán, chuỗi phải quyết định chia thế nào. Các quy tắc thường gặp, có thể kết hợp:
- Chia sẻ toàn bộ: mọi kênh thấy cùng một tồn khả dụng. Tối đa doanh số nhưng dễ bán âm khi kênh sàn cập nhật chậm.
- Hạn mức theo kênh: dành một phần tồn cho mỗi kênh, ví dụ sàn chỉ được bán tối đa một tỷ lệ nhất định. Giảm rủi ro ở kênh chậm, đổi lại có thể để hàng nằm chờ ở kênh không bán chạy.
- Ưu tiên theo biên lợi nhuận: khi tồn thấp, ẩn hàng khỏi kênh có phí hoa hồng cao hoặc chi phí giao lớn, giữ lại cho kênh có lãi hơn.
- Loại trừ cửa hàng khỏi nguồn online: cửa hàng có lượng khách tại quầy cao hoặc độ chính xác tồn thấp không được dùng làm điểm hoàn tất đơn online.
- Ngưỡng ngắt: khi tồn của một mặt hàng xuống dưới ngưỡng, tự động tắt bán trên kênh chậm nhất trước.
Quy tắc phân bổ nên do người phụ trách ngành hàng quyết, hệ thống thực thi; đừng để mỗi kênh tự đặt hạn mức. Ghi lại mọi lần huỷ đơn vì hết hàng kèm nguyên nhân để điều chỉnh quy tắc theo dữ liệu thật.
Câu hỏi thường gặp
Có nên dùng tồn kho của cửa hàng để bán online không, hay chỉ dùng kho tổng?
Dùng kho tổng đơn giản và chính xác hơn, nhưng bỏ phí lượng hàng lớn nằm ở cửa hàng và giao chậm hơn. Dùng tồn cửa hàng tăng độ phủ và tốc độ giao, đổi lại cần độ chính xác tồn kho cao và quy trình lấy hàng tại cửa hàng. Nhiều chuỗi bắt đầu bằng kho tổng, rồi mở dần cho các cửa hàng có độ chính xác tốt.
Đồng bộ mấy phút một lần là đủ?
Phụ thuộc tốc độ bán và lượng tồn mỗi mặt hàng. Hàng bán chậm, tồn nhiều thì đồng bộ mười lăm phút vẫn ổn. Hàng bán nhanh, tồn mỏng như hàng khuyến mãi giới hạn thì cần cơ chế giữ hàng tập trung. Đo tỷ lệ đơn huỷ vì hết hàng theo nhóm sản phẩm để biết chỗ nào cần nhanh hơn.
Khi ngày hội mua sắm trên sàn, nên xử lý tồn kho thế nào?
Nên tách hẳn một lượng hàng dành riêng cho chương trình, chuyển về kho phục vụ đơn sàn trước ngày diễn ra, tắt đồng bộ tự động với tồn cửa hàng cho các mã đó và tăng tồn đệm. Lượng đơn tăng đột biến làm giao diện lập trình của sàn và hệ thống của bạn chậm lại, nên dựa vào đồng bộ nhanh lúc đó rất rủi ro.
Mã vạch có đủ không hay phải dùng RFID?
Với đa số ngành hàng, mã vạch cùng quy trình quét chặt chẽ là đủ. RFID có lợi rõ ở ngành thời trang, nhiều biến thể, kiểm kê thường xuyên, vì đếm cả kệ trong vài phút. Cần tính chi phí nhãn trên mỗi món, thiết bị đọc và việc gắn nhãn tại nguồn trước khi quyết định.
Làm sao biết tồn ảo đang làm mất doanh số?
Dấu hiệu thường gặp là một mặt hàng có tồn trên hệ thống nhưng không bán được món nào tại một cửa hàng trong khoảng thời gian dài bất thường so với cửa hàng khác. Lập báo cáo những mặt hàng có tồn dương mà doanh số bằng không nhiều ngày liền, yêu cầu cửa hàng kiểm đếm, sẽ lộ ra phần lớn tồn ảo.
Đơn online đã giữ hàng nhưng khách không thanh toán thì xử lý sao?
Đặt thời hạn giữ hàng: đơn chưa thanh toán hoặc chưa xác nhận sau một khoảng thời gian thì tự động nhả hàng về tồn khả dụng. Thời hạn ngắn với thanh toán trực tuyến, dài hơn với đơn thanh toán khi nhận. Hệ thống cần ghi rõ lý do nhả để theo dõi tỷ lệ bỏ đơn.