Kiến trúc tham khảo cho bài toán phổ biến: ERP đang chạy tốt cho vận hành nội bộ nhưng không được thiết kế để kết nối với sàn thương mại điện tử, và nhân viên đang phải nhập tay đơn hàng giữa các hệ thống.
Đây là kiến trúc tham khảo, không phải hồ sơ khách hàng. Trang này không chứa tên khách hàng hay số liệu của dự án cụ thể nào.
Bài toán
Doanh nghiệp có ERP triển khai từ nhiều năm trước, chạy ổn định cho kho, kế toán và sản xuất. Nay bán thêm trên hai ba sàn thương mại điện tử, website riêng và hệ thống cửa hàng.
Hiện trạng: mỗi sáng nhân viên tải đơn từ từng sàn về, nhập tay vào ERP. Tồn kho cập nhật một lần mỗi ngày, dẫn tới bán vượt hàng thực có. Khi khách hỏi đơn đến đâu, phải mở ba hệ thống để tra.
Thay ERP không phải phương án — nó đang chạy tốt phần việc của nó, và chi phí thay thế quá lớn so với vấn đề cần giải quyết.
Kiến trúc đề xuất: lớp trung gian
Không sửa ERP, không sửa sàn. Dựng một lớp trung gian đứng giữa, chịu trách nhiệm dịch dữ liệu qua lại và giữ trạng thái đồng bộ.
Vì sao chọn lớp trung gian
- ERP giữ nguyên, không phát sinh rủi ro cho hệ thống đang vận hành
- Thêm sàn mới chỉ cần viết thêm một bộ kết nối, không đụng phần còn lại
- Khi sàn đổi API, chỉ sửa bộ kết nối tương ứng
- Có một chỗ duy nhất để xem nhật ký khi cần truy vết sai lệch
Xác định nguồn sự thật cho từng loại dữ liệu
Đây là quyết định quan trọng nhất của cả dự án. Phải chốt trước khi viết dòng mã đầu tiên.
| Dữ liệu | Nguồn sự thật | Chiều đồng bộ |
|---|---|---|
| Danh mục sản phẩm, giá | ERP | ERP đẩy ra các kênh |
| Tồn kho khả dụng | ERP | ERP đẩy ra, tần suất cao |
| Đơn hàng mới | Kênh bán | Kênh đẩy về ERP |
| Trạng thái giao hàng | ERP | ERP đẩy ngược ra kênh |
| Thông tin khách hàng | Tùy chính sách | Cần quyết định rõ, đây là chỗ hay tranh cãi |
Xử lý bài toán tồn kho — phần khó nhất
Nếu chia cứng tồn kho cho từng kênh thì lãng phí: kênh A hết hàng trong khi kênh B còn tồn không bán được. Nếu để tất cả các kênh cùng thấy toàn bộ tồn kho thì sẽ bán vượt.
Cách xử lý cân bằng: giữ một phần tồn làm đệm an toàn không hiển thị ra kênh nào, phần còn lại chia sẻ chung. Khi có đơn, trừ tồn ngay tại lớp trung gian trước khi ERP kịp cập nhật, để tránh hai kênh cùng bán một món trong khoảng thời gian giữa hai lần đồng bộ.
Tần suất đẩy tồn kho nên cao hơn nhiều so với các dữ liệu khác — vài phút một lần thay vì vài giờ.
Điểm dễ vỡ
| Tình huống | Cách xử lý |
|---|---|
| Sàn giới hạn số lần gọi API | Xếp hàng và điều tiết tốc độ gọi; ưu tiên tồn kho hơn các dữ liệu khác |
| ERP bảo trì, tạm ngừng | Lớp trung gian giữ đơn trong hàng đợi, đẩy lại khi ERP trở lại |
| Đơn bị đẩy hai lần | Mỗi đơn có khoá định danh duy nhất, ERP từ chối bản trùng |
| Sàn đổi API không báo trước | Kiểm tra tự động hàng ngày, cảnh báo ngay khi cấu trúc thay đổi |
| Sai lệch tích lũy theo thời gian | Đối soát toàn bộ mỗi đêm, xuất báo cáo chênh lệch cho người phụ trách |
Luôn giữ đường thủ công
Dù tự động hoá tốt đến đâu, phải luôn có màn hình cho phép người vận hành xem đơn đang kẹt ở đâu và đẩy lại bằng tay. Ngày nào đó sàn sẽ trả về dữ liệu không đúng định dạng dự kiến, và bạn cần xử lý được mà không phải gọi lập trình viên.
Lộ trình
- Một chiều trước. Đẩy đơn từ một sàn về ERP. Chạy song song với nhập tay hai tuần, đối chiếu từng đơn.
- Thêm đồng bộ tồn kho. Bắt đầu với tần suất thấp và đệm an toàn lớn, siết dần khi đã tin tưởng.
- Mở rộng ra các kênh còn lại. Mỗi kênh một bộ kết nối, thêm dần.
- Đẩy ngược trạng thái giao hàng. Giảm tải cho bộ phận chăm sóc khách hàng.
- Bảng theo dõi và đối soát tự động. Để vận hành không cần kỹ thuật can thiệp hàng ngày.
Bạn cần chuẩn bị gì
- Tài liệu API của ERP, hoặc quyền truy cập cơ sở dữ liệu nếu không có API
- Tài khoản người bán trên các sàn, có quyền tạo khoá API
- Danh sách mã sản phẩm đối chiếu giữa ERP và từng sàn — thường đây là phần lộn xộn nhất
- Quyết định về chính sách đệm tồn kho: chấp nhận rủi ro bán vượt bao nhiêu
Bài viết được biên soạn từ kinh nghiệm triển khai hạ tầng và phần mềm của đội ngũ. Không nhận tài trợ, không quảng cáo sản phẩm.