Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Logistics
Tôi vẫn nhớ rõ buổi sáng thứ Hai, tháng 6/2023, trời mưa tầm tã, team vận hành gọi dồn dập trên Slack:
Andy ơi! Hệ thống lại đẩy đơn về nhầm kho rồi. Kho A thì nhận hàng của Kho B, mà bên A thì không có sản phẩm đó!
Lúc ấy tôi – một BA domain logistics mới nhận dự án được chính thức 3 tháng ở một công ty nước ngoài – ngồi lặng người trước màn hình, tự hỏi: “Đây là do bug, do logic sai hay do dữ liệu đầu vào?”

Bài viết dưới đây là hành trình tôi đi từ những lời than phiền cảm tính đến việc vạch trần lỗi mapping ‘chết người’ trong hệ thống. Qua đó, tôi sẽ chia sẻ cách thiết lập giải pháp từ ngắn đến dài hạn để diệt tận gốc bài toán giao nhầm kho kinh điển.
Mơ hồ – “Kẻ thù” số 1 của Business Analyst
Khi bắt tay vào phân tích nghiệp vụ, bạn sẽ thấy yêu cầu nghiệp vụ thường chia làm 2 loại:
- Một là cực kỳ cụ thể: “Tạo màn hình hiển thị trạng thái đơn hàng theo thời gian thực (real-time)”
- Hai là cực kỳ… mơ hồ: “Anh ơi, đơn cứ về sai kho ấy”.
Với người mới làm BA, kiểu yêu cầu số hai nghe có vẻ vô hại. Nhưng với tôi và có lẽ với bất kỳ BA logistics nào từng đi qua mùa mưa bug thì đây là tín hiệu đỏ rực.
Và…bạn không được dừng lại ở đó.
Hãy hỏi họ:
“Sai là sai như thế nào?”
Rồi thay vì hỏi 1 lần, tôi hỏi đến 5 lần, ở 5 thời điểm khác nhau, với 5 người khác nhau. Lý do? Vì mỗi người kể lại một version khác nhau!
Nghệ thuật khai quật thông tin mơ hồ
Để làm sáng tỏ vấn đề, hãy bắt đầu đưa ra loạt câu hỏi cụ thể hơn:
- “Kho nhận sai là nhận nhầm sản phẩm, hay nhầm cả vận đơn (tracking number)?”
- “Việc này xảy ra mọi đơn hay chỉ 1 số trường hợp cụ thể?”
- “Lúc lỗi xảy ra, trạng thái đơn là gì? Đã xác nhận? Đã xuất hàng?”
- “Có quy trình kiểm tra kho trước khi xuất hàng không? Ai xác nhận?”
- “Mình có dashboard nào đang log dữ liệu này không?”
Tuy nhiên, thứ tôi nhận về thường là những câu trả lời rời rạc, thiếu hệ thống, tựa như việc cố gắng lắp ráp một chiếc đồng hồ từ những linh kiện không khớp nhau. Thực tế, đặt câu hỏi đúng chỉ là bước đầu; kỹ năng then chốt nằm ở việc kết nối những mảnh vỡ đó thành một bản yêu cầu hoàn chỉnh. Đây cũng chính là thách thức lớn nhất trong cách xử lý requirement mơ hồ mà bất kỳ người làm sản phẩm nào cũng cần thành thạo để tránh lãng phí nguồn lực.
Nguyên nhân thực sự là gì?
Sau vài ngày đào bới, tôi phát hiện rằng lỗi không nằm ở hệ thống phân phối đơn, mà nằm ở việc mapping địa chỉ: kho (warehouse) sai. Cụ thể:
- Địa chỉ phường/xã trong hệ thống đặt hàng (OMS) không đồng bộ với địa chỉ vùng phục vụ trong hệ thống giao nhận (TMS).
- Hệ thống cũ từng hard-code mapping này, nhưng người viết đã nghỉ từ năm ngoái.
- QA thì test trên môi trường staging mà staging thì không có dữ liệu production thật để phát hiện bug.
Chuyện cười ra nước mắt là: Ops biết lỗi này từ tháng trước rồi, nhưng họ fix tay bằng cách chỉnh kho thủ công. Vì… tiện.
Không ai tạo bug report. Không ai coi đây là “vấn đề lớn”. Và rồi lỗi đó âm thầm phá vỡ toàn bộ luồng giao vận.
Những hậu quả khôn lường từ việc giao nhầm kho
Chuyện nhỏ nhưng hậu quả to:
- Trải nghiệm khách hàng: Hàng đến chậm, hoặc bị hủy. Niềm tin tụt dốc.
- Vận hành kho: Nhận SKU không đúng → xử lý thủ công → quá tải.
- CSKH: Nhận nhiều phản ánh → tăng chi phí nhân sự xử lý.
- Tài chính: Tăng chi phí hoàn đơn, chuyển lại, thất thoát doanh thu.
Cái “sai kho” không còn là lỗi vận hành nữa và nó là bài toán nghiệp vụ và hệ thống.
Giải pháp hệ thống hóa: Ngắn – Trung – Dài hạn
Là một BA, tôi không trực tiếp fix bug. Tôi đề xuất giải pháp chiến lược để “diệt tận gốc” vấn đề:
| Giai đoạn | Hành động cụ thể |
| Ngắn hạn | Mapping lại toàn bộ Master Data địa chỉ theo chuẩn (ViettelPost/Google Code). |
| Trung hạn | Thêm logic cảnh báo (Alert) khi địa chỉ đơn hàng không khớp vùng phục vụ của kho. |
| Dài hạn | Đồng bộ Master Data giữa OMS và TMS qua API; Xóa bỏ hoàn toàn hard-code cũ và thiết lập Version Control rõ ràng. |
Các bạn thấy cách tôi đề xuất ở trên không? Đây cũng là một trong những cách đề xuất mà các chuyên gia giải pháp, các IT BA lâu năm rất hay đưa ra. Đó là ngắn-trung-dài hạn cho một vấn đề; hay đối với một bug/issue thì nên giải quyết nhanh bằng cách đưa ra giải pháp tạm thời và sau đó là cách fix dài hạn… Hi vọng các bạn hiểu ý của tôi !!!
Tôi viết lại user story:
“Hệ thống phải hiển thị cảnh báo khi đơn hàng được gán đến kho không thuộc khu vực vận hành của địa chỉ giao hàng.”
Và cấu trúc lại Flow logic mới:
- Người dùng tạo đơn hàng.
- OMS ghi nhận thông tin đơn.
- Kiểm tra vùng phục vụ từ địa chỉ giao hàng.
- Nếu match → tự động gán kho.
- Nếu không match → cảnh báo cho Điều phối.
- Điều phối xác nhận lại hoặc chỉnh tay.
Gợi ý bài học cho các bạn BA mới vào nghề
- Đừng ngại hỏi lại. Nhiều khi stakeholder không biết cách mô tả lỗi.
- Luôn xác thực bằng dữ liệu. DB logs không biết nói dối.
- Đừng assume. “Tôi tưởng là…” là thứ nguy hiểm nhất trong nghề này.
- Thử đóng vai người dùng cuối. Có khi bạn sẽ hiểu họ đang chịu đau ở đâu.
Trải nghiệm thật – bài học thật
Câu chuyện này dạy tôi một điều:
Nhiều vấn đề lớn bắt đầu từ một logic nhỏ bị bỏ qua.
Nếu hôm đó tôi cũng chỉ nghe Ops nói “đơn sai kho” mà reply “check lại giúp anh nhé” thì có lẽ hệ thống tiếp tục sống chung với lỗi còn BA sống chung với… gánh nặng tội đồ không tên 🙂
Tóm tắt và đúc kết
- Là BA, đừng làm người ghi chép yêu cầu. Hãy là người làm sáng tỏ điều người ta chưa nói ra.
- Trong logistics, mỗi địa chỉ – mỗi kho – mỗi đơn hàng đều có thể là một biến số nguy hiểm nếu không được quản lý đúng cách.
- Và đôi khi, câu chuyện vận đơn không chỉ là tracking hàng hóa, mà là tracking những thứ mơ hồ nhất hay chính là tư duy người dùng và logic cũ.
Bonus: Những câu hỏi gợi ý bạn BA mới nên hỏi khi nghe “đơn giao sai kho”
- “Sai là sai như thế nào? Sai kho nào? Có ví dụ cụ thể?”
- “Tần suất xảy ra? Bao nhiêu đơn/tuần?”
- “Địa chỉ giao hàng có gì khác thường? Có bị thiếu thông tin không?”
- “Kho có logic mapping vùng phục vụ không?”
- “Có tool hay dashboard nào để kiểm tra không?”
Lại đúc kết lần cuối cho tình huống này nhé!!!
Làm BA không phải để viết tài liệu cho đẹp. Làm BA là người tháo gỡ sự mơ hồ, kết nối vận hành, kỹ thuật và khách hàng bằng cách nghĩ – hỏi – xác minh – đề xuất.
Và nếu bạn đang làm logistics, hãy nhớ:
Sai một địa chỉ, chệch cả một luồng đơn.
Hãy là người cuối cùng review điều đó.

Thảo luận
Đăng nhập để bình luậnAnh có thể đặt câu hỏi, góp ý hoặc lưu lại insight quan trọng sau khi đọc bài.