Triển khai hệ thống đặt lịch nhận hàng nhà máy: Cầu bốc dỡ và tích hợp ERP

Khi cân nhắc triển khai hệ thống đặt trước hàng đến cho nhà máy, chỉ so sánh giao diện đặt trước sẽ không thể đánh giá được hiệu quả vận hành. Đơn đặt hàng mua hàng (PO), dự kiến giao hàng của nhà cung ứng (ASN), thời điểm xe tải đến, phân bổ bến, tiếp nhận vật lý, phản ánh kết quả thực tế lên ERP – tất cả các bước này là các sự kiện tách biệt nhau. Bài viết này tổng hợp một cách thực tiễn mà có thể áp dụng cho nhà máy ở Thái Lan, làm rõ hệ thống nào xác nhận sự kiện nào, cách xử lý trễ, chênh lệch số lượng, và nhập hàng không có đặt trước. Đã tổng hợp dưới dạng có thể kiểm tra trước khi triển khai, từ các hạng mục nên ghi vào RFP cho đến các ví dụ thử nghiệm FAT và SAT.

Định nghĩa công việc mà hệ thống đặt trước nhập hàng nhà máy giải quyết

Điều mà hệ thống đặt trước xử lý đầu tiên không phải là chính hàng hóa, mà là “khi nào, phương tiện nào, sẽ mang hàng hóa nào, đến địa điểm tiếp nhận nào”. Quy trình tiếp nhận trong nhà máy, xe chờ, bốc dỡ, bố trí nhân sự, chuẩn bị kiểm tra được lên kế hoạch dựa trên cam kết này. Trong khi đó, bản gốc của đơn hàng là ERP; dữ liệu đã tiếp nhận (số lượng, lô, v.v.) sẽ được ghi nhận chính trong WMS hoặc ERP – đó là cách phân công trách nhiệm phổ biến. Việc đặt trước chỉ xác nhận khung thời gian, không được phép tự ý giảm số dư đơn đặt hay tồn kho.

Dock Appointment Scheduling của SAP được giải thích là chức năng lên lịch cho xe tải đến và bốc dỡ, đồng thời cho phép nhìn tổng thể khối lượng công việc tại bến theo từng ngày. Tài liệu quản lý kho của Oracle cũng chia nhỏ từng giai đoạn: đặt trước thời gian, xác nhận thời gian đến, check-in tại dock, tiếp nhận sử dụng ASN. Nếu ghi rõ những phân biệt này ở đầu RFP, sẽ tránh được thiết kế mà nhà cung cấp dịch vụ coi “đã đặt trước = đã tiếp nhận”.

Khi xác định đối tượng áp dụng, không nên trộn lẫn cùng lúc nguyên vật liệu, vật liệu bao bì, phụ tùng thay thế, khuôn, hàng hoàn trả thành phẩm, v.v. vì thời gian thao tác, hạn chế phương tiện, nhu cầu kiểm tra, và phương pháp đối chiếu đơn đặt đều khác nhau. Giai đoạn đầu nên lựa chọn rõ ràng, ví dụ “nhập nguyên vật liệu thô theo đơn đặt hàng thông thường qua xe tải”, trong khi giao hàng trực tiếp, hàng nguy hiểm, hàng cần bảo quản lạnh, phụ tùng gấp được liệt kê như ngoại lệ. Việc này không phải để bỏ qua chức năng mà là để làm rõ tiêu chí tiếp nhận ở giai đoạn một.

Lý do phân biệt giữa đặt trước, đến nơi và tiếp nhận

Dù nhà cung ứng đã đặt trước khung giờ buổi sáng, phương tiện vẫn có thể đến trễ. Khi phương tiện đến, có trường hợp chỉ nhận được một phần vì lý do khác nhau như: sai số đơn đặt, thiếu mặt hàng, nhãn không đọc được, v.v. Ngay cả khi đã ghi nhận nhập kho, kiểm định chất lượng hoặc đăng ký tiếp nhận sản phẩm trên ERP có thể diễn ra sau đó. Tài liệu của Microsoft cũng phân chia rõ ràng giữa đăng ký trước bằng ASN, ghi nhận tại dock và chuyển tiếp nhận sản phẩm trên ERP. Do đó, mỗi giai đoạn phải có thời điểm, người phụ trách, số lượng, trạng thái riêng biệt.

Mối quan hệ giữa PO, ASN, đặt trước giao hàng, thực tế nhập kho

PO (đơn đặt hàng) là điều kiện đặt mua; ASN (thông báo giao hàng trước) là thông báo về hàng mà nhà cung ứng sẽ thực sự gửi; đặt trước giao hàng là khung thời gian cho xe và nguồn lực bốc dỡ; thực tế nhập kho là kết quả kiểm tra hàng tại hiện trường. Mô hình tương tác logistics của GS1 cũng xem thông báo gửi hàng và thông báo nhận hàng là hai giao dịch khác nhau; thông báo nhận hàng thể hiện chênh lệch giữa hàng đã báo gửi và hàng thực nhận. Hệ thống đặt trước nhập hàng có thể hiển thị các dữ liệu này trên cùng một màn hình, nhưng không được phép hợp nhất và xóa bỏ ý nghĩa gốc của từng loại dữ liệu.

Có thể có trường hợp một đơn PO được giao làm nhiều đợt, hoặc một xe tải chở hàng nhiều PO. Do đó cần tránh thiết kế một-một kiểu “mã đặt trước = mã PO”. Phân biệt rõ giữa header đặt trước và ASN/PO chi tiết, đồng thời ghi nhận riêng số lượng dự kiến và số lượng thực cho từng dòng. Tài liệu hướng dẫn quản lý inbound load của Microsoft cũng mô tả thiết kế cho phép gắn nhiều dòng lệnh đặt hàng lên một chuyến nhập hàng (load). Xem xét các đơn vị hợp đồng đặc biệt hoặc phương thức đóng gói, rồi từ đó vẽ sơ đồ mối quan hệ giữa đặt trước, xe, ASN, dòng PO, dòng nhập hàng trước khi quyết định API.

Thời điểm đối chiếu với số dư ĐH

Khi tạo đặt trước, có thể cảnh báo “PO hợp lệ hay không”, “nhà cung ứng và nơi nhận có khớp không”, “số lượng dự kiến có vượt quá nhiều so với số dư ĐH không”. Nhưng do PO có thể bị thay đổi sau khi đặt trước, kết quả kiểm tra đó không còn hiệu lực mãi mãi. Cần thiết kế để kiểm tra lại ở từng bước: khi xác nhận đặt trước, khi nhận ASN, lúc check-in tại cổng, lúc xác nhận nhập kho cuối cùng, phạm vi kiểm tra khác nhau theo từng bước. Nếu kiểm tra thất bại, cần quy định cách xử lý riêng: ví dụ giữ lại chờ xác nhận khi PO không hợp lệ, chờ phê duyệt khi vượt số lượng, chỉ cảnh báo khi chênh lệch thời hạn giao, v.v. và ghi rõ quy tắc đồng thuận của mua hàng và vận hành kho.

Khi cần nghiên cứu sâu hơn về quản lý số dư ĐH, vui lòng xem thêm bài liên quan Quản lý số dư PO và đối chiếu lịch giao hàng. Hệ thống đặt trước nhập hàng chỉ là cổng hiển thị số dư, còn có cấp quyền thay đổi đơn đặt qua giao diện đặt trước hay không thì cần cân nhắc thêm.

Cách tạo slot hệ thống đặt lịch bến nhà máy

Các slot dạng “mỗi giờ một xe” đơn giản sẽ không thích ứng được sự khác biệt về hình thức hàng và thao tác. Cần quản lý (master) số lượng bến, thời gian vận hành, kích thước phương tiện, có/không có xe nâng, phương thức bốc dỡ, khối lượng kiểm tra, và các ràng buộc an toàn. Độ dài slot không chỉ là cấu hình cố định, mà có thể ước lượng dựa trên số dòng ASN, số pallet nhập, và cho phép quản trị viên chỉnh sửa lại. Tuy nhiên, cần hiệu chỉnh các công thức dự đoán này dựa trên kết quả thực tế hiện trường, đồng thời ghi lại giá trị dự đoán vs thực tế để cải tiến.

Ví dụ, dù bến nhập nguyên liệu và thành phẩm nhìn qua giống nhau về mặt thiết bị, nhưng nếu tuyến luân chuyển hoặc quy trình xuất – nhập khác nhau thì không thể hoán đổi. Hàng nguy hiểm, hàng cần kiểm soát nhiệt độ, xe gom hàng, trả container đều được coi là ràng buộc riêng. Khi ưu tiên phân bến cho các xe quan trọng, cần ghi lại ai, vì sao đã thay đổi lịch đặt trước. Quan trọng hơn giao diện lịch, là phải giải thích được vì sao không hiển thị slot trái với ràng buộc.

Tài liệu của SAP có các trạng thái đặt lịch như “tạm”, “kế hoạch đã hoàn tất”, “đến điểm kiểm tra”, “đến dock”, “rời dock” v.v. Không cần dùng đúng các tên gọi này, nhưng nhất thiết phải phân biệt: xác nhận đặt trước, đến cổng, đến bến, hoàn thành bốc dỡ, rời khỏi – tất cả đều phải lưu thời điểm riêng biệt, để không nhầm lẫn giữa thời gian chờ và thời bốc dỡ. Việc cập nhật slot trống không chỉ dựa vào thời gian dự kiến mà còn phải xét đến hoạt động thực tế của xe trước, thời gian dọn dẹp, xác nhận an toàn.

Xác định đơn vị slot và dung lượng

Việc chọn đơn vị khi đặt slot (“mỗi xe”, “chuyến nhập”, “ASN”, “PO”) tùy theo vận hành thực tế. Nếu nhà máy thường chở nhiều PO trên một xe, thì đặt header là phương tiện/chuyến vận chuyển, còn PO là chi tiết. Nếu là PO lớn chia thành nhiều xe, cần cho phép tách nhiều đặt trước theo cùng một PO. Nếu chia hàng trên xe về nhiều bến sau khi xe đã vào cổng, cần cân nhắc cho phép gắn nhiều thao tác bến trên một lần đặt. Nếu không rõ ràng ở bước này, số lượng đặt trước sẽ không phản ánh được thực trạng xe đang chờ.

Để tránh vượt quá công suất, cần đặt hạn cho slot tạm giữ và không bán lặp lại slot đã bị giữ chờ duyệt. Nếu nhiều hệ thống đồng thời đặt lịch, phải đồng nhất quy tắc hiển thị slot trống trên giao diện và quá trình xác nhận cuối cùng. Đơn xin đặt trùng được xác định bằng request ID, tránh gửi lại mà tạo 2 đặt trước trùng lặp. Về mặt API, cung cấp cho nhà cung ứng màn hình thể hiện rõ slot ở các trạng thái “đã xác nhận”, “đang chờ duyệt”, “không được duyệt”.

Nội dung nhập và trách nhiệm khi đặt trước giao hàng của nhà cung ứng

Nếu bắt nhà cung ứng nhập quá nhiều trường ngay từ đầu, họ sẽ dễ quay lại đặt lịch qua điện thoại/email. Tối thiểu bao gồm: nhà cung ứng, nơi nhận, thời gian mong muốn, thông tin xe hoặc nhà vận chuyển, tham chiếu PO/ASN, ước lượng khối lượng hàng, thông tin liên lạc. Những trường trình bày được từ dữ liệu PO/ASN thì tự động điền, nếu bị chỉnh sửa thì yêu cầu nhập lý do. Thông tin lái xe chỉ thu thập trong phạm vi cần thiết khi vào cổng, và phải chỉ rõ thời gian lưu trữ và quyền truy cập.

Phân chia trách nhiệm phải phản ánh rõ trên giao diện. Nhà cung ứng khai báo nội dung xuất hàng và phương tiện; logistics nhà máy xác nhận khả năng đặt slot và tương thích bến; mua hàng phán quyết về tính hợp lệ của PO và thay đổi số lượng; kho kiểm đếm hàng; QA xử lý chờ kiểm tra chất lượng. Phân biệt điều kiện tự động phê duyệt và điều kiện cần người xác nhận; đồng thời xây dựng kênh xử lý khẩn cấp dù người duyệt vắng mặt để không làm tắc đầu vào. Thông báo thay đổi ngoài email còn cần thể hiện ngay trên giao diện đặt trước bản cập nhật mới nhất.

Kết hợp email, EDI và portal

Nhà cung ứng lớn có thể dùng EDI hoặc API; nhà cung ứng vừa và nhỏ nhập qua portal; các chuyến xe bất thường do bên nhà máy nhập hộ – cần đa kênh đầu vào. Dù nhập từ đâu, cũng phải hợp nhất về ID đặt trước và chu trình trạng thái. Tùy sản phẩm và hợp đồng mà có thể từ chối toàn bộ xe không có ASN, hoặc tiếp nhận rồi bổ sung ASN sau. Tài liệu Oracle mô tả quy trình đối chiếu đặt trước với ASN, sau khi check-in tại dock thì nhận ASN. Tùy vận hành thực tế của nhà máy, phải quy định rõ quyền tiếp nhận xe không ASN và thời hạn bổ sung dữ liệu.

Dịch giao diện cũng cần xem xét. Nếu tại nhà máy Thái Lan, mua hàng nói tiếng Nhật, bảo vệ nói tiếng Thái, nhà cung ứng quốc tế nói tiếng Anh, thì việc chỉ dịch tiêu đề là chưa đủ. Phải chuẩn hóa cả định dạng ngày giờ, múi giờ, số điện thoại, biển số, đơn vị, cảnh báo, tùy chọn lý do thay đổi. Đặc biệt với ngày giờ, lưu trữ dữ liệu phải cố định múi giờ, API gửi đầy đủ thông tin chênh lệch múi giờ; kiểm thử phải phát hiện lỗi lệch ngày giờ do giao diện ngôn ngữ khác nhau.

Quy tắc xử lý trễ, đến sớm, đặt lại slot

Khi hãng vận chuyển báo trễ, nếu chỉ ghi đè giờ đặt trước thì sẽ xóa mất dấu vết về cam kết ban đầu và việc trễ. Cần lưu cả slot cũ, slot sau chỉnh, thời điểm nhận thông báo, lý do, người phê duyệt vào lịch sử. Chia điều kiện phê duyệt cho các trường hợp: đặt lại trước khi xe xuất phát, thông báo trễ khi đang di chuyển, thay đổi thứ tự sau khi vào cổng. Nếu phải đẩy lịch của xe khác do thay đổi slot, cần thông báo rõ và ghi lý do ngoại lệ.

Nguồn thông tin phát hiện bị trễ gồm: báo cáo của hãng vận chuyển, thông tin vị trí, check-in thực tế tại cổng. Ngay cả khi dùng dữ liệu vị trí, giờ ETA vẫn là dự đoán, không phải thực đến. Dù hệ thống tự động cập nhật ETA, không nên tự động đổi slot dock. Người trực cổng cần nhìn thấy mọi thông tin đặt trước, hiện trạng, thứ tự đến, lý do giữ lại trên một màn hình, và phải lưu lại quyết định tại hiện trường. Đối với xe không đặt trước, nên giữ trạng thái “tiếp nhận tạm thời (walk-in)” thay vì ghi nhận lại là “đã có đặt trước”.

No Show và Hủy đặt

Xe đến muộn không được tự động hủy booking ngay mà cần quy định rõ thời gian chờ liên lạc và điều kiện chuyển slot. Nên phân biệt “ứng viên no-show” (chưa xác thực) và “chắc chắn no-show” sau xác nhận để tránh phán đoán nhầm do nghẽn mạng hoặc tắc cổng. Nếu cùng lô hàng được đặt lại sau khi bị hủy, nên tham chiếu lại booking ID cũ, không đếm thành hai slot khi tổng hợp KPI. Cần xác minh rõ mẫu số khi tính KPI cho “số lượng booking xác nhận”.

Quy trình phân bến và tiếp nhận hiện trường

Tại hiện trường, ngoài mã đặt trước còn kiểm tra biển số xe, nhà cung ứng, ASN, PO, dạng hàng. Quy trình phê duyệt vào cổng và khi xe đỗ tại bến là hai thời điểm riêng biệt. Nếu phát sinh thêm PO ngoài danh sách booking, logistics cần xác nhận khả năng tiếp nhận ngay tại hiện trường, và chuyển về cho mua hàng/kho duyệt nếu cần. Nếu xe chở hàng nhiều doanh nghiệp khác nhau, cần quản lý thông tin chủ hàng riêng biệt, khai báo chi tiết kết quả nhập kho cho từng mặt hàng.

Tại bến, phải ghi nhận các sự kiện: xác nhận an toàn, bắt đầu bốc dỡ, hoàn thành bốc dỡ, kiểm đếm, rời bến. Nếu việc kiểm đếm kéo dài nhưng xe đã dỡ xong thì có thể giải phóng bến, hoặc có quy trình giữ xe lại nếu cần chờ kiểm tra chất lượng. Tránh nhồi nhiều sự kiện vào một nút “nhập hoàn thành”, mà cần tách từng sự kiện đúng với quy định an toàn và chất lượng nội bộ. Phải nêu rõ trên RFP cả cách lưu tạm khi thiết bị offline và quy tắc tránh nhập trùng khi phục hồi dữ liệu.

Nếu bao gồm cả công việc trong kho sau nhập, xem thêm bài liên quan Thiết kế quản lý xuất-nhập kho và phản ánh tồn. Nếu gộp mọi trạng thái từ đặt trước đến lưu kho thành “hoàn thành”, sẽ không thể xác định được điểm nào bị trễ, do đó cần ghi chú tách biệt thời điểm xe vào bến, kiểm đếm, kiểm định, lưu kho.

Ranh giới cần bảo vệ khi liên kết thông tin dự kiến và kết quả thực tế nhập kho

Phải xác định rõ từ đầu đâu là thông tin sẽ chuyển từ hệ thống đặt trước lên ERP. Thông thường, hiển thị thông tin dự kiến cho mua hàng/lập kế hoạch sản xuất, kết quả nhập thực sẽ được ghi nhận chính từ tính năng tiếp nhận của WMS hoặc ERP. Nếu booking bị hủy, không được tự ý đóng PO; nếu slot bến còn trống cũng không được xác nhận số nhập là bằng 0. Ngược lại, nếu số nhập thực ít hơn dự kiến thì cần quản lý xử lý thực tế chênh lệch và số dư còn lại phải do mua hàng quyết định.

Tài liệu Microsoft về quản lý kho mô tả quy trình: sau khi nhập số thực vào inbound load, chuyển qua tiếp nhận sản phẩm bằng chức năng nhận hàng trên ERP để cập nhật tồn kho và kế toán. Khi tích hợp hệ thống đặt trước với ERP, cần làm rõ bằng hợp đồng và quy trình vận hành: ở sự kiện nào thì “hàng đã đến vật lý”, “đã kiểm đếm”, “đã ghi nhận tồn kho”, “có thể dùng đối chiếu hóa đơn”. Tên trạng thái và thời điểm ghi nhận trên các ERP khác nhau, không được tự động đồng nhất chỉ dựa vào tên sản phẩm.

Mapping ID, đơn vị, trạng thái

Tối thiểu cần có các khóa liên kết: mã đặt trước, mã nhà cung ứng, nơi nhận, mã PO và số dòng, mã ASN và số dòng, mã sản phẩm, kiểu đóng gói, đơn vị đo, mã xe/ chuyến. Với sản phẩm bắt buộc lô hoặc serial, cần thêm chi tiết tương ứng. Xác định rõ ERP có cho phép nhập từng phần cho dòng PO không, mã sản phẩm phía nhà cung ứng có khác không, có cần quy đổi đơn vị không. Ví dụ, nếu đối chiếu số lượng mà không đồng nhất đơn vị hộp / cái, kg/bịch, cảnh báo sai lệch sẽ không còn giá trị. Quản lý chuẩn hóa hệ số quy đổi và quy tắc làm tròn dữ liệu.

Về trạng thái, có thể đặt ra các ứng viên như: “tạo mới”, “gửi yêu cầu”, “xác nhận”, “yêu cầu đặt lại”, “đến nơi”, “vào bến”, “bốc dỡ xong”, “nhập kho từng phần”, “nhập kho hoàn thành”, “hủy”, … và sẽ tinh gọn theo thực tế nghiệp vụ. Điều quan trọng không phải là tên trạng thái, mà là vai trò nào được chuyển tiếp trạng thái nào trong điều kiện nào. Các thao tác hoàn về trạng thái trước phải được lưu vào lịch sử và dù nhiều lần nhận được cùng thông báo cũng không được ghi nhận nhập kho lặp. Nếu kết nối với ERP thất bại, ghi rõ sự khác biệt giữa “chờ gửi lại” và “nghiệp vụ đã chắc chắn”; trên giao diện phải chỉ rõ hệ thống nào là mới nhất.

Xử lý chênh lệch và chờ xử lý

Chênh lệch về số lượng thực, thừa thiếu, sai loại, hư hại, không khớp lô, kiểm định giữ lại, thiếu chứng từ… không được gom thành một “lỗi” chung. Cảnh báo ở bước đặt trước, chờ xử lý ngay tại cổng, chênh lệch sau bốc dỡ, chờ QA đều là các trường hợp phải phân rõ người chịu trách nhiệm và bước xử lý tiếp theo. Nếu muốn đính kèm hình ảnh hoặc chứng từ cho trường hợp sai lệch, cần quy định nơi lưu, quyền truy cập, và cách tham chiếu dữ liệu vào ERP. Việc đặt trước có bao gồm quy trình hoàn trả/hủy hàng, đề nghị nhà cung ứng gửi lại hay không, cần phải ghi rõ phạm vi.

Các Yêu Cầu Nên So Sánh Khi Lập RFP

Bản demo sản phẩm thường trình bày quy trình thuận lợi. Tuy nhiên, sau khi triển khai, những điều gây nhiều phiền toái thường là các tình huống: chậm trễ, hàng ghép, giao một phần, thay đổi PO, thiếu sót ASN, mất kết nối. Khi lập RFP, thay vì liệt kê danh sách màn hình, hãy mô tả rõ kịch bản thực tế và các tiêu chí đạt/không đạt. Đừng chỉ ghi “có thể đặt hẹn”, mà nên nêu “điều kiện nào cho phép đặt lịch, khi có ngoại lệ thì ai dựa vào đâu để quyết định” để từ đó so sánh đề xuất của các bên.

Khi so sánh báo giá, không chỉ nhìn vào chi phí thiết lập ban đầu mà hãy tách riêng các phần: hỗ trợ đăng ký nhà cung ứng, kết nối EDI, cải tiến ERP, thiết bị cổng vào, đào tạo, giám sát vận hành, cập nhật phiên bản. Cũng cần hỏi rõ: phí thay đổi khi số lượng đặt hẹn, số địa điểm, số người dùng, lượng API phát sinh… Nếu dùng cloud, phải kiểm tra vị trí lưu trữ dữ liệu, phân quyền, nhật ký kiểm toán, sao lưu, cách tiếp nhận dự phòng khi gặp sự cố. Không mặc định bất kỳ tính năng của sản phẩm cụ thể nào mà hãy lấy kịch bản thực tế của doanh nghiệp làm tiêu chuẩn đánh giá.

Ví Dụ Điều Kiện Tiếp Nhận Cần Viết Trong Yêu Cầu

Chỉ nói “Nhà cung cấp có thể chọn PO và khung giờ mong muốn” thì không thể kiểm thử. Hãy diễn đạt như sau: “Nhà cung cấp có thể chọn dòng PO hợp lệ và bổ sung nhiều dòng PO vào cùng chuyến xe. Các bến không khả dụng sẽ không được hiển thị. Khi xác nhận đặt hẹn sẽ sinh một ID duy nhất, gửi lại cũng không tạo hai mục trùng nhau.” Với trường hợp chờ kiểm tra chất lượng: “Chi tiết được xác định là cần kiểm định chất lượng khi tiếp nhận hàng sẽ không chuyển vào tồn kho sử dụng trước khi được phê duyệt đúng quy trình, dù nhân viên kho đã ghi nhận số lượng nhập”, đồng thời chỉ rõ đối tượng liên quan và bên chịu trách nhiệm.

Điều kiện tiếp nhận phải bao gồm cả trường hợp không đủ quyền, thiếu thông tin bắt buộc, trùng lặp, xin lại sau khi hủy, API dừng, lệch múi giờ, sai đơn vị tính… Yêu cầu về hiệu năng nên dựa trên số lượt đỉnh tại doanh nghiệp, số thao tác đồng thời thực tế, không đưa ra các con số thời gian không có căn cứ. Không chỉ đo phản hồi màn hình mà còn đo thời gian từ khi đặt hẹn xác nhận cho đến khi thông báo cho nhà cung cấp, ERP được đồng bộ để nhận diện các chậm trễ thực tế trong vận hành.

Phân Định Rõ Kiểm Thử RFP, FAT, SAT Đối Với Đặt Lịch Nhận Hàng Nhà Máy

FAT (Factory Acceptance Test – Kiểm tra nghiệm thu tại nhà máy) dùng hệ thống đã cấu hình đầy đủ trên môi trường test để xác nhận các chức năng và chuẩn tích hợp như hợp đồng. SAT (Site Acceptance Test – Kiểm tra nghiệm thu tại hiện trường) kiểm tra với cổng, bến, thiết bị, mạng, nhân viên và kết nối ERP/WMS thực tế xem quy trình có vận hành được hay không. Vì mỗi hợp đồng có thể gọi tên khác nhau, trong RFP cần nêu rõ: “ai, tại môi trường nào, dùng dữ liệu gì, tiêu chí đánh giá là gì”. Đã có trường hợp FAT pass nhưng lên thực tế SAT lại không đọc được số xe hoặc nhãn, do đó cần đánh giá FAT và SAT độc lập.

Dữ liệu kiểm thử sẽ lấy từ các tổ hợp thực tế được ẩn danh: chia một PO thành hai chuyến, gộp hai PO trên cùng chuyến, số lượng ASN và thực nhận khác nhau, xe đến sau khi đã hủy lịch, hoặc ERP bị ngắt tạm thời… Chỉ dùng dữ liệu mẫu của nhà cung ứng có thể bỏ sót vấn đề về chuyển đổi đơn vị hoặc mã hàng. Kết quả ghi nhận không chỉ bao gồm “pass” mà còn cả hiển thị màn hình, người nhận thông báo, log kiểm toán, kết quả phía ERP, trạng thái sau khi xử lý lại.

Tiêu Chuẩn Đạt/Không Đạt & Xử Lý Vấn Đề Tồn Đọng

Tiêu chí đạt/không đạt không chỉ là “chạy bình thường”, mà phải lưu lại từng thao tác nhập, vận hành, kết quả mong đợi, chứng cứ, và người xác nhận. Ví dụ: “Gửi hai lần cùng một sự kiện đến từ ASN, chỉ ghi nhận một thực nhập, lượt thứ hai đánh dấu trùng lặp” thì phải tái hiện được. Nếu còn tồn đọng lỗi nghiêm trọng, cần lập quy trình tạm thời, chỉ định người chịu trách nhiệm, thời hạn, điều kiện tái kiểm thử. Các quy trình “làm thủ công” chỉ được chấp nhận sau khi đã đánh giá số lượng phát sinh và phân vùng trách nhiệm rõ ràng.

Thực hiện SAT phải có các vai trò liên quan trực tiếp tham dự: bảo vệ, logistics, kho, mua hàng, chất lượng, hệ thống, đại diện nhà cung cấp lớn – ít nhất mỗi bên xác nhận thao tác của chính mình. Kiểm chứng thông báo phê duyệt gửi đúng người, màn hình tiếng Thái/tiếng Anh thể hiện dễ hiểu, thiết bị truy xuất biển số xe và hàng hóa chuẩn xác. Các điểm làm thao tác viên lúng túng (không theo tài liệu) cũng cần ghi lại để đánh giá giải quyết bằng đào tạo hay phải sửa giao diện hoặc điều chỉnh phân quyền.

Trình Tự Triển Khai & Kế Hoạch Chuyển Đổi

Trước tiên, quan sát quy trình nhận hàng hiện thời, ghi lại thời điểm đến từng chuyến, lý do chờ, thời gian dỡ hàng, chênh lệch số lượng, và các lộ trình tiếp nhận. Phỏng vấn nhà cung cấp để xác định thời điểm xác nhận xuất hàng và mức chi tiết có thể phát hành ASN. Tiếp theo, quyết định mối quan hệ dữ liệu giữa PO – ASN – đặt lịch – nhận hàng, luồng trạng thái, vai trò chịu trách nhiệm. Nếu làm màn hình trước mà thiếu sơ đồ này thì khi tích hợp với ERP rất dễ nảy sinh vùng xám.

Áp dụng thử ban đầu nên giới hạn ở một số bến, nhà cung cấp, mặt hàng và duy trì song song với quy trình giấy tờ hoặc điện thoại cũ trong một giai đoạn chuyển tiếp. Tuy nhiên, không được để tình trạng nhập liệu hai hệ thống kéo dài; mỗi ngày phải xác định đâu là hệ thống gốc đối với các giao dịch phát sinh. Quan sát không chỉ tỷ lệ đặt lịch mà còn cả các chỉ số: đúng giờ đến, chờ tại cổng, chờ bến, thời gian dỡ hàng, chênh lệch số lượng kế hoạch và thực tế, thất bại khi cập nhật ERP. Mục tiêu cải tiến là phân loại rõ nguyên nhân gây trễ để có biện pháp riêng, chứ không phải để chỉnh sửa thành chỉ số đẹp.

Sau khi vận hành, cần thường xuyên đánh giá lại gánh nặng đăng ký bên nhà cung ứng và thực tế hiện trường. Tăng trường thông tin bắt buộc chưa chắc nâng chất lượng dữ liệu. Nếu còn nhiều trường hợp đăng ký thay, cần cân nhắc giảm bớt trường thông tin hoặc tăng lựa chọn tiếp nhận tự động. Nếu thường xuyên trễ, phải điều tra kỹ cả độ dài ca/xuất, tình hình giao thông, tổ chức dỡ hàng, bước kiểm đếm/trả hàng. Nếu có nhiều lệch trong nhận hàng, cần kiểm lại thời điểm lập ASN và quy trình gửi thông báo thay đổi PO.

Chuẩn Bị Dữ Liệu & Tiêu Chí Chuyển Đổi Khi Triển Khai

Các bảng master đầu tiên nhập vào hệ thống đặt lịch gồm: nhà cung cấp, điểm giao hàng, cổng, bến, lịch hoạt động, loại xe, phân loại mặt hàng, điều kiện xếp dỡ. Mỗi master cần xác định bộ phận quản lý và tần suất cập nhật. Ví dụ: nếu mã nhà cung ứng khác nhau giữa ERP và hệ thống đặt lịch thì phải có bảng đối chiếu, tránh so sánh tên. Kỳ nghỉ bảo trì bến hay bảo dưỡng thiết bị phải đẩy lên hệ thống trước khi hiển thị suất đặt lịch. Nếu có chuyển đổi từ hệ thống cũ hoặc file excel sang, cần xác định ngày gốc cho dữ liệu chuyển đổi, cách xử lý lịch đã hủy, lưu lại bảng chuyển đổi ID giữa hệ thống cũ và mới.

Ngày chuyển đổi chính thức, tại hiện trường phải phân biệt được các lịch đặt thuộc hệ thống nào xác nhận. Tránh trường hợp nhà cung cấp đăng ký lại lịch cũ sau chuyển đổi, gây trùng chỗ; do đó, nội dung thông báo và quy trình tiếp nhận trước/sau chuyển đổi phải đồng nhất. Ngày đầu vận hành cần thiết lập kênh hỗ trợ tại cổng và logistics, đồng thời chuẩn bị biểu mẫu/thiết bị cho các tình huống như không tra được lịch, đổi biển số xe, chưa có ASN, dừng kết nối ERP. Khi phục hồi, cần hướng dẫn cụ thể thứ tự nhập lại các bản ghi dự phòng và cách xóa trùng lặp.

Không chỉ xem màn hình hoạt động là đã triển khai thành công, mà phải xác nhận đủ các điều kiện: nhà cung ứng đã đăng ký xong, đối chiếu xong các lịch chưa xử lý, các ngoại lệ lớn đã test SAT, ERP/WMS đã đồng bộ và thử gửi lại, hiện trường đã được đào tạo, quy trình tiếp nhận dự phòng đã định sẵn khi gặp sự cố. Với các vấn đề tồn đọng thì phải định rõ ảnh hưởng đến nghiệp vụ, biện pháp tạm thời, người phụ trách, hạn giải quyết, và ghi nhận ai là người xác nhận đưa hệ thống vào vận hành chính thức. Như vậy, sẽ tránh được tình trạng đẩy chỉ số đặt lịch nhưng thực tế lại phát sinh thêm thao tác tay khác tại hiện trường mà không kiểm soát được.

Câu Hỏi Thường Gặp

Hệ thống đặt lịch nhận hàng cho nhà máy có thể chỉ dùng ERP không?

Nếu ERP đã có chức năng dự báo nhận hàng hoặc đặt lịch, về lý thuyết có thể bắt đầu mà không cần thêm hệ thống mới. Tuy nhiên, phải kiểm tra: nhà cung cấp có chọn được suất đặt, có thể mô tả được hạn chế bến không, có tách được sự kiện đến cổng và ghi nhận vật lý không, có theo dõi được lịch lại khi trễ không. Không nên quyết định dựa trên tên sản phẩm, hãy thử nghiệm theo kịch bản thực tiễn.

Hệ thống đặt lịch bến nhà máy có giống WMS không?

Có trường hợp chức năng bị giao thoa, nhưng đặt lịch là để lên kế hoạch xe và nguồn lực xếp dỡ trong tương lai; còn WMS tập trung vào ghi nhận thực tế nhận hàng và vận hành trong kho. Các tài liệu của Oracle, SAP cũng nhấn mạnh tích hợp giữa lịch hẹn và nhập kho/hoạt động tại bến. Dù cùng nằm trong một sản phẩm thì cũng nên tách bạch bản ghi đặt lịch (kế hoạch) và bản ghi thực nhận (kết quả).

ASN có bắt buộc đối với đặt lịch giao hàng của nhà cung cấp không?

Không có câu trả lời cố định. Nếu có ASN, sẽ dễ đối chiếu trước với dự kiến từng mặt hàng. Tuy nhiên, không phải nhà cung cấp nào cũng gửi được ASN. Có thể chỉ yêu cầu tham chiếu PO để cho phép đặt lịch tạm, hoặc phía nhà máy sẽ nhập hộ, tùy từng mặt hàng, rủi ro. Cần xác định rõ thông tin và trách nhiệm bổ sung trước khi xác nhận nhập chính thức.

Khi tích hợp dữ liệu dự kiến nhận, thực nhập cần lưu tâm gì nhất?

Không được gộp các sự kiện đặt lịch, đến cổng, kiểm đếm thực tế, ghi nhận tồn kho vào chung một bước xác thực. Cần kiểm thử kỹ các trường hợp: số lượng dự kiến và thực tế khác nhau, sự kiện trùng lặp, gửi lại khi ERP dừng kết nối, hủy và đặt lại hẹn. Cần chỉ rõ hệ thống nào giữ dữ liệu gốc của từng phần này trong tài liệu đặc tả.

RFP, FAT và SAT tối thiểu cần gì?

RFP phải chứa rõ luồng dữ liệu, vai trò, trạng thái, trường hợp ngoại lệ, tích hợp, tiêu chí đạt/không đạt. FAT kiểm tra các chức năng, API với cả trường hợp chuẩn lẫn lỗi; SAT xác minh vận hành thực tế tại cổng, bến, thiết bị, nhân viên, kết nối ERP toàn quy trình nhập hàng. Cần thống nhất cách lưu chứng cứ test và quy trình xử lý vấn đề chưa giải quyết.

Tổng Kết

Đặt lịch nhận hàng tại nhà máy là cơ chế tổ chức kế hoạch cho xe và nguồn lực xếp dỡ. PO là cam kết mua hàng, ASN là dự báo xuất hàng, ghi nhận thực nhập là kết quả vật lý – cần tách bạch rõ dữ liệu gốc cho từng đối tượng và liên kết hợp lý. Thành công của việc triển khai không nằm ở giao diện hiển thị suất trống, mà quyết định bởi việc quy trình có duy trì được khi xảy ra giao một phần, hàng ghép, trễ, chênh lệch số lượng, chờ kiểm nghiệm, dừng ERP… Hãy mô tả minh bạch ngoại lệ và điều kiện tiếp nhận trong RFP, kiểm tra chức năng kỹ tại FAT rồi kiểm chứng vận hành thực tiễn tại SAT.

Nếu quý doanh nghiệp đang cần tư vấn sắp xếp luồng nhận hàng và quy trình ngoại lệ tại nhà máy Thái Lan, hoặc tích hợp giữa đặt lịch và ERP, WMS, hãy liên hệ TOMAS TECH và gửi thông tin điểm kho, bối cảnh gặp khó khăn để được hỗ trợ.

Tài Liệu Tham Khảo

• GS1 Logistics Interoperability Model Application Standard: Giao dịch thông báo gửi và nhận hàng, bao gồm chênh lệch giữa dự kiến và thực nhận.
• SAP Dock Appointment Scheduling: Giải thích về sự kiện đến xe, kế hoạch xếp dỡ và tải bến.
• SAP Yard Logistics: Dock Appointment Scheduling: Trạng thái đặt lịch và điều kiện check-in.
• Oracle Warehouse Management: Creating Appointments: Đặt lịch, cập nhật đến, phân bến, thao tác nhập ASN.
• Microsoft Learn: Warehouse handling of inbound loads: Lập inbound từ PO/ASN, đăng ký, ghi nhận nhập hàng.
• Microsoft Learn: Product receipt against purchase orders: Đăng ký ASN trước, ghi nhận thực nhận, phân biệt nhập hàng hóa.