Công ty vận tải container giảm 70% chuyến trễ cut-off và tiết kiệm 950 triệu đồng phí lưu container

Mỗi booking có nhiều mốc thời gian và chỉ một thay đổi nhỏ cũng có thể gây rớt tàu. Doanh nghiệp đã dùng ERP để quản lý booking, container, chặng xe và các đồng hồ hạn trên cùng một nguồn dữ liệu.

1. Bối cảnh: mỗi chuyến có nhiều đồng hồ đếm ngược

Tân Cảng Road là tên thay thế của doanh nghiệp vận tải container phục vụ các tuyến cảng, depot và nhà máy khu vực phía Nam. Công ty điều phối khoảng 3.600 lượt lấy, hạ và trả container mỗi tháng. Mỗi booking có lịch tàu, giờ hẹn, cut-off, thời gian miễn phí và yêu cầu chứng từ khác nhau. Chỉ một mốc bị bỏ lỡ có thể tạo phí chờ, lưu container hoặc rớt tàu.

Thông tin đến từ nhiều nguồn: thư của khách hàng, cổng hãng tàu, tin nhắn depot, lịch nhà máy và bảng điều vận. Nhân viên giàu kinh nghiệm ghi chú bằng màu và nhắc nhau qua nhóm. Khi sản lượng tăng 32%, số mốc phải theo dõi vượt khả năng trí nhớ. Doanh nghiệp bắt đầu trả nhiều phí mà không xác định rõ lỗi thuộc khách hàng, depot, tài xế hay điều vận.

Trong ba tháng, 9,8% chuyến hạ cảng sau cut-off hoặc phải xin gia hạn; phí lưu container và detention đạt 1,46 tỷ đồng; thời gian chờ bình quân 3,1 giờ. Chỉ 42% cảnh báo được xử lý trước hạn vì chúng nằm ở nhiều bảng. Có chuyến phát sinh phí nhưng thiếu ảnh và thời gian nên không thể thu lại khách hàng.

Một lô 28 container xuất khẩu là sự cố điển hình. Nhà máy đóng hàng chậm, lịch tàu đổi và depot thay điểm trả rỗng. Sáu container rớt chuyến, mười một container vượt thời gian miễn phí. Tổng phí và điều xe lại 386 triệu đồng. Từng thay đổi đã được một người biết, nhưng không có một bản ghi tổng hợp tác động đến toàn bộ lô.

2. Gốc rễ: quản lý trạng thái nhưng thiếu quản lý thời hạn

Bảng điều vận cho biết xe đang ở đâu nhưng không tính thời gian còn lại đến cut-off, free time hay trả rỗng. Mốc được nhập dưới dạng ghi chú, không có múi giờ, nguồn thay đổi và người chịu trách nhiệm. Khi lịch tàu đổi, nhân viên sửa một bảng nhưng các lệnh liên quan không tự cập nhật.

Booking, container và chuyến xe chưa có quan hệ rõ. Một booking có nhiều container, một xe có thể thực hiện nhiều chặng, một container có các mốc lấy rỗng, đóng, hạ và trả. Dữ liệu phẳng khiến việc theo dõi lô lớn khó khăn và cảnh báo không biết gửi cho ai.

Thời gian chờ được ghi sau chuyến, chủ yếu để thanh toán tài xế. Không có mốc đến, bắt đầu phục vụ và rời điểm đủ tin cậy nên doanh nghiệp khó phân biệt chờ do đến sớm, nhà máy chưa sẵn sàng hay tài xế xử lý chậm. Vì thiếu bằng chứng, phụ phí chờ chỉ thu được ở một phần nhỏ trường hợp.

Cảnh báo cũng chưa có cấp độ. Một booking còn hai ngày và một booking còn hai giờ xuất hiện giống nhau. Nhân viên nhận quá nhiều nhắc nhở nên bỏ qua. Hệ thống cần tính tác động theo số container, giá trị phí và nguy cơ rớt tàu để ưu tiên.

3. Giải pháp: mô hình hóa booking, container, chặng và đồng hồ hạn

ERP quản lý booking ở cấp lô, container ở cấp tài sản tạm thời và chuyến ở cấp thực hiện. Mỗi container mang số, loại, hãng tàu, depot, ngày lấy, cut-off, free time, ngày hạ và ngày trả rỗng. Các chặng được nối với lệnh xe và tài xế, giúp nhìn trạng thái chi tiết lẫn tiến độ toàn lô.

Mốc thời gian có nguồn và phiên bản. Khi khách hàng hoặc hãng tàu đổi lịch, hệ thống lưu mốc cũ, mốc mới, người cập nhật và các chuyến bị ảnh hưởng. Cảnh báo được tính lại tự động. Điều vận thấy danh sách theo số giờ còn lại, tác động và hành động cần thực hiện.

Tài xế xác nhận đến, bắt đầu phục vụ và rời bằng định vị cùng ảnh. Thời gian chờ được tính theo điều khoản khách hàng. Khi vượt miễn phí, ERP tạo đề nghị phụ phí kèm bằng chứng. Nếu nguyên nhân nội bộ, chi phí được gắn vào chuyến để phân tích thay vì cố thu khách hàng.

Dashboard có ba lớp: điều vận nhìn mốc trong 24 giờ; chăm sóc khách hàng nhìn booking có nguy cơ và yêu cầu xác nhận; quản lý nhìn phí, nguyên nhân và khách hàng lặp lại. Cảnh báo quá hạn được nâng cấp nhưng không gửi đồng loạt cho mọi người.

4. Triển khai bảy tháng và va vấp thực tế

Giai đoạn đầu chọn hai khách hàng xuất khẩu có lịch ổn định và một khách hàng nhiều thay đổi. Nhóm dự án chuẩn hóa mười hai trạng thái, tám loại mốc và sáu nguyên nhân chờ. Họ không cố tích hợp mọi cổng hãng tàu ngay; lịch được nhập có kiểm soát, sau đó mới tự động hóa nguồn có sản lượng lớn.

Va vấp đầu tiên là mốc từ khách hàng thường ở dạng văn bản. Biểu mẫu tiếp nhận booking buộc xác nhận ngày, giờ, múi giờ và nguồn. Thư gốc được đính kèm. Nhân viên không được chỉ sao chép nội dung vào ghi chú vì hệ thống không thể tính cảnh báo từ văn bản tự do.

Va vấp thứ hai là tài xế quên bấm trạng thái. Công ty dùng geofence gợi ý mốc khi xe đến điểm nhưng vẫn cần tài xế xác nhận lý do chờ. Thông báo được giới hạn, không yêu cầu thao tác khi xe đang chạy. Tỷ lệ chuyến có đủ ba mốc thời gian tăng từ 51% lên 94%.

Va vấp thứ ba là lịch hãng tàu thay đổi liên tục. Đội chăm sóc khách hàng trở thành chủ sở hữu mốc thương mại, điều vận sở hữu mốc thực hiện. Khi thay đổi ảnh hưởng nhiều container, hệ thống tạo một hành động theo lô thay vì hàng chục tin nhắn riêng.

Va vấp thứ tư là tranh luận trách nhiệm phí. Công ty xây ma trận nguyên nhân và bằng chứng: khách hàng chưa sẵn sàng, depot ùn tắc, hãng tàu đổi lịch, xe đến muộn hoặc chứng từ thiếu. Chỉ khoản có căn cứ mới đưa vào đề nghị thu; khoản nội bộ trở thành dữ liệu cải tiến.

Sau ba tháng, cảnh báo được tinh chỉnh theo tuyến và khách. Depot có thời gian chờ thường xuyên được đặt ngưỡng sớm hơn. Khách có quy trình xác nhận phụ phí dài được cảnh báo trước để thu đủ bằng chứng. Hệ thống trở nên phù hợp thực tế thay vì dùng một ngưỡng cho mọi chuyến.

5. Kết quả: ít rớt tàu và kiểm soát phí tốt hơn

Sau bảy tháng, tỷ lệ chuyến trễ cut-off giảm từ 9,8% xuống 2,9%, tương đương giảm 70%. Phí lưu container và detention giảm từ 1,46 tỷ xuống 510 triệu đồng trong kỳ so sánh. Thời gian chờ bình quân giảm từ 3,1 xuống 1,7 giờ.

Tỷ lệ cảnh báo được xử lý trước hạn tăng từ 42% lên 91%. Doanh thu phụ phí chờ có đủ bằng chứng tăng 2,3 lần dù tổng thời gian chờ giảm. Nhân viên điều vận xử lý nhiều hơn 24% sản lượng mà thời gian tổng hợp báo cáo cuối ngày giảm 61%.

Với lô xuất khẩu tương tự sự cố trước, lịch tàu thay đổi được cập nhật ở cấp booking và tự tính lại 32 container. Bốn chuyến có nguy cơ được ưu tiên, khách hàng xác nhận giờ đóng mới, xe được đổi lịch. Toàn bộ lô hạ trước cut-off và không phát sinh detention.

6. Bài học quản trị

Vận tải container là bài toán thời hạn nhiều hơn trạng thái. Biết xe đang ở depot chưa đủ; doanh nghiệp cần biết còn bao lâu đến cut-off, free time và mốc trả rỗng. Mọi mốc phải có nguồn, người sở hữu và lịch sử thay đổi.

Cần tách booking, container và chuyến. Nếu gộp vào một dòng, hệ thống không xử lý được lô nhiều container, chặng trung gian hoặc đổi xe. Mô hình đúng giúp cảnh báo chính xác và truy vết chi phí.

Geofence hỗ trợ nhưng không thay thế xác nhận nghiệp vụ. Định vị biết xe đến, không biết nhà máy chưa sẵn sàng hay tài xế đang làm thủ tục. Kết hợp dữ liệu máy và lý do người dùng mới đủ để phân tích.

Không phải phí nào cũng nên thu khách hàng. Ma trận nguyên nhân và bằng chứng giúp doanh nghiệp công bằng, đồng thời nhìn thấy lỗi nội bộ để cải thiện. Đây là nền tảng xây SLA minh bạch.

Kết luận

Phí lưu container, chờ và rớt tàu thường được coi là chi phí khó tránh. Case study cho thấy phần lớn tổn thất có thể giảm khi booking, container, chặng xe và thời hạn được quản lý trên cùng hệ thống. Cảnh báo sớm tạo thời gian để đổi lịch, phối hợp khách hàng hoặc ưu tiên nguồn lực.

ERP có giá trị khi biến hàng trăm đồng hồ đếm ngược thành hàng đợi hành động rõ ràng. Điều vận không phải nhớ mọi mốc; quản lý không phải chờ báo cáo cuối tháng; khách hàng nhận được bằng chứng và cảnh báo sớm hơn.

Phụ lục thực hành: lộ trình áp dụng trong chín mươi ngày

Ba mươi ngày đầu, lập danh mục mốc và nguồn: giờ hẹn, cut-off, free time, trả rỗng, lịch tàu và thời hạn chứng từ. Xác định ai được thay đổi mỗi mốc và bằng chứng nào cần lưu. Chọn ba khách hàng có quy trình khác nhau để kiểm tra mô hình.

Đo đường cơ sở gồm trễ cut-off, phí detention, thời gian chờ, tỷ lệ mốc đủ dữ liệu, cảnh báo xử lý đúng hạn, phụ phí có bằng chứng và số lần lịch thay đổi. Phân tích theo khách, depot, cảng và nguyên nhân, không chỉ tổng công ty.

Trong tháng thứ hai, triển khai cho một nhóm điều vận và hai mươi xe. Họp mười lăm phút đầu ca để xem mốc 24 giờ tới; cuối ca chỉ xem ngoại lệ chưa đóng. Không biến dashboard thành một báo cáo dài phải đọc lại.

Thiết kế cảnh báo ba cấp: nhắc người xử lý, cảnh báo quản lý và cảnh báo khẩn theo tác động. Mỗi cấp cần hành động cụ thể. Nếu cảnh báo chỉ nói sắp trễ nhưng không chỉ cách xử lý, người dùng sẽ nhanh chóng bỏ qua.

Màn hình tài xế phải dùng được bằng một tay và không yêu cầu thao tác khi đang chạy. Mốc nên được gợi ý bằng vị trí; ảnh và lý do chỉ thu khi xe dừng. An toàn luôn cao hơn nhu cầu cập nhật dữ liệu tức thời.

Khi tích hợp cổng hãng tàu, ưu tiên nguồn có sản lượng và độ ổn định cao. Dữ liệu tự động vẫn cần lưu thời điểm đồng bộ và cơ chế người dùng xác nhận thay đổi quan trọng. Không để tích hợp lỗi âm thầm thay mốc đã cam kết.

Sau thí điểm, đưa KPI phí và đúng hạn vào đánh giá theo nguyên nhân, không đổ toàn bộ cho điều vận. Chăm sóc khách hàng, chứng từ, tài xế và khách hàng đều có vai trò. Cơ chế công bằng giúp dữ liệu nguyên nhân đáng tin hơn.

Nền tảng này có thể mở rộng sang dự báo ùn tắc, xác suất trễ và tối ưu thứ tự xe bằng AI. Nhưng trước tiên doanh nghiệp cần ít nhất vài tháng dữ liệu mốc, tuyến và nguyên nhân sạch, nếu không mô hình chỉ tự động hóa những sai lệch cũ.

Bảng điều hành cần tách sự kiện đã xảy ra và rủi ro tương lai. Chuyến đã trễ dùng để phân tích nguyên nhân; chuyến có nguy cơ cần hành động ngay. Trộn hai nhóm khiến nhân viên dành thời gian giải thích quá khứ trong khi mốc sắp tới không được bảo vệ. Mỗi màn hình nên mặc định mở ở thời gian cần quyết định.

Khi khách hàng đổi lịch qua điện thoại, nhân viên vẫn phải cập nhật mốc và chọn nguồn xác nhận. Hệ thống có thể lưu ghi chú cuộc gọi, nhưng cần thư hoặc tin nhắn xác nhận cho thay đổi ảnh hưởng phí. Quy tắc này bảo vệ cả doanh nghiệp và khách hàng khi đối soát, đồng thời giảm tranh luận dựa trên trí nhớ.

Đội quản trị nên kiểm tra hằng tuần các cảnh báo không tạo hành động, cảnh báo xuất hiện quá muộn và cảnh báo giả. Mỗi loại được điều chỉnh nguyên nhân, ngưỡng hoặc đối tượng nhận. Chất lượng cảnh báo là một sản phẩm cần chăm sóc liên tục, không phải cấu hình một lần rồi giữ nguyên bất kể sản lượng và tuyến thay đổi.

Với lô nhiều container, ERP cần cho phép xử lý theo nhóm nhưng vẫn giữ ngoại lệ từng container. Một thay đổi lịch có thể cập nhật cả lô; một container hư hỏng hoặc thiếu chứng từ phải tách riêng. Cân bằng hai cấp giúp điều vận thao tác nhanh mà không mất khả năng truy vết và tính phí chính xác.