Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Logistics
Trong dự án Logistics, mỗi đơn hàng ‘mất dấu’ không chỉ là một con số, mà là cả một sự đứt gãy giữa dòng chảy dữ liệu và thực tế vận hành. Với tôi, nhiệm vụ của một BA lúc này không phải là ngồi chờ yêu cầu, mà là phải tự mình đi ‘giải mã’ những lời than phiền thành các Requirement ngầm, từ đó xây dựng cơ chế Tracking real-time để lấy lại quyền kiểm soát cho anh em Ops. Bài viết này sẽ chia sẻ với bạn hành trình tôi bóc tách những điểm gãy đó, cùng cách thiết lập hệ thống cảnh báo thông minh để giải quyết triệt để bài toán kinh điển này.
Tại sao đơn hàng có thể “biến mất” khỏi hệ thống?
Ngày ấy, cái thời mới vào làm một vài dự án Logistics, tôi còn nhớ có lần team vận hành hớt hải báo tình trạng khẩn: “Có đơn hàng đi từ sáng mà không biết nó đi đâu, tài xế không cập nhật, khách (là một doanh nghiệp trong Sài Gòn) gọi bảo chưa nhận được, CSKH cũng không rõ đơn ở đâu mà tra!”.
Tôi đây – một BA tưởng như đã quá quen với những tình huống “dở khóc dở cười” – vậy mà vẫn phải mất đúng 5 giây định thần.
Ủa,… chuyện gì đang xảy ra vậy? Hệ thống track and trace “GoForGPS” lỗi à? Hay là do hệ thống cập nhật chậm? Hoặc có khi nào là do chính tài xế quên thao tác? Tôi bắt đầu thấy tò mò. Nhưng đồng thời cũng hơi… đau đầu.
Requirement không chỉ mơ hồ, mà còn gián tiếp
Không ai nói rõ: “Chúng ta cần tracking GPS tài xế”. Không có một dòng brief nào được ghi vào tài liệu cả. Tất cả chỉ là những lời than phiền:
- “Khách cứ gọi hỏi đơn đến đâu rồi mà mình không biết trả lời thế nào.”
- “Phải gọi từng tài xế hỏi, cực quá.”
Và bạn biết gì không? Là một Business Analyst – chính xác hơn là IT BA kiêm Solution Consultant – tôi hiểu rằng công việc của mình là phải dịch những lời “thở dài” đó thành các requirement ngầm:
Người dùng nội bộ (CSKH, Điều phối) cần một cách để biết đơn hàng đang ở đâu theo thời gian thực, mà không cần phụ thuộc vào việc gọi điện cho tài xế.
=> Đó là điểm bắt đầu cho cả một hành trình phân tích, gỡ rối và đề xuất cải tiến đầy cảm xúc.
Hỏi + Lắng nghe + Vẽ lại bức tranh thực tế
Tôi bắt đầu gợi chuyện, cố gắng mở rộng vấn đề để tìm ra nguyên nhân gốc rễ:
- Với CSKH: “Em thường biết đơn hàng đang ở đâu bằng cách nào?”
- Với Điều phối viên: “Mỗi tài xế có check-in điểm giao/nhận không?”
- Với Dev: “App tài xế có đang gửi dữ liệu vị trí về server không? Bao lâu một lần?”
Sau một vòng dò hỏi, tôi phát hiện một vài điều thú vị và cũng đầy lo lắng:
- App tài xế không tự động bật GPS. Hoặc nếu có thì chỉ gửi khi có thao tác như nhấn nút “Đã giao hàng” hay “Bắt đầu giao”.
- Không có dashboard theo dõi vị trí các đơn hàng đang xử lý theo thời gian thực.
- Và điều nguy hiểm nhất đó là hệ thống cũng chẳng có cảnh báo nếu đơn hàng bị “mất hút” quá lâu.
Và đây mới là phần nguy hiểm nhất.
Giải pháp đề xuất: không phải một bước, mà là cả lộ trình
Sau khi gom hết thông tin, tôi đề xuất giải pháp theo ba giai đoạn:
- Ngắn hạn: Tích hợp GPS vào app tài xế và gửi dữ liệu định kỳ (mỗi 1-2 phút).
- Trung hạn: Tạo dashboard tracking hiển thị trạng thái và vị trí từng đơn hàng.
- Dài hạn: Cảnh báo khi trạng thái đơn không được cập nhật sau hơn 2 giờ kể từ khi tài xế nhận hàng.
Tôi đồng thời cập nhật lại business flow:
Khách tạo đơn → OMS tạo lệnh giao → Tài xế nhận đơn → Tracking bật → Trạng thái cập nhật định kỳ → Nếu trễ → cảnh báo → Giao hàng thành công → cập nhật POD (Proof of Delivery).
Và viết một functional requirement rõ ràng:
“Hệ thống phải tự động gửi cảnh báo đến điều phối viên nếu đơn hàng không được cập nhật trạng thái sau 2 giờ kể từ khi tài xế nhận hàng.”
Tôi còn vẽ một sơ đồ BPMN gửi cho Product Owner và Dev Lead để hình dung:
Bắt đầu → Tạo đơn hàng → Giao tài xế → Kích hoạt tracking → Giao hàng → Nếu quá thời gian → gửi cảnh báo → Cập nhật hoàn tất.
Nhưng đời không như mơ…
Tôi mang bản đề xuất đi trình bày với các bên. Product Owner thì ủng hộ, nhưng team Dev thì lo vấn đề tiêu tốn băng thông và pin điện thoại. Team vận hành thì sợ tài xế kêu ca vì bị “theo dõi”.
Thế là tôi lại bắt đầu… vòng tròn góp ý – cải tiến – thuyết phục. Tôi đề xuất bật tracking theo trạng thái đơn thay vì luôn bật. Ví dụ: chỉ gửi định kỳ khi trạng thái đơn là “Đang giao”. Đồng thời đề xuất tính năng tài xế có thể xem lại hành trình của mình như một quyền lợi, chứ không chỉ là sự giám sát.
Nói chuyện bằng dữ liệu, không chỉ bằng cảm tính
Tôi dùng chính số liệu support để thuyết phục team Dev và sếp:
- Tỷ lệ đơn trễ giao tăng 18% trong tháng không tracking.
- Số cuộc gọi từ CSKH về tình trạng đơn hàng tăng 24%.
- Thời gian trung bình xử lý một khiếu nại: 22 phút.
Và cuối cùng, sau gần 2 tuần lấy ý kiến – chỉnh sửa – test thử – rollout nhẹ nhàng, hệ thống tracking mới chính thức đi vào vận hành. Mọi người vui như Tết.
Cảm giác lúc đó? Nhẹ người.
Bài học kinh điển cho BA logistic
Tôi nhận ra rằng đôi khi hệ thống không “chết” vì bug, mà vì không ai hỏi đúng câu. Người vận hành thì nghĩ: “Ai cũng biết phải tracking tài xế mà”, còn Dev thì nghĩ: “Không có requirement thì làm làm gì?”. BA là người đứng giữa để nối hai thế giới đó lại, bằng ngôn ngữ dễ hiểu, bằng hình ảnh, bằng wireframe, bằng prototype, bằng empathy và đôi khi… cả chút hài hước.
Đừng bao giờ xem thường những lời than thở. Đó chính là mỏ vàng nếu bạn đủ tinh tế để lắng nghe và biến chúng thành cơ hội cải tiến.
Một vài câu hỏi mẫu team tôi ghi lại sau case:
- Ai đang gặp vấn đề gì cụ thể?
- Hiện tại họ đang xử lý thế nào?
- Cách nào để đo lường vấn đề? Có dashboard? Có log không?
- Nếu được chọn, họ mong muốn hệ thống làm gì?
- Có tính năng nào có thể giảm workload cho user không?
“Kết lại” sau mỗi lần va vấp @@:
Sau case này, tôi nghiệm ra rằng làm BA không chỉ là người viết tài liệu BRD, SRS hay user story, mà còn là người gỡ rối cho hệ thống thông tin, chính là thứ đôi khi bị “mù mờ” bởi quá nhiều lớp vai trò và tiếng nói.
Đặc biệt trong logistics: nơi mỗi phút trễ có thể khiến đơn hàng đi sai, hàng bị huỷ, hoặc doanh nghiệp tổn thất tài chính thì việc có hệ thống rõ ràng, tracking hiệu quả và cảnh báo kịp thời là không thể thiếu.
Và các bạn, những người BA trẻ tuổi đang đọc bài này → nếu sau này gặp những tình huống kiểu như: “Không biết đơn đang ở đâu, hệ thống im re, khách thì la làng”… thì hãy nhớ: mọi rối rắm đều bắt đầu từ một điểm mơ hồ và BA là người phải “clear” nó.
Còn nếu bạn đang chán vì “cứ ngồi viết tài liệu”, thì hãy đứng dậy, đi gặp user, hỏi 3 câu hỏi, và bạn sẽ phát hiện ra một thế giới cực kỳ sống động đang chờ bạn phân tích – cải tiến – và đồng hành. Tin tôi đi, một người lâu năm cho hay =) !!!!
