Hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy: Hướng dẫn triển khai

Trong lĩnh vực sản xuất, việc thiếu hụt linh kiện đột xuất hoặc sự cố bất ngờ của thiết bị làm tăng nguy cơ dừng dây chuyền sản xuất. Tại các nhà máy sản xuất ở Thái Lan, khi xem xét triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy để ứng phó nhanh chóng và chắc chắn với các tình huống khẩn cấp như vậy, cần thiết kế đồng thời cả tốc độ xử lý và dấu vết phê duyệt. Bài viết này sẽ trình bày chi tiết toàn bộ quy trình từ định nghĩa yêu cầu đặt hàng khẩn cấp, luồng phê duyệt, đến đặt hàng, nhận hàng và đối chiếu, đồng thời lồng ghép các điểm quyết định thực tế trong thiết kế và vận hành hệ thống.

Giải quyết các vấn đề nhờ triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy

Việc triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy tại các cơ sở sản xuất ở Thái Lan chủ yếu nhằm giải quyết các vấn đề sau:

• Giảm thiểu rủi ro dừng dây chuyền do thiếu linh kiện hoặc sự cố thiết bị

Khi xảy ra tình trạng hết hàng tồn kho các linh kiện chính hoặc thiếu phụ tùng dự phòng cho thiết bị, quy trình từ yêu cầu mua hàng khẩn cấp, phê duyệt, đặt hàng, giao hàng, nhận hàng đến đối chiếu hóa đơn sẽ được đẩy nhanh, giúp giảm thiểu tối đa thời gian dừng máy.

• Phân biệt rõ ràng với đặt hàng thông thường

Đặt hàng khẩn cấp tạo ra một cam kết mua sắm mới, khác với việc thay đổi đơn giá của PO hiện có hoặc điều chỉnh giao hàng từng phần. Chính sách kiểm soát được khuyến nghị là ghi lại sự phê duyệt của người có thẩm quyền, hoặc chỉ cho phép tự động phê duyệt/bỏ qua phê duyệt nếu đáp ứng các điều kiện đã được phê duyệt trước. Đường đi phê duyệt và điều kiện bỏ qua sẽ khác nhau tùy theo sản phẩm, do đó không nên bỏ qua phê duyệt chỉ vì lý do “khẩn cấp” một cách vô điều kiện (Microsoft Learn, Purchase requisition workflow; Oracle Fusion Cloud Procurement, Using Procurement).

• Khác biệt với việc tái sắp xếp kế hoạch sản xuất

Mua hàng khẩn cấp là một quy trình ra quyết định riêng biệt, không phải là thay đổi thứ tự ưu tiên trong kế hoạch sản xuất hiện tại (rescheduling) hay quản lý PO thông thường (thay đổi đơn giá, thời hạn giao hàng). Đặt hàng khẩn cấp tập trung vào việc phê duyệt và thực hiện đơn đặt hàng mới.

Xác định trước ranh giới mức độ khẩn cấp và thẩm quyền phê duyệt

Trong thiết kế hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy, điều đầu tiên cần xác định là “trường hợp nào được coi là khẩn cấp” và “ai có quyền phê duyệt đến đâu”.

Tiêu chí xác định mức độ khẩn cấp (ví dụ)

• Lượng tồn kho còn lại

Ví dụ: Dự kiến linh kiện chính sẽ hết trong vòng 24 giờ tới

• Thời gian còn lại đến khi dừng dây chuyền

Ví dụ: Không có hàng thay thế, nguy cơ dừng sản xuất trong vòng 2 giờ

• Khả năng thay thế

Ví dụ: Không thể thay thế bằng linh kiện khác hoặc quy trình khác

• Thời gian giao hàng (Lead time)

Ví dụ: Nếu mua theo quy trình thông thường sẽ không kịp tiến độ

• Tác động chi phí

Ví dụ: Thiệt hại lớn tính theo giờ khi dây chuyền dừng hoạt động

Những tiêu chí trên chỉ là ví dụ tham khảo khi thiết kế, cần điều chỉnh phù hợp với thực tế từng doanh nghiệp. Định nghĩa pháp lý về khẩn cấp và nghĩa vụ phê duyệt có thể khác nhau tùy quốc gia, ngành nghề, do đó cần xác định dựa trên quy định nội bộ và danh mục hàng hóa liên quan.

Điểm lưu ý trong thiết kế thẩm quyền

• Nguyên tắc bốn mắt (4-eyes principle)

Dù trong trường hợp khẩn cấp, bắt buộc phải có ít nhất 2 người (người đề xuất + người phê duyệt) tham gia để ngăn ngừa gian lận hoặc đặt hàng sai.

• Ngưỡng giá trị & phê duyệt ngoại lệ

Đơn hàng dưới một mức giá trị nhất định có thể được trưởng bộ phận phê duyệt ngay; vượt mức này cần thêm phê duyệt của trưởng phòng hoặc ban giám đốc.

• Ủy quyền & trực phê duyệt ngoài giờ

Ban đêm, ngày nghỉ cần chỉ định người trực phê duyệt để tránh chậm trễ quyết định khi có sự cố.

• Phân nhánh kịch bản

– Sắp dừng dây chuyền: Luồng phê duyệt tức thời

– Cần mua trong 24 giờ: Luồng phê duyệt rút gọn

– Có thể mua theo quy trình thường: Luồng phê duyệt tiêu chuẩn

Kết nối các sự kiện từ thiếu hụt/sự cố đến đặt hàng bằng một mã ID duy nhất

Thiết kế hệ thống được đề xuất trong bài viết này cho phép theo dõi toàn bộ quá trình từ phát hiện thiếu hụt/hỏng hóc đến PO và nhận hàng bằng một mã yêu cầu duy nhất. Tiêu chuẩn truy xuất nguồn gốc toàn cầu GS1 xử lý các sự kiện truy vết quan trọng (CTE) liên quan đến di chuyển vật lý như nhập kho, cùng với các yếu tố dữ liệu chính (KDE) mô tả “ai, cái gì, ở đâu, khi nào, tại sao”. Việc phê duyệt mua hàng không được xem là một CTE theo GS1. Khi nhận hàng, tham khảo phương pháp của GS1 để liên kết số tham chiếu của yêu cầu, PO và nhận hàng (GS1 Global Traceability Standard).

Các sự kiện chính trong quy trình mua hàng khẩn cấp

Mỗi sự kiện được liên kết bằng ID yêu cầu, để lại dấu vết kiểm toán cho các quyết định. Trong Oracle Fusion Cloud Procurement, loại yêu cầu mua đặc biệt ’emergency requisition’ có thể đặt trước số PO ngay khi gửi. Ngược lại, yêu cầu mua thông thường chỉ gắn cờ ưu tiên xử lý gấp ‘urgent’ không đặt trước số PO. Đây là đặc điểm sản phẩm của Oracle và không phải là hành vi chung của tất cả các hệ thống ERP (Oracle Fusion Cloud Procurement, Using Procurement). Quy trình phê duyệt yêu cầu mua của Microsoft xử lý trạng thái từ bản nháp đến phê duyệt và lộ trình phê duyệt. Ngoài ra, khi triển khai, bạn nên thiết kế để ghi nhận thời điểm phát sinh từng sự kiện và tham chiếu đến PO (Microsoft Learn, Purchase requisition workflow).

Luồng phê duyệt đặt hàng: Xử lý ngoại lệ nhanh, lưu vết chặt chẽ

Khi thiết kế luồng phê duyệt mua hàng khẩn cấp, cần đảm bảo vừa xử lý ngoại lệ nhanh chóng, vừa lưu giữ bằng chứng nghiêm ngặt.

Thẩm quyền phê duyệt & xử lý ngoại lệ

• Ma trận thẩm quyền

Xác định người phê duyệt theo giá trị, mặt hàng, mức độ khẩn cấp. Ví dụ, đặt hàng khẩn cấp với nhà cung cấp đã tin cậy (đối tác hiện tại) cần trưởng bộ phận hiện trường + trưởng phòng mua hàng phê duyệt; với nhà cung cấp mới hoặc giá trị lớn thì bắt buộc thêm phê duyệt cấp cao hơn.

• Giới hạn giá & phụ phí

Nếu chấp nhận phụ phí khi mua khẩn cấp, cần quy định mức trần và bắt buộc ghi rõ lý do để có thể rà soát sau này.

• Phân tách chức năng

Phân tách vai trò người đề xuất, nhân viên mua hàng và người phê duyệt để giảm rủi ro gian lận.

• Tự động chuyển cấp & quản lý thời hạn

Nếu phê duyệt không hoàn thành trong thời gian quy định, hệ thống tự động chuyển lên cấp trên. Ngoài giờ hành chính, người trực phê duyệt sẽ xử lý.

• Cấm phê duyệt sau sự kiện

Ngay cả với đơn hàng khẩn cấp, không được phép “làm giả hồ sơ phê duyệt sau”, bắt buộc phải lưu lại bằng chứng phê duyệt theo thời gian thực.

Bằng chứng & kiểm toán

• Dấu vết kiểm toán bất biến

Cần thiết kế hệ thống lưu lại lịch sử chỉnh sửa để có thể truy vết người phê duyệt, phiên bản báo giá tại thời điểm quyết định, lý do thay đổi, số đơn đặt hàng. Workflow mua hàng của Microsoft là ví dụ cho phép thiết lập luồng phê duyệt, cách lưu dấu vết kiểm toán cần xác nhận theo hệ thống và cấu hình khi triển khai (Microsoft Learn, Purchase requisition workflow).

• Quản lý rõ ràng trạng thái chuyển đổi

Quản lý rõ từng trạng thái: yêu cầu, phê duyệt, PO, nhận hàng, hóa đơn, đồng thời lưu dấu thời gian. Nhờ đó, dễ dàng truy vết nguyên nhân khi có sự cố hoặc phục vụ kiểm toán sau này.

Việc triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy giúp cân bằng giữa tốc độ xử lý ngoại lệ và quản lý hồ sơ nghiêm ngặt, từ đó giảm thiểu rủi ro và tăng cường quản trị tại hiện trường sản xuất.

Đánh giá đồng thời rủi ro về giá, nhà cung cấp và chất lượng trong trường hợp khẩn cấp

Khi triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy trong ngành sản xuất, điều quan trọng nhất là phải cân bằng giữa “tốc độ” và “quản lý rủi ro”. Đặc biệt tại các nhà máy ở Thái Lan, khi cần mua sắm khẩn cấp do thiếu linh kiện hoặc hỏng hóc thiết bị, nếu bỏ qua quy trình phê duyệt, có nguy cơ đặt hàng mà không đánh giá rủi ro về giá, chất lượng và nhà cung cấp.

Vì vậy, ngay cả khi đặt hàng khẩn cấp, cần thiết lập tối thiểu các cổng kiểm tra và vận hành kiểm tra đồng thời các khía cạnh sau:

• Danh sách nhà cung cấp đã được phê duyệt (Approved Vendor List, AVL)

Nếu mua từ các nhà cung cấp đã được phê duyệt, có thể đơn giản hóa quy trình phê duyệt trong hệ thống quản lý mua hàng thông thường.

• Phê duyệt có điều kiện khi sử dụng nhà cung cấp mới

Khi sử dụng nhà cung cấp chưa đăng ký, cần có phê duyệt tạm thời từ trưởng bộ phận mua hàng hoặc bộ phận đảm bảo chất lượng.

• Phê duyệt sự phù hợp và chất lượng của linh kiện thay thế

Nếu mã linh kiện hoặc thông số kỹ thuật khác nhau, bắt buộc phải có xác nhận sự phù hợp từ bộ phận thiết kế hoặc bộ phận chất lượng.

• So sánh giá mua hàng đột xuất (spot buy)

Ngay cả khi mua khẩn cấp, nếu có thể, nên so sánh nhiều báo giá, đồng thời so sánh tổng chi phí bao gồm phí vận chuyển, thuế nhập khẩu và rủi ro tỷ giá.

• Rủi ro khi chỉ có một báo giá hoặc cam kết giao hàng ngay

Nếu chỉ có báo giá từ một nhà cung cấp hoặc cam kết miệng như “có thể giao ngay”, phải ghi lại lý do ngoại lệ và người phê duyệt phải chấp nhận rủi ro một cách rõ ràng.

• Xác định mức độ ưu tiên

Tùy theo rủi ro dừng sản xuất hoặc mức độ ảnh hưởng đến thời hạn giao hàng cho khách hàng, quyết định rút ngắn quy trình phê duyệt hoặc bổ sung các cổng kiểm tra.

Bảng quyết định thực tiễn cho đánh giá mua hàng khẩn cấp

Như vậy, ngay cả trong trường hợp khẩn cấp, cần đính kèm và quản lý phiên bản lý do ngoại lệ và bằng chứng (báo giá, email phê duyệt, tài liệu kỹ thuật, v.v.) trên hệ thống để đảm bảo có thể kiểm tra lại sau này.

Ngoài ra, quy trình phê duyệt nên được thiết kế để có thể định tuyến theo “từng tài liệu” hoặc “từng dòng chi tiết” như trên Microsoft Dynamics 365. Người phê duyệt có thể được xác định tự động dựa trên hạn mức chi tiêu hoặc mức độ rủi ro (Microsoft Learn).

Kết nối nhanh chóng giữa phê duyệt, đặt hàng và nhận hàng

Sau khi mua hàng khẩn cấp được phê duyệt, điều quan trọng là phải phân biệt rõ từng giai đoạn từ đặt hàng (PO) đến nhận hàng, đồng thời minh bạch tiến độ.

Đặc biệt, cần theo dõi trên hệ thống các trạng thái như phát hành PO, nhà cung cấp xác nhận nhận hàng, xuất kho, đến nơi, kiểm tra chất lượng, phân bổ tồn kho, và thiết kế để xử lý các trường hợp ngoại lệ như sau:

• Phân biệt giữa phát hành PO và nhà cung cấp xác nhận nhận hàng

Ghi nhận riêng thời điểm phát hành đơn đặt hàng (PO) và thời điểm nhà cung cấp chính thức xác nhận, chấp nhận đơn hàng.

• Phản hồi thời hạn giao hàng, thay đổi ETA

Mọi phản hồi về thời hạn giao hàng hoặc thay đổi ETA (thời gian dự kiến đến nơi) từ nhà cung cấp đều phải được ghi nhận trên hệ thống và thông báo cho các bên liên quan.

• Giao hàng từng phần, linh kiện thay thế, quản lý lô/serial

Khi giao hàng từng phần hoặc giao linh kiện thay thế, cần tách chi tiết theo từng lô nhận hàng, ghi nhận số lô hoặc số serial.

• Kiểm dịch, phân bổ tồn kho, phòng tránh trùng lặp

Minh bạch trạng thái chờ kiểm tra chất lượng (kiểm dịch) hoặc phân bổ tồn kho, đồng thời ngăn chặn nhận hàng trùng lặp cho cùng một PO. Mọi sửa đổi PO đều phải được rà soát lại.

Lưu ý, trên Oracle Fusion Cloud Procurement, loại yêu cầu mua đặc biệt ’emergency requisition’ có thể đặt trước số PO ngay khi gửi. Ngược lại, yêu cầu mua thông thường chỉ gắn cờ ưu tiên xử lý gấp ‘urgent’ sẽ không được đặt trước số PO (Tài liệu chính thức Oracle). Tham khảo ví dụ này, khi thiết kế hệ thống cần xác định rõ “thời điểm giữ số PO” và “có cho phép phát hành PO trước khi phê duyệt hay không”.

Quay lại quy trình xử lý nhập kho, hóa đơn và giá thành thông thường

Sau khi hàng hóa mua khẩn cấp đã nhập kho, cần quay lại quy trình quản lý mua hàng thông thường, đảm bảo đầy đủ bằng chứng và quản lý chi phí chặt chẽ.

• Nhập kho (Goods Receipt)

Khi nhận hàng thực tế, đính kèm phiếu giao hàng hoặc biên bản kiểm tra lên hệ thống, ghi nhận người nhận, thời gian, số lượng, thông tin lô.

• Đối chiếu hóa đơn (Invoice Matching)

Trên Microsoft Dynamics 365, có thể so sánh giá và số lượng giữa PO, phiếu nhập kho và hóa đơn dựa trên chính sách đối chiếu ba bên đã thiết lập. Việc cho phép sai số hoặc yêu cầu phê duyệt khi có sai lệch sẽ do công ty quyết định (Microsoft Learn).

• Xử lý ngoại lệ, quản lý chi phí phát sinh

Các chi phí phát sinh do mua khẩn cấp như phí vận chuyển cao hoặc chi phí đặc biệt cần được quản lý bằng mã chi phí riêng, làm rõ trong tính giá thành và chốt sổ hàng tháng.

• Hóa đơn tạm thời, xử lý chưa nhận hàng

Quản lý hóa đơn tạm thời khi hàng chưa về hoặc phát hiện thiếu sót trong nhận hàng trên hệ thống để tránh ghi nhận trùng lặp.

• Bằng chứng và truy xuất nguồn gốc

Áp dụng tiêu chuẩn GS1 vào thiết kế truy xuất nguồn gốc khi nhập kho, ghi nhận sự kiện nhập hàng, kiểm tra (“ai”, “cái gì”, “khi nào”, “ở đâu”, “tại sao”) và liên kết các chứng từ liên quan (GS1).

Ví dụ thiết kế liên kết bằng chứng như phiếu giao hàng, biên bản kiểm tra, hóa đơn, lịch sử phê duyệt trên hệ thống khi nhận hàng khẩn cấp, phục vụ kiểm toán hoặc phân tích giá thành sau này.

Ngoài ra, cần phân biệt rõ phương pháp quản lý bằng chứng, chi phí và lịch sử phê duyệt giữa trường hợp nhập hàng từng phần của PO hiện có (vận hành thông thường) và nhập hàng từ PO mới do phát sinh mua hàng khẩn cấp.

Xác định ranh giới trách nhiệm giữa ERP, MES và WMS

Khi triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy, việc xác định ranh giới trách nhiệm và thiết kế liên kết dữ liệu giữa ERP (hệ thống quản trị tổng thể), MES (hệ thống thực thi sản xuất), WMS (hệ thống quản lý kho) là không thể thiếu.

• Ranh giới trách nhiệm

Bảng trên là ví dụ cấu hình với ERP phụ trách đặt hàng & phê duyệt, WMS phụ trách nhận hàng tại hiện trường, MES phụ trách đưa vào sản xuất. Thực tế, cần xác định hệ thống lưu trữ chính cho từng lĩnh vực dựa trên hệ thống đã triển khai.

• ID liên kết & đảm bảo không trùng lặp

Liên kết giữa các hệ thống phải quản lý bằng các ID duy nhất như số PO, số lô, đảm bảo thiết kế không trùng lặp khi gửi lại dữ liệu.

• Dấu thời gian & múi giờ

Mọi sự kiện đều phải ghi nhận cả UTC và giờ địa phương để đáp ứng yêu cầu kiểm toán và truy xuất nguồn gốc.

• Quản lý chất lượng & tồn kho

Quản lý rõ trạng thái chất lượng như kiểm dịch, đạt, không đạt và khả năng phân bổ tồn kho, ngăn ngừa sử dụng sai trước khi đưa vào MES.

Để biết thêm chi tiết về so sánh hệ thống quản lý tồn kho và thực tiễn triển khai, vui lòng tham khảo So sánh hệ thống quản lý tồn kho nhà máy, Triển khai hệ thống quản lý tồn kho tại Thái Lan.

Ba trường hợp chuyển quyền quyết định mua hàng khẩn cấp về cho hiện trường

Hãy xem xét trường hợp thiếu hụt linh kiện. Đối với linh kiện cần thiết cho lệnh sản xuất, dù số dư sổ sách vẫn đủ, nhưng thực tế trên kệ tại hiện trường lại thiếu. Nếu chỉ ghi “thiếu hàng” trong yêu cầu ban đầu và tiến hành đặt hàng, có thể bỏ sót tồn kho ở kho khác, hàng đang chờ kiểm tra chất lượng, hoặc hàng nhập chưa ghi nhận. Trên màn hình yêu cầu, cần hiển thị số dư sổ sách, số lượng thực tế trên kệ, số lượng chờ kiểm tra, số lượng có thể chuyển từ điểm kho khác, và thời điểm đưa vào sản xuất tiếp theo. Trước khi chuyển sang bộ phận mua hàng, người phụ trách kho phải xác nhận nguyên nhân chênh lệch và nếu có thể điều chuyển kịp thời thì giảm số lượng đặt hàng. Chỉ giữ lại phần thiếu hụt thực sự cần thiết để yêu cầu khẩn cấp, đồng thời nêu rõ đơn đặt hàng này nhằm đảm bảo cho lệnh sản xuất nào. Trong ví dụ này, điều cần rút ngắn không phải là thao tác nhập liệu mà là thời gian để các bên liên quan cùng nhìn thấy số lượng thiếu giống nhau.

Trong trường hợp hỏng hóc thiết bị, dù bộ phận bảo trì tìm được “linh kiện cùng loại”, cũng không nhất thiết được phê duyệt mua ngay lập tức. Cần xác nhận số hiệu thiết bị, vị trí hỏng, mã sản phẩm của nhà sản xuất, phiên bản thông số kỹ thuật, quy trình thay thế, điều kiện bảo hành, và nếu là linh kiện thay thế thì phải xác định trước ai trong các bộ phận thiết kế, chất lượng, bảo trì sẽ quyết định việc sử dụng. Quyết định mua linh kiện thay thế và quyết định lắp ráp, vận hành lại thiết bị cũng cần tách biệt. Dù linh kiện được giao nhanh và kho có thể nhận hàng, nhưng cho đến khi đánh giá phù hợp hoàn tất, cần lưu trữ ở trạng thái chờ kiểm tra chất lượng. Yêu cầu đặt hàng phải liên kết với chỉ thị bảo trì thiết bị đang dừng, để sau này có thể truy xuất “tại sao chọn linh kiện này với giá này”. Nếu sau khi đặt hàng mới phát hiện nguyên nhân hỏng khác, cần tạo tác vụ riêng để liên hệ với nhà cung cấp và xác nhận khả năng hủy đơn hàng.

Trong trường hợp lựa chọn nhà cung cấp, giả sử nhà cung cấp đã được phê duyệt giao hàng chậm, còn nhà cung cấp mới giao nhanh nhưng giá cao. Hệ thống không chỉ so sánh đơn giá mà còn hiển thị trên cùng một màn hình các thông tin như thời gian dự kiến đến, phương thức vận chuyển, loại tiền tệ, thuế, thông số thay thế, tài liệu chất lượng, điều kiện giao dịch. Nếu chỉ lấy được báo giá từ một nhà cung cấp, không để trống phần so sánh mà phải ghi rõ “lý do chỉ chọn được một nhà cung cấp” và lưu lại người phê duyệt quyết định đó. Nếu đăng ký nhà cung cấp mới chưa hoàn tất, cần xác định trước điều kiện để có thể gửi PO. Quyết định chấp nhận giá cao phải được so sánh với hiệu quả tránh dừng sản xuất trong cùng loại tiền tệ và thời gian, nếu lý do không rõ ràng thì nên quay lại quy trình thông thường. Đây không phải là màn hình để luôn hợp lý hóa chi phí tăng thêm.

Ngay trong cùng một vụ việc, ý nghĩa của thời điểm mà các bên liên quan nhìn nhận là khác nhau. “Thời điểm cần thiết” của hiện trường là lúc đưa linh kiện vào sản xuất, còn “thời hạn giao hàng” của bộ phận mua hàng thì chỉ dựa vào thời điểm nhà cung cấp xuất kho là chưa đủ. Kho còn có thời gian nhận hàng, kiểm tra, di chuyển đến vị trí lưu trữ; chất lượng cần thời gian kiểm tra và giải phóng. Do đó, cần lưu từng sự kiện riêng biệt như hạn nộp yêu cầu, gửi PO, nhà cung cấp xác nhận, xuất kho, hàng đến nhà máy, nhận hàng, giải phóng chất lượng, đưa vào sản xuất. Dù ETA của nhà cung cấp được cập nhật, không tự động chuyển trạng thái “đúng hạn” cho đến khi giải phóng chất lượng. Nếu người phê duyệt thay đổi vào ban đêm, cũng cần tái hiện được bảng phân quyền đã áp dụng, bao gồm cả thời gian và múi giờ.

Trong trường hợp giao hàng từng phần, có thể chỉ nhận được một phần hàng của PO khẩn cấp, phần còn lại sẽ đến vào ngày hôm sau. Kho nhận số lượng và lô hàng đã đến trước, phần chưa đến vẫn để ở trạng thái chưa nhận. Việc hiện trường có thể sử dụng phần hàng đến trước hay không phụ thuộc vào kết quả kiểm tra và số lượng cần thiết của công đoạn. Dù nhà cung cấp gửi một hóa đơn, không được coi là đã nhận đủ toàn bộ số lượng. Cần đối chiếu số lượng trên từng phiếu nhận hàng với hóa đơn, phần còn lại sẽ liên kết với các lần nhận sau. Nếu là giao hàng từng phần của PO hiện có thì quản lý tồn đơn hàng như bình thường, không phải lý do để tạo PO khẩn cấp mới. Chỉ khi đặt hàng bổ sung phần thiếu cho nhà cung cấp khác, mới cần ghi nhận mối liên hệ giữa yêu cầu, phê duyệt mới và phần chưa nhận của PO gốc. Nhờ đó, có cơ sở để tránh mua hàng trùng lặp.

Cần xác định ranh giới cho các thay đổi sau khi phê duyệt. Khi phê duyệt, đã xem xét số lượng, giá, nhà cung cấp, thời gian dự kiến nhận hàng cụ thể. Nếu nhân viên mua hàng chỉ thay đổi giá mà vẫn gửi đơn đặt hàng, thì điều kiện đã khác với lúc phê duyệt. Hệ thống cần so sánh trước và sau thay đổi, xác định theo bảng phân quyền nội dung nào cần phê duyệt lại. Ngược lại, nếu nhà cung cấp chỉ sửa thông tin liên hệ xác nhận nhận hàng, có thể không cần phê duyệt lại giá trị PO mỗi lần. Không xử lý tất cả các thay đổi bằng cùng một nút “thay đổi”, mà phân loại riêng các thay đổi ảnh hưởng đến điều kiện đặt hàng, chỉnh sửa thông tin liên hệ, cập nhật phản hồi thời hạn giao hàng, chỉnh sửa kết quả nhận hàng. Tất cả đều phải lưu lại người thay đổi, thời gian, nơi thông báo, và thông tin cũ đã bị hủy để tra cứu.

Khi đối chiếu sau khi nhận hàng, không được nhầm lẫn giữa việc có hàng thực tế và khả năng thanh toán. Nếu mã hàng trên phiếu giao hàng khác với PO, số lượng nhiều hơn, không đạt kiểm tra, thiếu lô, giá trên hóa đơn khác với giá đã phê duyệt, thì mỗi trường hợp có người phụ trách khác nhau. Kho phụ trách số lượng vật lý, bộ phận chất lượng phụ trách đánh giá phù hợp, mua hàng phụ trách điều kiện PO, kế toán phụ trách đối chiếu hóa đơn. Hệ thống không gom tất cả sai lệch thành một “lỗi” mà hiển thị rõ ai cần xác nhận nội dung gì để tiếp tục xử lý. Trong thời gian chờ kiểm tra chất lượng, dù hàng tồn kho vẫn không được phân bổ cho sản xuất; nếu chỉ nhận được hóa đơn trước thì không được tạo dữ liệu nhận hàng giả mà phải để ở trạng thái chưa đối chiếu. Báo cáo cuối tháng cần tách rõ các trường hợp đã đặt hàng – chưa nhận, đã nhận – chưa kiểm tra, đã kiểm tra – chưa thanh toán.

Cuối cùng, ngay cả khi mua hàng khẩn cấp thành công, “hàng đã đến” không có nghĩa là đã hoàn tất. Cần xác nhận liệu thiếu hụt hoặc hỏng hóc ban đầu đã được giải quyết chưa, có cần đặt hàng bổ sung thông thường không, chi phí tăng thêm thuộc về dự án nào, linh kiện thay thế có được phê duyệt sử dụng cho lần sau không. Không tự động nâng cấp ngoại lệ thành quy tắc lâu dài, mà phải đánh giá qua các bộ phận kỹ thuật, chất lượng, mua hàng trước khi cập nhật vào hệ thống chính. Nếu cùng một linh kiện liên tục phát sinh yêu cầu khẩn cấp, không chỉ đẩy nhanh phê duyệt mà còn phải xem xét lại tồn kho an toàn, biến động nhu cầu, chênh lệch kiểm kê, kế hoạch bảo trì thiết bị, phản hồi thời hạn giao hàng của nhà cung cấp. Hệ thống mua hàng khẩn cấp vừa là kênh xử lý ngoại lệ, vừa là nền tảng ghi nhận lý do phát sinh ngoại lệ để phản hồi về kế hoạch thông thường.

Ngay cả khi sử dụng quy tắc ngoại lệ đã được phê duyệt trước, cần giới hạn rõ phạm vi không cần sự phán đoán của con người. Ví dụ, chỉ tự động phê duyệt khi nhà cung cấp, mã hàng, điều kiện giá, giới hạn số lượng, thời hạn hiệu lực đều trùng khớp; chỉ cần một yếu tố không khớp sẽ chuyển cho người phụ trách xử lý. Kết quả phê duyệt tự động phải lưu lại phiên bản quy tắc áp dụng và dữ liệu đầu vào, truy xuất được ai, khi nào đã phê duyệt quy tắc đó. Nếu quy tắc hết hạn thì quay lại quy trình chờ phê duyệt thông thường, không hiển thị là đã đặt hàng trên màn hình hiện trường. Nếu chỉ lấy mức độ khẩn cấp làm điều kiện tự động phê duyệt, sẽ xảy ra nghịch lý là những trường hợp thiếu lý do lại được đặt hàng nhanh hơn. Ngược lại, nếu tăng quá nhiều bước phê duyệt sẽ không kịp ngăn dừng dây chuyền. Cần quy định rõ ràng rủi ro nào cần con người xem xét, và thiết kế tách biệt giữa các trường hợp định hình rủi ro thấp với các trường hợp nhà cung cấp chưa đăng ký, linh kiện thay thế, vận chuyển giá trị cao.

Chuyển đổi yêu cầu triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy thành RFP

Khi triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy trong ngành sản xuất tại Thái Lan, có rất nhiều yêu cầu cần được nêu rõ trong RFP (Yêu cầu đề xuất). Trước hết, về yêu cầu chức năng, việc thiết kế quy trình phê duyệt và đề xuất đặt hàng đáp ứng cả mua hàng thông thường và mua hàng khẩn cấp là điều không thể thiếu. Theo Microsoft Learn, quy trình phê duyệt đặt hàng nên có khả năng phân nhánh theo từng tài liệu hoặc từng dòng chi tiết, tự động xác định người phê duyệt dựa trên hạn mức giá trị hoặc theo từng phòng ban (Microsoft Learn, Purchase requisition workflow).

Trong trường hợp đặt hàng khẩn cấp, ví dụ của Oracle Fusion Cloud Procurement cho thấy khi gửi yêu cầu mua hàng khẩn cấp, có thể đặt trước số PO, còn với yêu cầu thông thường chỉ đánh dấu “khẩn” thì không được đặt trước. Vì vậy, cần làm rõ điều kiện đảm bảo số PO khi đặt hàng khẩn cấp ngay từ giai đoạn định nghĩa yêu cầu (Oracle Fusion Cloud Procurement, Using Procurement). Ngoài ra, với chức năng tạo PO tự động của Oracle, nếu giá cả hoặc các điều kiện chưa được thương lượng trước thì vẫn phải qua phê duyệt. Hãy xác định rõ các điều kiện ngoại lệ và thiết kế lưu vết phê duyệt phù hợp với doanh nghiệp (Oracle Fusion Cloud Procurement, Using Procurement).

Về yêu cầu phi chức năng, các yếu tố sau rất quan trọng:

• Hỗ trợ di động, trực ca: Thiết kế UI/UX cho phép nhân viên hiện trường và người phê duyệt có thể gửi yêu cầu, phê duyệt và kiểm tra trạng thái từ điện thoại thông minh hoặc máy tính bảng.
• Đa ngôn ngữ: Hỗ trợ chuyển đổi giữa tiếng Thái, tiếng Nhật, tiếng Anh và lưu cài đặt ngôn ngữ cho từng người dùng.
• Đa tiền tệ, hỗ trợ tiền tệ địa phương: Giao dịch, hiển thị và báo cáo bằng nhiều loại tiền tệ, bao gồm cả THB (Baht Thái).
• Kiểm soát truy cập: Quản lý truy cập dựa trên vai trò (RBAC), cấp quyền truy cập tạm thời cho nhà cung cấp bên ngoài hoặc kiểm toán viên.
• Lưu vết kiểm toán, nhật ký: Ghi lại toàn bộ thao tác gửi yêu cầu, phê duyệt, thay đổi, hủy bỏ theo trình tự thời gian, có thể tìm kiếm và xuất dữ liệu.
• Chính sách lưu trữ tệp đính kèm: Quản lý linh hoạt việc đính kèm báo giá, phiếu giao hàng, chứng từ, thời gian lưu trữ, tự động xóa hoặc lưu trữ lâu dài.

Về phạm vi, trong RFP cần ghi rõ ranh giới như: “Hệ thống này chỉ bao gồm quy trình từ đề xuất mua hàng đến đặt hàng, nhận hàng, xử lý hóa đơn; không bao gồm các chức năng chi tiết về quản lý tồn kho, lập kế hoạch sản xuất, kế toán tài chính.” Ngoài ra, cần nêu rõ yêu cầu giao tiếp với các hệ thống bên ngoài (ERP, MES, WMS, v.v.), cũng như thiết kế xử lý lỗi khi tích hợp API và phòng tránh trùng lặp.

Không trộn lẫn dữ liệu “Yêu cầu” và “Đặt hàng” trong RFP

Chỉ tạo một màn hình cho yêu cầu khẩn cấp sẽ không thể truy vết được đã đặt hàng gì sau khi phê duyệt. Yêu cầu mua hàng cần có thông tin về người tạo, địa điểm phát sinh, đối tượng bị dừng hoặc thiếu hàng, thời điểm cần, số lượng cần, đơn vị, khả năng thay thế, và thời điểm kiểm tra tồn kho làm căn cứ. Nếu là phụ tùng thiết bị thì tham chiếu số thiết bị và lệnh bảo trì; nếu là nguyên vật liệu thì tham chiếu lệnh sản xuất, mã hàng và phiên bản quy cách. Khi bộ phận mua hàng lấy lại báo giá, không được ghi đè lên yêu cầu gốc mà phải thêm phiên bản báo giá và nhà cung cấp dự kiến. Người phê duyệt cần được cung cấp một ảnh chụp tổng thể tại thời điểm nộp đơn gồm số tiền, loại tiền tệ, chi phí vận chuyển, thuế, dự kiến đến nơi và rủi ro chất lượng.

Đơn đặt hàng là một bản ghi riêng được tạo từ các điều kiện đã được phê duyệt. Cần phân biệt ID yêu cầu, ID phê duyệt, số PO, số dòng PO, và liên kết tiếp đến ID nhận hàng, ID hóa đơn sau này. Ví dụ, nếu một yêu cầu thiếu hàng được chia đặt cho hai nhà cung cấp, thì chỉ có một yêu cầu nhưng có hai PO. Ngược lại, nếu thêm hàng thông thường vào cùng một PO thì việc tổng hợp chi phí khẩn cấp sẽ bị mơ hồ. Trong RFP, yêu cầu nhà cung cấp thể hiện rõ trên cả giao diện và dữ liệu khả năng lưu lịch sử cho các trường hợp đặt hàng một-nhiều, giao hàng chia nhỏ, hủy/đặt lại, điều chỉnh giá. Việc sửa đổi bản ghi không được xóa sự kiện gốc mà phải lưu lại người sửa, lý do và phiên bản bị ảnh hưởng như một điều kiện chấp nhận.

Kiểm tra ma trận phê duyệt theo thời điểm, số tiền, nhà cung cấp

Luồng phê duyệt không thể chỉ có một dòng kiểu “khẩn cấp thì trưởng bộ phận”. Cần phân biệt thời điểm quy đổi tiền tệ cho hạn mức phê duyệt, người thay thế ban đêm, trường hợp người nộp và người phê duyệt là một, nhà cung cấp đã phê duyệt không đảm bảo tiến độ, sử dụng nhà cung cấp mới, hoặc cần thay thế linh kiện. Khi người phê duyệt thay đổi, cần thiết kế bảng quyền hạn có ngày hiệu lực để không còn các yêu cầu dựa trên quyền hạn cũ. Nếu số tiền báo giá tăng sau khi đã phê duyệt, cần xác định điều kiện tái phê duyệt không chỉ dựa vào mức tăng giá mà còn cả chi phí vận chuyển và thay đổi số lượng. Nếu nhà cung cấp thay đổi thời hạn giao hàng, dù số tiền không đổi thì vẫn phải thông báo cho bộ phận mua hàng và quản lý sản xuất do ảnh hưởng đến sản xuất.

Ngay cả khi công ty cho phép xác nhận qua điện thoại vào ban đêm, không nên thay thế việc gọi điện bằng cờ “đã phê duyệt”. Cần phân biệt rõ ai, khi nào, điều kiện nào được chấp thuận bằng miệng và ai đã ghi nhận vào hệ thống, đồng thời lưu riêng thời điểm phê duyệt chính thức và thời điểm thông báo đặt hàng. Phạm vi cho phép nhập liệu sau sự kiện phải được quy định nội bộ, thiết kế hệ thống không cho phép làm giả thời điểm phê duyệt. Nếu người phê duyệt thay thế vắng mặt thì chuyển tiếp lên người kế tiếp, nếu không ai có quyền thì dừng ở trạng thái “chờ phê duyệt” và đề xuất các biện pháp giảm nhẹ khác như chuyển kho hoặc điều chỉnh thứ tự sản xuất cho hiện trường. Cần yêu cầu nhà cung cấp trình diễn thực tế cả quy trình dừng này.

Đặc tả tích hợp phải mô tả cả quy trình khi thất bại

Bảng tích hợp ERP, WMS, MES không chỉ ghi nhận nơi gửi thành công mà còn phải chỉ rõ chủ sở hữu sự kiện khi gửi thất bại. Nếu màn hình phê duyệt báo thành công nhưng không có PO trên ERP thì phải ngăn không gửi xác nhận đặt hàng cho nhà cung cấp, hoặc bộ phận mua hàng phải kiểm tra từ hàng đợi ngoại lệ. Nếu mất kết nối trước khi ERP phản hồi, cần truy vấn lại bằng cùng ID yêu cầu và khóa idempotent để không tạo trùng PO, đây là điều kiện chấp nhận. Nếu giá thay đổi trong thời gian mất kết nối, không được gửi lại đặt hàng theo phiên bản phê duyệt cũ mà phải xét lại phần chênh lệch.

Ngay cả khi thiết bị hiện trường có thể lưu yêu cầu offline, điều đó không có nghĩa là đã hoàn tất phê duyệt hay đặt hàng tại thời điểm đó. Trên thiết bị cần hiển thị rõ các trạng thái “chưa gửi”, “đã nhận”, “chờ phê duyệt”, “đã đặt hàng” để khi khôi phục có thể kiểm tra sự kiện nào đã đồng bộ. Ở phía nhập hàng, nếu có độ trễ giữa hoàn tất nhận hàng trên WMS và ghi nhận tồn kho trên ERP, cần xác định hệ thống nào sẽ hiển thị hàng đã có thể sử dụng. Linh kiện đang chờ kiểm tra chất lượng dù đã ở trên kệ cũng không được tính vào số lượng có thể sử dụng, và việc phê duyệt giải phóng chất lượng phải là một sự kiện riêng. Những điều này giúp giải thích khi số liệu hiện trường và kế toán tạm thời khác nhau.

Ghi lại cả quyết định giảm mức độ khẩn cấp trong lịch sử

Yêu cầu khẩn cấp không nên được xử lý đến cuối chỉ dựa trên cảm giác nguy cấp ban đầu. Nếu xuất hiện thông tin mới—như phát hiện tồn kho cùng quy cách ở kho khác, thiết bị đã hoạt động trở lại sau sửa chữa, hoặc thời gian cần thiết được kéo dài do thay đổi thứ tự sản xuất—thì bộ phận mua hàng và quản lý sản xuất sẽ đánh giá lại số lượng cần thiết và thời hạn giao hàng. Nếu chưa gửi PO cho nhà cung cấp, có thể chuyển yêu cầu về quy trình phê duyệt thông thường hoặc hủy đơn đặt hàng. Nếu PO đã gửi, cần kiểm tra tình trạng chấp nhận của nhà cung cấp, điều kiện hủy, tiến độ vận chuyển và so sánh chi phí hủy với lượng tồn kho dư kiến. Hệ thống không nên thiết kế để người khởi tạo có thể tự ý gỡ cờ khẩn cấp và xóa lịch sử.

Khi đánh giá lại mức độ khẩn cấp, cần lưu lại cả dự báo thiếu hụt ban đầu và thông tin tồn kho, sản xuất mới. Ví dụ, dù phát hiện có tồn kho nhưng nếu hàng đang chờ kiểm tra chất lượng thì không tính vào số lượng có thể sử dụng. Nếu đã phê duyệt hàng thay thế, phải tính cả thời gian chuẩn bị chuyển đổi vào thời hạn giao hàng. Dù nhà cung cấp hứa giao hàng sớm, nếu chưa có xác nhận bằng văn bản thì không được hiển thị là ngày giao hàng chắc chắn. Việc phân biệt như vậy giúp giải thích sau này vì sao phải trả thêm phí vận chuyển hoặc vì sao hủy đơn hàng khẩn cấp. Những trường hợp giảm mức độ khẩn cấp cũng không nên xóa khỏi KPI mà cần lưu lại trạng thái cuối cùng và lý do thay đổi để xem xét lại việc phát hiện sớm có hiệu quả hay có nhiều cảnh báo sai.

Kế hoạch thử nghiệm 30-60-90 ngày và kiểm thử nghiệm thu

Dự án triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy nên xây dựng kế hoạch thử nghiệm theo từng giai đoạn 30 ngày, 60 ngày, 90 ngày để giảm thiểu tác động đến vận hành thực tế và đảm bảo hệ thống được áp dụng chắc chắn. Dưới đây là ví dụ điển hình về tiến độ, cần điều chỉnh phù hợp với từng doanh nghiệp.

Trong kiểm thử nghiệm thu, cần xây dựng các kịch bản cụ thể như sau:

• Mua sắm khẩn cấp khi thiếu vật tư hoặc thiết bị hỏng: Đảm bảo yêu cầu khẩn cấp từ hiện trường được phê duyệt và phát hành PO ngay lập tức.
• Đề xuất thay thế chưa được phê duyệt: Dừng việc đặt hàng hoặc chuyển vào tồn kho sử dụng cho đến khi bộ phận thiết kế/chất lượng xác nhận phù hợp. Nếu người phê duyệt vắng mặt, kiểm tra quy trình phê duyệt thay thế hoặc chuyển cấp.
• Thay đổi thời hạn giao hàng của nhà cung cấp: Khi có thay đổi sau khi đặt hàng, xác định hệ thống có cần thông báo và phê duyệt lại không.
• Nhận hàng vượt số lượng/chia nhỏ: Khi giao hàng nhiều lần, đảm bảo đối chiếu đúng giữa PO, phiếu nhận hàng và hóa đơn (3 điểm đối chiếu) (Microsoft Learn, Vendor invoices overview; Microsoft Learn, Accounts payable invoice matching overview).
• Báo giá hết hạn, thử lại API bị trùng lặp: Xử lý khi báo giá hết hạn hoặc lỗi kết nối API, đảm bảo không gửi trùng lặp.
• Xử lý offline, cuối tháng: Lưu yêu cầu khi mất kết nối mạng, tự động thông báo các trường hợp chưa xử lý vào cuối tháng.
• Xử lý hủy đơn hàng: Đảm bảo việc hủy đơn sau phê duyệt được ghi nhận và thông báo đúng quy trình.

Tiêu chí nghiệm thu là “quy trình nghiệp vụ mong đợi được tái hiện trên hệ thống và các bên liên quan xác nhận thao tác, kết quả”. Các chỉ tiêu về thời gian xử lý nên lấy từ thực tế nhà máy, và trong mỗi lần kiểm thử cần xác nhận tính tái hiện của quy trình nghiệp vụ.

FAT: Tái hiện quy tắc phê duyệt và thay đổi dữ liệu trên bàn giấy

Trong FAT (kiểm thử trước khi xuất xưởng), chuẩn bị dữ liệu kiểm thử đã ẩn danh mã vật tư thực tế, bảng quyền hạn, danh mục nhà cung cấp, tồn kho và phiên bản báo giá. Đầu tiên chạy thử quy trình thông thường, sau đó chỉ thay đổi thời điểm thiếu hàng của cùng mã vật tư để kiểm tra mức độ khẩn cấp có thay đổi không. Tiếp theo, lần lượt đưa vào các trường hợp vắng mặt người phê duyệt, vượt hạn mức, cùng một người nộp và phê duyệt, nhà cung cấp chưa được phê duyệt, báo giá hết hạn. Điều kiện đạt không chỉ là “có lỗi” mà phải xác định được điều kiện nào đã chặn quy trình, được chuyển lại cho ai, cả báo giá gốc và phiên bản nộp lại có còn lưu không, thông báo đặt hàng đã phát ra chưa, tất cả phải kiểm tra trên giao diện và log. Cũng cần thử trường hợp trả lại yêu cầu đã phê duyệt để đảm bảo không thể dùng lại phê duyệt cũ cho điều kiện mới.

Khi kiểm thử tạo PO, cố ý gửi lại cùng một yêu cầu API để xác nhận chỉ phát hành một số PO duy nhất. Nếu phản hồi bị timeout, hệ thống không được coi là “thất bại” ngay mà phải có thể truy vấn kết quả bằng ID yêu cầu gốc. Việc thay đổi số lượng, giá, nhà cung cấp, hủy PO đã đặt phải tách thành các kịch bản riêng, đối chiếu phiên bản trước/sau, điều kiện cần phê duyệt lại, thông báo lại cho nhà cung cấp. Cũng cần xác nhận việc chỉ thay đổi ngày giao hàng hoặc chia nhỏ giao hàng của PO hiện có không bị tính nhầm thành đơn hàng khẩn cấp mới. Kết quả kiểm thử phải kèm dữ liệu đầu vào, trạng thái chuyển đổi mong đợi, giao diện thực tế, thông điệp tích hợp và người đánh giá.

SAT: Kiểm tra tình huống lệch thứ tự vật tư và thông tin

Trong SAT (kiểm thử tiếp nhận tại hiện trường), các nhân viên kho, mua hàng, chất lượng, sản xuất, kế toán cùng theo dõi các trường hợp kiểm thử giống nhau. Thử nghiệm các tình huống như: hàng thay thế đến trước nhưng chưa được chuyển vào tồn kho sử dụng trước khi kiểm tra chất lượng xong; hóa đơn giao hàng đến trước nhưng PO liên kết bị chậm thì để ở trạng thái chờ đối chiếu tạm thời; quét cùng một thùng hai lần không làm tăng gấp đôi số lượng nhận. Khi giao hàng chia nhỏ, cần tách số lượng và lô của từng chuyến, nếu hóa đơn gộp thì vẫn phải liên kết với từng dòng nhận hàng. Nếu nhận thừa số lượng, cần xác định trước sẽ dừng nhận hay yêu cầu phê duyệt ngoại lệ, tránh để lại quyết định ngầm tại hiện trường.

Trong quá trình thử nghiệm, không chỉ kiểm tra giao diện trước/sau đặt hàng mà còn đối chiếu thực tế trên kệ, vị trí chờ, số dư sổ sách. Nếu nhà cung cấp báo trễ giao hàng ngay sau khi phát hành PO, cần tính lại dự báo dừng chuyền không chỉ dựa vào ETA mà còn để bộ phận sản xuất xem xét phương án thay thế. Nếu cuối tháng còn PO chưa nhận hoặc chưa xuất hóa đơn, cần lập danh sách công khai cho kế toán và quy trình đối chiếu lại vào tháng sau. Khi số liệu thực tế và sổ sách lệch nhau, cần truy vết được sự kiện nào chưa gửi, bị trùng hoặc chờ hủy trước khi hiện trường tự điều chỉnh số lượng. Việc xác nhận nhập hàng phải đảm bảo nhân viên có thể tái hiện theo hướng dẫn, chủ sở hữu ngoại lệ và thời hạn xử lý phải rõ ràng.

Khi chuyển sang vận hành chính thức, không bỏ sót các trường hợp chưa hoàn thành

Khi chuyển từ thử nghiệm sang vận hành chính thức, không nhất thiết phải chuyển toàn bộ các trường hợp sang hệ thống mới cùng lúc. Tuy nhiên, cần liệt kê theo trạng thái từng trường hợp đã tạo yêu cầu nhưng chưa phê duyệt, đã phê duyệt nhưng chưa đặt hàng, đã đặt hàng nhưng chưa nhận, đang giao hàng chia nhỏ, đang chờ kiểm tra chất lượng, chưa xuất hóa đơn, và quyết định từng trường hợp sẽ hoàn tất ở hệ thống nào. Liên kết số cũ và số mới, đảm bảo không gửi PO trùng cho nhà cung cấp. Trong kỳ đối chiếu tháng đầu sau chuyển đổi, cần đối chiếu mã chi phí khẩn cấp, chênh lệch nhận hàng, các trường hợp nhận tạm chưa đối chiếu giữa bộ phận mua hàng, kho và kế toán.

Trong vài tuần đầu, không chỉ ghi nhận thời gian chờ phê duyệt mà còn lý do bị trả lại giữa chừng, lý do phải chuyển sang gọi điện/chat. Nếu nhập liệu trên giao diện quá lâu, trước khi bỏ bớt trường bắt buộc, hãy tìm các trường có thể tự động điền từ số thiết bị hoặc mã vật tư. Nếu phê duyệt chậm, không nên nới lỏng ngưỡng một cách đồng loạt mà phải xem bị tắc ở điều kiện rủi ro nào. Cũng cần kiểm tra trên cùng dashboard xem việc bỏ qua kiểm tra chất lượng có làm nhanh hơn không, hay các đối chiếu kế toán chưa xử lý bị dồn về sau. Nếu luồng khẩn cấp bị biến thành lối tắt cho luồng thường, cần rà soát lại căn cứ và tỷ lệ ngoại lệ của mức độ khẩn cấp, đảm bảo quyết định trước khi đặt hàng luôn có thể giải trình tại hiện trường.

KPI đo lường hiệu quả và đánh giá khi thất bại

Để đánh giá khách quan hiệu quả triển khai hệ thống, cần thiết lập các KPI (Chỉ số đánh giá hiệu quả chính) sau:

• Thời gian phê duyệt (Approval Lead Time): Thời gian từ khi đề xuất mua hàng đến khi phê duyệt cuối cùng, đo riêng cho trường hợp khẩn cấp và thông thường.
• Thời gian dừng máy do chậm mua sắm: Ghi nhận thời gian thiết bị dừng do chậm trễ mua vật tư, phụ tùng.
• Tỷ lệ phát sinh ngoại lệ: Số lượng trường hợp thiếu phê duyệt, đặt hàng chưa phê duyệt, đặt nhầm, đặt trùng lặp.
• Chi phí mua sắm khẩn cấp vượt chuẩn: Số lần và số tiền phát sinh chi phí mua khẩn cấp vượt định mức.
• Chênh lệch đối chiếu ba điểm: Số trường hợp không khớp về giá trị/số lượng giữa PO, nhận hàng, hóa đơn (Microsoft Learn, Accounts payable invoice matching overview).
• Tuổi thọ các trường hợp chưa xử lý: Phân bố số ngày các trường hợp chưa phê duyệt, chưa nhận hàng, chưa thanh toán.
• Tính đầy đủ dữ liệu: Đảm bảo mỗi trường hợp mua hàng có đầy đủ tệp đính kèm, chứng từ, lưu vết kiểm toán.

Các KPI này cần được so sánh cùng phạm vi, cùng thời gian trước và sau khi triển khai để định lượng mức cải thiện nghiệp vụ. Nếu thất bại hoặc không đạt mục tiêu, cần thực hiện phân tích nguyên nhân gốc rễ (Root Cause Analysis), ví dụ: “người phê duyệt thường xuyên vắng mặt”, “quy trình khẩn cấp vận hành sai”, “lỗi tích hợp API không được phát hiện”, từ đó xác định vấn đề thuộc quy trình, vận hành hay hệ thống và đề xuất biện pháp phòng ngừa tái diễn.

Câu hỏi thường gặp

Chi phí triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy là bao nhiêu?

Chi phí triển khai phụ thuộc lớn vào phạm vi tích hợp với hệ thống hiện có, số lượng người dùng, yêu cầu tùy chỉnh, và mức độ hỗ trợ tại chỗ. Nếu sử dụng mô hình cloud, có thể giảm chi phí đầu tư ban đầu và trả phí hàng tháng, nhưng nếu cần triển khai on-premise hoặc thiết kế quy trình phê duyệt phức tạp sẽ phát sinh thêm chi phí. Cần làm rõ yêu cầu ngay từ giai đoạn RFP và lấy báo giá từ nhiều nhà cung cấp.

Chỉ dùng ERP có đáp ứng được phê duyệt mua hàng khẩn cấp không?

Các ERP lớn (ví dụ: Microsoft Dynamics 365, Oracle Fusion Cloud, v.v.) đều có sẵn chức năng quy trình đề xuất và phê duyệt mua hàng, nhưng các quy trình đặc thù cho mua hàng khẩn cấp (ví dụ: đặt trước số PO, điều kiện bỏ qua phê duyệt, phê duyệt thay thế, chính sách lưu trữ tệp đính kèm, v.v.) có thể cần cấu hình bổ sung hoặc mở rộng (Microsoft Learn, Purchase requisition workflow; Oracle Fusion Cloud Procurement, Using Procurement). Việc xác định yêu cầu sát với thực tế vận hành là rất quan trọng.

Loại yêu cầu mua khẩn cấp khác gì yêu cầu thông thường gắn cờ ưu tiên gấp?

Phân loại mức độ ưu tiên trong doanh nghiệp cần quy định riêng. Trong ví dụ Oracle, ’emergency requisition’ là một loại yêu cầu mua đặc biệt có thể đặt trước số PO khi gửi; yêu cầu mua thông thường chỉ gắn cờ xử lý gấp ‘urgent’ không có tính năng đặt trước số PO. Vì vậy phải xác định rõ loại yêu cầu, luồng phê duyệt, thời điểm phát hành PO và quyền hạn, thay vì dựa vào hai từ gần nghĩa.

Có thể phát hành PO trước khi phê duyệt không?

Trong Oracle Fusion Cloud Procurement, bạn có thể đặt trước số PO khi gửi yêu cầu mua khẩn cấp, nhưng việc đặt trước số và phát hành PO đã được phê duyệt là hai trạng thái khác nhau (Oracle Fusion Cloud Procurement, Using Procurement). Việc có thể cam kết đặt hàng với nhà cung cấp trước khi phê duyệt hay không không chỉ phụ thuộc vào cài đặt sản phẩm mà còn vào quy định về thẩm quyền của công ty bạn. Không nên coi việc có số PO là bằng chứng đã được phê duyệt; hãy ghi nhận riêng thời điểm gửi cho nhà cung cấp và lịch sử phê duyệt.

Nếu phụ tùng thay thế chưa được phê duyệt thì xử lý thế nào?

Đối với phụ tùng thay thế chưa được phê duyệt, cần thiết kế để dừng việc đặt hàng hoặc chuyển vào tồn kho sử dụng cho đến khi xác nhận phù hợp. Nếu người phê duyệt vắng mặt, cần có quy trình phê duyệt thay thế hoặc chuyển cấp. Nếu vẫn tiếp tục mà chưa được phê duyệt, có nguy cơ phát sinh lỗi đối chiếu hoặc giữ lại thanh toán ở các bước sau (nhận hàng, xử lý hóa đơn).

Xử lý nhận hàng và hóa đơn như thế nào?

Sau khi ghi nhận nhận hàng, hệ thống sẽ đối chiếu PO, phiếu nhận hàng và hóa đơn theo quy trình đã thiết lập. Khi giao hàng chia nhỏ hoặc vượt số lượng, hệ thống vẫn cho phép nhận từng phần và quản lý chênh lệch (Microsoft Learn, Vendor invoices overview). Khi xử lý hóa đơn, hệ thống tự động kiểm tra khớp giá và số lượng với PO, nếu không khớp sẽ chuyển sang quy trình xử lý ngoại lệ (Microsoft Learn, Accounts payable invoice matching overview).

Tổng kết

Việc triển khai hệ thống phê duyệt mua hàng khẩn cấp cho nhà máy tại các doanh nghiệp sản xuất ở Thái Lan cần xác định rõ yêu cầu chức năng, phi chức năng, tối ưu hóa vận hành thực tế thông qua thử nghiệm từng bước và kiểm thử nghiệm thu. Đo lường hiệu quả bằng KPI và liên tục cải tiến dựa trên đánh giá thất bại là chìa khóa để hệ thống thực sự phát huy hiệu quả và bền vững.

Nếu bạn cần tư vấn về triển khai hệ thống, xác định yêu cầu, hoặc đánh giá mức độ phù hợp với vận hành thực tế tại địa phương, vui lòng liên hệ. Chúng tôi có thể hỗ trợ bạn xác định tiêu chí mua hàng khẩn cấp và quy trình phê duyệt phù hợp với ERP và quy trình hiện trường của bạn.

Thông tin tham khảo

• Microsoft Learn, Purchase requisition workflow
• Oracle Fusion Cloud Procurement, Using Procurement
• Oracle Fusion Cloud Procurement, Using Procurement
• Microsoft Learn, Vendor invoices overview
• Microsoft Learn, Accounts payable invoice matching overview
• GS1, Global Traceability Standard