Khi đưa việc quản lý đặt hàng trước các linh kiện có thời gian giao hàng dài lên hệ thống trong ngành sản xuất, điều đầu tiên cần quyết định không phải là “nút đặt hàng sớm”. Mà là quy trình xác định ai sẽ đặt nhu cầu tạm thời dựa trên cơ sở nào khi thiết kế hoặc BOM chưa được chốt, phạm vi cam kết với nhà cung cấp đến đâu, và ai sẽ chịu chi phí khi thay đổi hoặc hủy bỏ. Nếu kết nối MRP và mua hàng mà bỏ qua điểm này, bạn sẽ tạo ra đặt hàng trùng lặp hoặc tồn kho ứ đọng dù nghĩ rằng đã tránh được thiếu hàng. Bài viết này dành cho các cán bộ lựa chọn và triển khai hệ thống tại nhà máy ở Thái Lan và ASEAN, tổng hợp các bước từ thiết kế nghiệp vụ, RFP, đến FAT/SAT theo từng đơn vị công việc thực tế.
Tại sao chỉ riêng linh kiện có thời gian giao hàng dài không thể chờ BOM chốt?
Thông thường, sau khi chốt thông số kỹ thuật sản phẩm, phê duyệt BOM, tính toán nhu cầu bằng MRP rồi chuyển sang yêu cầu mua hàng là trình tự hợp lý đối với các linh kiện thông thường. Tuy nhiên, với các linh kiện mà thời gian từ đặt hàng đến nghiệm thu còn dài hơn cả thời hạn giao hàng cho khách – như thiết bị điều khiển nhập khẩu, vật liệu khuôn chuyên dụng, vật đúc đặt riêng, linh kiện điện tử đặc biệt – nếu tuân thủ trình tự này thì ngay khi bắt đầu cũng đã không kịp tiến độ. Do đó, đặt hàng trước không phải là “lối tắt” ngoại lệ, mà là đối tượng quản lý cần được xử lý minh bạch khi thiết kế chưa chốt.
Điều quan trọng ở đây là phải tách biệt giữa “chuẩn bị trước” và “phát hành đơn đặt hàng có tính ràng buộc”. Ban đầu, chỉ cần hỏi thời gian giao hàng với nhà cung cấp, trao đổi về năng lực sản xuất, lấy báo giá là đủ. Sau đó, tiến tới đặt chỗ có thể hủy, giữ nguyên vật liệu, rồi mới đến đặt hàng chính thức. Ở mỗi giai đoạn, mức độ ràng buộc hợp đồng, thời hạn hủy, và giới hạn chi phí sẽ khác nhau. Nếu trên màn hình hệ thống tất cả đều hiển thị là “đang đặt hàng”, người phê duyệt sẽ không thể đánh giá đúng rủi ro thực tế.
Tại các nhà máy ở Thái Lan, còn có các yếu tố như thông quan hàng nhập khẩu, ngày nghỉ địa phương, năng lực sản xuất của nhà cung cấp, chênh lệch múi giờ và quy trình phê duyệt qua lại với trụ sở chính tại Nhật Bản. Nếu gom tất cả lại thành một số ngày an toàn cố định, sẽ có mặt hàng quá ngắn và mặt hàng quá dài. Điều cần thiết là ngoài việc rà soát lại lead time mua hàng, còn phải trực quan hóa mức độ chắc chắn của thiết kế và mức độ ràng buộc của đơn đặt hàng trên các trục khác nhau. BOI Thái Lan cũng hỗ trợ đầu tư cho việc hình thành chuỗi cung ứng điện tử, cơ khí, v.v., nhưng điều đó không đảm bảo rút ngắn thời gian giao hàng cho từng linh kiện. Thời gian giao hàng phải được quản lý dựa trên số liệu thực tế của từng mặt hàng và từng nhà cung cấp.
Chia quy trình đặt hàng trước thành 4 giai đoạn: “Nhu cầu tạm thời”, “Phê duyệt”, “Cam kết đối ngoại”, “Chỉ thị chính thức”
Để tránh dồn toàn bộ nghiệp vụ vào một cờ đặt hàng duy nhất, trạng thái được chia thành bốn giai đoạn. Giai đoạn đầu tiên là nhu cầu tạm thời do bộ phận thiết kế hoặc kinh doanh khởi tạo. Tại đây, cần ghi lại thông tin về dự án liên quan, mã sản phẩm dự kiến, thời điểm cần thiết, số lượng ước tính, phiên bản thiết kế và mức độ xác thực. Giai đoạn thứ hai là phê duyệt nội bộ cho quyết định đặt hàng trước. Người có quyền duyệt ngân sách sẽ xác định giới hạn, bao gồm cả khả năng thay thế và chi phí hủy bỏ. Giai đoạn thứ ba là cam kết đối ngoại với nhà cung cấp. Cần phân biệt giữa báo giá, đặt trước hạn mức, thông báo dự kiến và đơn đặt hàng chính thức, đồng thời lưu lại nội dung và ngày tháng mà đối tác đã xác nhận. Giai đoạn thứ tư là chuyển đổi sang chỉ thị chính thức sau khi thiết kế được xác nhận. BOM đã chốt, nhu cầu MRP, yêu cầu mua hàng và dòng PO sẽ được liên kết bằng cùng một khóa tham chiếu.
Phân loại này không phải là tên trạng thái tiêu chuẩn của một sản phẩm cụ thể, mà là một ví dụ về thiết kế nghiệp vụ được quyết định khi triển khai hệ thống. Theo tài liệu của SAP, khi chuyển đổi lệnh kế hoạch sang yêu cầu mua hàng, yêu cầu đó sẽ không tự động thay đổi trong các bước thực hiện kế hoạch tiếp theo. Trong tài liệu của Microsoft Dynamics 365, các thao tác như phê duyệt và xác nhận lệnh kế hoạch, yêu cầu mua hàng, phê duyệt PO được trình bày là các thao tác riêng biệt. Hành vi thực tế sẽ phụ thuộc vào sản phẩm và thiết lập được sử dụng, do đó trong RFP cần xác nhận “trạng thái nào sẽ được tính vào nguồn cung của MRP”.
Khóa chính của sổ cái đặt hàng trước không chỉ đơn giản là mã sản phẩm. Cần có ID dự án, ID dòng nhu cầu, mã sản phẩm dự kiến hoặc ID thông số kỹ thuật, phiên bản thiết kế, ngày cần thiết, nhà cung cấp, số lượng và trạng thái. Nếu mã sản phẩm chính thức chưa được cấp, hãy phát hành ID tạm thời và lưu lại lịch sử kể cả khi sau này thay thế bằng mã sản phẩm chính thức. Nếu xóa ID dòng nhu cầu và tạo dòng mới, sẽ không thể phát hiện sự trùng lặp giữa thông báo dự kiến cũ và đề xuất MRP mới.
Cách tạo nhu cầu tạm thời khi thiết kế chưa xác nhận
Nhu cầu tạm thời không phải là bản sao của đơn hàng đã xác nhận. Cần ghi lại cơ sở của nhu cầu như dự án của khách hàng, kết quả thử nghiệm, bản vẽ tạm thời hay sản xuất dự kiến, đồng thời gắn mức độ xác thực. Không nên chỉ dựa vào con số như “70%” để đánh giá mức độ xác thực. Nếu có thêm các trường riêng biệt ghi lại mục nào trong bản vẽ chưa xác nhận, có ứng viên thay thế hay không, khi nào sẽ được quyết định, thì sau này có thể giải thích lý do tăng số lượng. Kỹ sư thiết kế sẽ đánh giá mức độ xác thực, bộ phận kinh doanh sẽ chỉ ra khả năng thành công của dự án, bộ phận mua hàng sẽ chỉ ra ngày có thể cung ứng. Ba bên nhập liệu riêng biệt và so sánh trên cùng một màn hình, không trộn lẫn dữ liệu.
Nhu cầu nên được chia thành ít nhất ba loại. ① Gắn với đơn hàng đã xác nhận nhưng chỉ chưa xác định thông số linh kiện, ② Dựa trên thông báo dự kiến từ khách hàng, ③ Chỉ dựa trên dự báo bán hàng nội bộ. Loại ① có mức độ ưu tiên cao về đảm bảo tiến độ giao hàng, loại ③ có rủi ro tồn kho lớn. Tuy nhiên, nếu là sản phẩm tiêu chuẩn có thể chuyển đổi mục đích sử dụng thì rủi ro sẽ giảm. Do đó, không nên quyết định đặt hàng chỉ dựa vào mức độ xác thực, mà cần kết hợp cả khả năng chuyển đổi và điều kiện hủy bỏ.
Ví dụ, cần 100 chiếc, khả năng áp dụng phương án A cao nhưng phiên bản thiết kế chưa được phê duyệt, thời gian mua tiêu chuẩn của nhà cung cấp là 16 tuần, còn lại 12 tuần để giao cho khách hàng. Chênh lệch 4 tuần này không đủ để biện minh cho việc phát hành PO ngay cho 100 chiếc. Cần xác nhận có thể giữ chỗ cho 50 chiếc với điều kiện có thể hủy, có thể chuyển sang phương án B hay không, quyết định thiết kế sẽ có trong 2 tuần hay không. Các con số nêu trên chỉ là giả định minh họa, không phải thời gian lead time hay mức tồn kho khuyến nghị chung.
Các mục tối thiểu cần có trong nhu cầu tạm thời bao gồm: mã dự án và nhu cầu, sản phẩm và linh kiện dự kiến, bản vẽ tạm thời hoặc phiên bản BOM, ngày cần thiết, khoảng số lượng, cơ sở xác thực, ngày dự kiến xác nhận thiết kế, sản phẩm thay thế, khả năng chuyển đổi tồn kho, điều kiện mua lại/hủy bỏ, ngày rà soát tiếp theo. Có thể ghi nhận bằng Excel. Tuy nhiên, nếu ghi đè phiên bản, phê duyệt qua email bị phân tán, nhập liệu trùng lặp vào hệ thống MRP, sẽ không thể truy vết số liệu nào đã dẫn đến cam kết đối ngoại. Khi đánh giá hiệu quả triển khai, cần đánh giá khả năng truy vết này chứ không phải số lượng màn hình nhập liệu.
Tính toán cần trình bày cho người phê duyệt khi đặt trước các linh kiện có thời gian giao hàng dài
Trên màn hình phê duyệt, chỉ hiển thị cảnh báo màu đỏ “có thể thiếu hàng” là chưa đủ. Điều cần thiết cho quyết định là phải so sánh được tổn thất do chậm trễ khi chờ đợi và tổn thất do hủy bỏ hoặc tồn kho khi cam kết đặt trước, bằng cùng một đơn vị đo lường. Nếu giá dự toán, tiền đặt cọc, phí hủy đơn, nghĩa vụ nhận hàng khác nhau, cần trình bày riêng biệt từng khoản. Đối với các trường hợp không thể dự đoán chính xác số tiền tổn thất, nên trình bày khoảng giá trị và căn cứ, đồng thời giữ nguyên các yếu tố chưa biết để giúp ra quyết định tốt hơn.
Ví dụ, trên thẻ phê duyệt, hãy liệt kê ngày khách hàng cần hàng, ngày giao hàng sớm nhất hiện tại, số ngày chênh lệch, số lượng tối thiểu/tối đa cần thiết, số lượng còn lại của PO hiện có, tồn kho khả dụng, số lượng có thể đặt trước, hạn chót hủy đơn, tổn thất tối đa, khả năng thay thế. Đối tượng phê duyệt không chỉ là “có thể đặt hàng” mà còn phải xác định rõ “đặt bao nhiêu, cho nhà cung cấp nào, với mức cam kết nào, trước thời hạn nào”. Bộ phận kế toán/quản lý kinh doanh xác nhận giới hạn số tiền, bộ phận thiết kế xác nhận tính tương thích kỹ thuật, bộ phận mua hàng xác nhận điều kiện cung ứng/hợp đồng. Nếu số lượng hoặc thông số kỹ thuật thay đổi vượt ngưỡng sau khi phê duyệt, cần yêu cầu phê duyệt lại.
Quyền phê duyệt phải phù hợp với quy định tổ chức. Không nên lấy các mức tiền hoặc chức danh trong bài viết làm tiêu chuẩn chung cho mọi doanh nghiệp. Tại hiện trường, thay vì rút ngắn quy trình như “số tiền nhỏ không cần trưởng phòng phê duyệt”, điều quan trọng là phải có cơ chế theo dõi tổng số tiền không thể hủy của từng dự án. Dù một lần phê duyệt có giá trị nhỏ, tổng số tiền đặt trước cho nhiều nhà cung cấp trong cùng một dự án có thể vượt ngân sách. Hệ thống cần tổng hợp số tiền cam kết theo cả dự án và từng mã hàng, đồng thời hiển thị hạn mức còn lại trước và sau phê duyệt.
Theo tài liệu công khai của Microsoft Dynamics 365, khi kích hoạt quản lý thay đổi PO, đơn đặt hàng sẽ đi qua quy trình phê duyệt từ bản nháp, và các thay đổi đối với PO đã phê duyệt sẽ được xử lý qua yêu cầu thay đổi hoặc quy tắc phê duyệt lại. Ngoài ra, trạng thái phê duyệt của PO được xác nhận từ lệnh kế hoạch cũng có các ngoại lệ về mặt cài đặt. Do có những hành vi đặc thù theo từng sản phẩm như vậy, không nên chỉ nghe “có chức năng phê duyệt tiêu chuẩn” mà cho rằng đã đáp ứng đủ yêu cầu. Cần kiểm chứng bằng dữ liệu mẫu xem quy trình phê duyệt mong muốn cho các trường hợp nhu cầu giả định có thực sự khả thi hay không.
Xác định trước trách nhiệm chi phí khi thay đổi hoặc hủy đơn
Thay đổi thiết kế không phải là ngoại lệ đối với đặt hàng trước, mà là một nhánh thông thường cần dự liệu ngay từ đầu. Cần định nghĩa rõ cho từng mã hàng rằng khi nào cần báo giá lại nếu thay đổi kích thước, vật liệu, điều kiện chứng nhận, số lượng, hoặc thời hạn giao hàng. Đơn xin thay đổi phải kèm theo so sánh giữa phiên bản cũ và mới, ảnh hưởng đến các đơn đã đặt, hàng đang sản xuất, tồn kho, khả năng chuyển đổi sang mã thay thế, và khả năng chuyển chi phí cho khách hàng. Tài liệu quản lý thay đổi thiết kế của Microsoft cũng tách biệt giữa yêu cầu thay đổi và lệnh thay đổi, đồng thời kiểm tra ảnh hưởng đến các giao dịch hiện có bao gồm cả đơn mua hàng. Không nên áp dụng nguyên xi các quy tắc này cho doanh nghiệp mình, mà chỉ nên tham khảo về các loại bằng chứng cần thiết.
Nếu chỉ đơn giản đẩy trách nhiệm chi phí cho “bộ phận gây ra”, quyết định sẽ bị chậm trễ. Ngay khi phê duyệt đặt hàng trước, cần xác định giới hạn nhận trách nhiệm của bộ phận kinh doanh, điều khoản chia sẻ chi phí với khách hàng, và điều kiện phê duyệt lại khi thay đổi thiết kế. Khi thay đổi đã xác nhận, cần kiểm tra với nhà cung cấp về số lượng có thể hủy, phí hủy, xử lý hàng đang sản xuất, và khả năng chuyển đổi sang mã khác. Việc phân loại chi phí và trích lập dự phòng phụ thuộc vào chính sách kế toán của công ty, không nên tự động quyết định chỉ dựa vào hệ thống mua hàng.
Trước khi ghi nhận “đã hủy”, cần lưu lại ai đã thông báo cho nhà cung cấp và nhà cung cấp đã xác nhận những gì. Việc đặt số lượng còn lại về 0 trên màn hình PO không chứng minh được rằng phía đối tác đã dừng sản xuất. Trong tài liệu về PO của Microsoft, nếu đã có số lượng đã nhận hoặc đã xuất hóa đơn, chỉ phần còn lại chưa xử lý mới được phép hủy, và nếu sử dụng quản lý thay đổi thì việc hủy cũng phải qua quy trình phê duyệt. Khi lựa chọn hệ thống, cần kiểm tra xem có thể theo dõi toàn bộ lịch sử gồm thông báo ra ngoài, xác nhận/đồng ý của đối tác, và tính toán số dư nội bộ hay không.
Khi cùng một linh kiện được sử dụng tại nhiều địa điểm, việc chuyển đổi mục đích sử dụng có thể có lợi hơn so với hủy đơn. Do đó, cần kiểm tra không chỉ mã hàng mà còn phiên bản, ngày hiệu lực, điều kiện sử dụng về chất lượng và pháp lý, cũng như chi phí vận chuyển. Khi quyết định chuyển đổi, cần giảm số tiền cam kết của dự án gốc và chuyển nhu cầu sang dự án nhận. Nếu có thể theo dõi ID của cả hai dự án, sẽ tránh được việc ghi nhận chi phí thay đổi hai lần. Nếu hệ thống khó thực hiện chuyển đổi, tối thiểu nên thiết lập khóa tham chiếu liên kết giữa dòng gốc và dòng chuyển đổi.
Ngăn ngừa đặt hàng trùng lặp khi chuyển đổi từ BOM chính thức sang yêu cầu mua hàng MRP
Khi thiết kế đã được hoàn tất và BOM được phê duyệt, MRP sẽ đề xuất nhu cầu vật tư thông thường. Nếu tại thời điểm này không thể tham chiếu đến các đơn đặt hàng (PO) hoặc đặt chỗ đã thực hiện trước đó, sẽ phát sinh yêu cầu mua hàng thứ hai cho cùng một nhu cầu. Do đó, điều kiện tiên quyết khi chuyển đổi là phải có mã định danh để đối chiếu giữa dòng nhu cầu tạm thời và dòng BOM chính thức, đồng thời xác định rõ sẽ trừ đi các cam kết cung ứng hiện có ở bước tính toán nhu cầu hay ở khâu xét duyệt mua hàng.
Trình tự xử lý cơ bản gồm: ① Phê duyệt phiên bản thiết kế, ② Đối chiếu nhu cầu tạm thời với mã hàng và số lượng BOM đã xác nhận, ③ Đối chiếu số lượng đã đặt chỗ, PO còn lại và số lượng đã nhập kho, ④ Chỉ chuyển phần chênh lệch sang MRP hoặc bộ phận mua hàng, ⑤ Đóng dòng nhu cầu tạm thời với trạng thái “đã chuyển sang chỉ thị chính thức”. Nếu cần chuyển đổi một phần, số lượng sẽ được tách theo từng dòng. Ví dụ, nếu trong 100 chiếc nhu cầu tạm thời, 60 chiếc đã xác định là hàng A, 40 chiếc còn lại vẫn là ứng viên B, thì không được đóng toàn bộ 100 chiếc cùng lúc. Chỉ liên kết 60 chiếc đã xác định, còn 40 chiếc chưa xác định cần giữ lại hạn chót để ra quyết định.
Khóa phát hiện đặt hàng trùng lặp không chỉ dựa vào mã hàng. Có trường hợp cùng một mã hàng được sử dụng cho nhiều dự án khác nhau, hoặc ngược lại, khi thay đổi thiết kế thì mã hàng thay đổi nhưng vẫn đáp ứng cùng một nhu cầu. Cần kết hợp các yếu tố như mã dự án, mã dòng nhu cầu, phiên bản thiết kế, tính tương đương của vật tư, ngày cần thiết, mã dòng cung ứng, và xác nhận ngoại lệ bằng con người. Nếu do phản hồi từ nhà cung cấp chậm mà cả đơn báo trước và PO đều còn tồn tại, hệ thống sẽ cảnh báo dựa trên trạng thái và tính ràng buộc. Nếu tự động xóa một phía, sẽ làm mất dấu vết kiểm toán và lịch sử hợp đồng.
Tài liệu của SAP minh họa ví dụ chuyển đổi toàn bộ hoặc một phần từ lệnh kế hoạch sang yêu cầu mua hàng, còn tài liệu của Microsoft giải thích về phê duyệt và lịch sử xác nhận lệnh kế hoạch. Tuy nhiên, chức năng của từng phần mềm không đồng nghĩa với việc “có thể quản lý hoàn toàn việc đặt hàng trước khi thiết kế chưa hoàn tất” theo tiêu chuẩn. Khi triển khai, cần xác nhận thực tế trên hệ thống về tính đồng nhất giữa nhu cầu tạm thời và nhu cầu chính thức, tính toán cung ứng, chuyển đổi từng phần, và khả năng rollback khi có lỗi, bao gồm cả thiết lập và mở rộng. Độ chính xác của dữ liệu master trong MRP là một vấn đề khác, có thể tham khảo thêm tại Tổng hợp về hệ thống MRP và độ chính xác dữ liệu master.
Nên Viết Gì Trong RFP Khi Triển Khai Hệ Thống
Ranh Giới Dữ Liệu Giữa Sổ Theo Dõi Đặt Hàng Trước và ERP
Một trong những điểm dễ phát sinh tranh cãi khi triển khai là xác định nơi lưu trữ chính thức cho nhu cầu tạm thời. Nếu ERP có khả năng lưu BOM chưa phê duyệt hoặc mã hàng tạm thời, có thể lựa chọn sử dụng vùng lập kế hoạch trong ERP. Nếu không, cần thiết lập một sổ theo dõi đặt hàng trước riêng biệt và chỉ chuyển sang yêu cầu mua hàng/PO khi đã được phê duyệt chính thức. Nguyên tắc là không được nhập thủ công cùng một nhu cầu ở nhiều nơi khác nhau. Khi liên kết với các hệ thống khác, cần truyền ID dòng nhu cầu gốc và phiên bản, đồng thời nhận lại số yêu cầu mua hàng, số PO, số phiếu nhập kho làm tham chiếu. Nếu thiết kế theo kiểu “vì đã có trong sổ nên cũng thêm nhu cầu dự báo vào ERP”, có thể dẫn đến việc MRP tính toán hai lần cho cùng một nhu cầu.
Các sự kiện liên kết cần phân biệt giữa tạo mới, phê duyệt, thay đổi, hủy bỏ, chuyển đổi và phải gắn khóa idempotent để tránh tạo trùng tài liệu khi gửi lại. Nếu API bị dừng giữa chừng do sự cố, cần kiểm tra trạng thái đã gửi hay chưa trước khi xử lý lại. Nếu chỉ đơn giản “thực hiện lại” khi có lỗi truyền thông, có thể dẫn đến trùng lặp trong trường hợp PO đã được tạo thành công nhưng chỉ mất phản hồi. Cần đảm bảo người phụ trách mua hàng có thể xem trạng thái này trên màn hình và nếu giải quyết thủ công thì phải lưu lại lịch sử.
Cũng cần xác định rõ ai là chủ sở hữu của master mã hàng. Bộ phận thiết kế quản lý thông số kỹ thuật và phiên bản, mua hàng quản lý nhà cung cấp và điều kiện mua, kho quản lý đơn vị nhập và tồn kho, kế toán quản lý phân loại chi phí. Cần liệt kê rõ thay đổi nào cần thông báo cho bộ phận khác. Nếu chỉ đồng bộ số lượng mà để lẫn lộn các đơn vị như “bộ”, “cái”, “set”, thì 50 của đặt hàng trước và 50 của BOM chính thức chưa chắc đã cùng ý nghĩa. Cần hiển thị chuyển đổi đơn vị, kích thước lô, lượng đặt hàng tối thiểu, số lượng đóng gói trên màn hình đối chiếu.
Đưa Review Ngoại Lệ Hàng Ngày Thành Yêu Cầu Vận Hành
Sau khi triển khai, điều quan trọng là thực hiện review ngoại lệ vào mỗi sáng. Không phải đọc toàn bộ các linh kiện có thời gian giao hàng dài mỗi ngày, mà cần trích xuất các nhu cầu tạm thời đã quá hạn xác nhận thiết kế, các đơn chờ phản hồi từ nhà cung cấp, các đặt chỗ gần đến hạn có thể hủy, các dòng vượt hạn mức phê duyệt do thay đổi số lượng, các dòng còn tồn tại mà chưa chuyển sang BOM chính thức. Gán người phụ trách và ngày đánh giá tiếp theo cho từng ngoại lệ, sau khi đánh giá xong phải ghi lại lý do. Chỉ nhìn số lượng trên dashboard sẽ không thúc đẩy trách nhiệm chi phí có hạn.
Review nên là quyết định ngắn gọn, phối hợp giữa thiết kế, quản lý sản xuất, mua hàng và kinh doanh. Thiết kế cập nhật các điểm chưa xác định và ngày xác nhận, mua hàng cập nhật hạn mức cung ứng và điều kiện hủy, quản lý sản xuất cập nhật thay đổi ngày cần hàng, kinh doanh cập nhật tình trạng xác nhận của khách hàng. Kết quả đánh giá chọn một trong các phương án: tiếp tục, giảm số lượng, xem xét thay thế, chuyển đổi chính thức, hoặc hủy bỏ. Nếu hủy, phải dừng nhu cầu trên ERP, đóng các cam kết với nhà cung cấp, theo dõi đến khi quyết toán chi phí. Tránh để trạng thái “chờ xử lý” vô thời hạn trên màn hình, bắt buộc phải có ngày đánh giá tiếp theo.
Các chỉ số để đo lường vận hành này gồm: số nhu cầu tạm thời quá hạn, số ngày tồn đọng phê duyệt, số ngày trễ phản hồi nhà cung cấp, số dòng đã quá hạn hủy, số ngày từ khi phát sinh đến khi chuyển đổi chính thức. Mục tiêu số liệu thay đổi tùy theo đặc thù linh kiện, nên trước tiên cần thống kê hiện trạng. Việc tìm nguyên nhân tồn đọng ở các trường hợp nổi bật hơn mức trung bình sẽ dễ phát hiện lỗ hổng trong phân định trách nhiệm.
Nếu chỉ liệt kê các chức năng như “yêu cầu mua hàng, phê duyệt, đơn đặt hàng, nhập kho” trong RFP thì sẽ bỏ sót các điểm khó của dự án này. Thay vào đó, cần cung cấp cho nhà cung cấp kịch bản trạng thái và ngoại lệ. Ví dụ: tạo nhu cầu tạm thời từ BOM chưa xác định, phê duyệt đặt chỗ, nhận phản hồi có điều kiện từ nhà cung cấp, thay đổi thiết kế, hủy một phần, chuyển đổi sang BOM chính thức, chạy lại MRP. Yêu cầu nhà cung cấp giải thích sự thay đổi về số lượng, hạn mức ràng buộc, tính vào cung ứng, lịch sử phê duyệt, tài liệu đối ngoại trước và sau các thao tác này.
Các mục tối thiểu trong RFP gồm: liên kết giữa ID tạm thời và mã hàng chính thức, phiên bản BOM và ngày hiệu lực, dải số lượng theo từng dự án, phân biệt đặt chỗ có điều kiện, forecast, PO, hạn hủy và giới hạn chi phí, phê duyệt theo quyền hạn, phân tích ảnh hưởng thay đổi, truy xuất PO còn lại, tồn kho, WIP, tính vào cung ứng cho MRP, chuyển đổi một phần, cảnh báo đặt hàng trùng, log kiểm toán, bằng chứng thông báo cho nhà cung cấp, giao diện và thông báo bằng tiếng Thái, Anh, Nhật, liên kết API hoặc file với ERP hiện tại. Không nhất thiết phải triển khai tất cả các mục này ngay từ đầu. Trước tiên cần xác định rõ ở đâu trong hệ thống hiện tại sẽ quyết định và chuyển sự kiện đi đâu.
Yêu cầu nhà cung cấp trả lời rõ ràng phân biệt giữa “hỗ trợ tiêu chuẩn”, “tùy biến”, “xử lý bằng vận hành”. Nếu là hỗ trợ tiêu chuẩn thì trình bày giao diện và cấu trúc dữ liệu, nếu là tùy biến thì báo giá phát triển và trách nhiệm bảo trì, nếu xử lý bằng vận hành thì ai sẽ ghi nhận và ghi nhận những gì. Nếu điều kiện tính vào cung ứng chưa rõ ràng, MRP có thể coi đặt chỗ như tồn kho thực tế, dẫn đến cảnh báo thiếu hàng biến mất dù chưa có hàng thật. Nhu cầu tạm thời chưa xác định thiết kế về nguyên tắc không phải là tồn kho chính thức. Trạng thái nào được coi là cung ứng trong kế hoạch cần được cố định bằng test case.
Nếu chuẩn hóa phạm vi quản lý đơn hàng, mua hàng, MRP hiện tại trước, sẽ dễ viết ranh giới trách nhiệm trong RFP hơn. Bài viết này bổ sung thêm hai điểm: “chuyển đổi từ đặt hàng trước sang chỉ thị chính thức” và “trách nhiệm chi phí khi thay đổi”.
Các kịch bản kiểm thử cần thực hiện trong FAT/SAT
Trong FAT, không chỉ kiểm tra xem màn hình có thể lưu được hay không mà còn phải xác nhận dữ liệu có bị mâu thuẫn khi xảy ra ngoại lệ hay không. Tạo một trường hợp thử nghiệm, đặt các giá trị minh họa như nhu cầu tạm thời 100 chiếc, đã đặt trước 60 chiếc, số lượng cần thiết sau khi xác nhận là 80 chiếc, và đã nhập kho 20 chiếc. Khi tính toán lại MRP tại đây, so sánh số lượng chênh lệch được đề xuất với giá trị kỳ vọng. Kết quả sẽ thay đổi tùy theo điều kiện xem đặt trước là nguồn cung cấp – là “đã xác nhận với nhà cung cấp” hay chỉ “được phê duyệt nội bộ”, vì vậy cần ghi rõ giá trị kỳ vọng trước.
Tiếp theo, thay đổi phiên bản thiết kế và thử trường hợp chỉ 30 trong số 60 chiếc có thể chuyển sang phiên bản mới. Kiểm tra xem số dư PO của phiên bản cũ, phí hủy, số lượng có thể chuyển đổi, số lượng bổ sung cần thiết có được hiển thị riêng biệt hay không. Ngay cả khi thực hiện lại MRP trong quá trình phê duyệt hủy, kiểm tra xem nhu cầu tạm thời có bị khôi phục và phát sinh PO kép hay không. Cũng cần kiểm tra xem nhân viên không có quyền có thể bỏ qua phê duyệt hay không, khi người phê duyệt vắng mặt thì cài đặt đại diện có được ghi lại trong lịch sử hay không, và số liệu trên tài liệu sửa đổi gửi cho nhà cung cấp có khớp với màn hình nội bộ hay không.
SAT được thực hiện với mã hàng thực tế của nhà máy Thái Lan, phản hồi từ nhà cung cấp, ngày nghỉ, tiền tệ, hệ thống phê duyệt và mạng thực tế. Ngay cả khi liên kết dữ liệu thông qua dữ liệu mẫu thành công, tại hiện trường có thể thất bại do sự khác biệt về số ký tự mã hàng, ký hiệu phiên bản, chuyển đổi đơn vị, hoặc biến thể tên tiếng Thái. Cần xác nhận rằng các danh sách mà bộ phận mua hàng sử dụng hàng ngày hiển thị các mục như thiết kế chưa xác định, chờ phản hồi, sắp đến hạn hủy, chưa chuyển đổi sang lệnh chính thức, và quy trình rà soát hàng ngày được thực hiện. FAT là bằng chứng hệ thống hoạt động đúng như thiết kế, còn SAT là bằng chứng hiện trường có thể hoàn thành công việc với thiết kế đó.
Đo lường hiệu quả chi phí bằng tiêu chí nào
Chỉ số “phát hành đơn đặt hàng nhanh hơn bao nhiêu phút” không đủ để đánh giá giá trị của hệ thống đặt hàng trước. Các chỉ số cần theo dõi gồm: số lượng trường hợp giao hàng trễ do linh kiện có thời gian giao hàng dài, chi phí hủy và tồn đọng sau thay đổi thiết kế, số lượng PO trùng lặp cho cùng một nhu cầu, số lượng nhu cầu tạm thời chưa chuyển đổi, thời gian đến khi phê duyệt, thời gian đến khi xác nhận với nhà cung cấp. Nếu có thể lấy số liệu chuẩn trong 3-6 tháng trước khi triển khai với cùng định nghĩa, việc so sánh sẽ dễ dàng hơn. Nếu không thể lấy, hãy tạo một đường cơ sở riêng cho giai đoạn thử nghiệm và không nên ước đoán tỷ lệ cải thiện.
Việc quy đổi thành tiền có giới hạn. Ảnh hưởng đến khách hàng do giao hàng trễ thay đổi tùy hợp đồng hoặc sản xuất thay thế, và tổn thất do tồn kho dư cũng khác biệt lớn tùy khả năng chuyển đổi. Trong phê duyệt đầu tư, cần tách biệt các khoản có thể đếm chính xác như phí hủy, chi phí vận chuyển khẩn cấp, dư thừa do PO trùng lặp với các khoản ước tính như mất cơ hội. Nếu ghi rõ nguồn số liệu, thời gian, đối tượng mặt hàng, khả năng kiểm chứng sau triển khai sẽ tăng lên.
Cần đưa cả gánh nặng vận hành tại hiện trường vào đánh giá hiệu quả. Một hệ thống yêu cầu bộ phận thiết kế cập nhật nhu cầu tạm thời hàng ngày sẽ không thể duy trì lâu dài. Thay vào đó, chỉ cập nhật chênh lệch khi có thay đổi, tự động thông báo khi đến hạn hoặc nhà cung cấp phản hồi chậm sẽ phù hợp thực tế hơn. Đối với bộ phận mua hàng, việc ưu tiên hiển thị các dòng có thời gian giao hàng dài, chưa xác định thông số kỹ thuật và có giá trị ràng buộc sẽ giúp dễ dàng ra quyết định hơn so với việc giám sát toàn bộ mặt hàng.
Nếu muốn triển khai trong 90 ngày
Trong 30 ngày đầu, giới hạn phạm vi linh kiện và đo lường hiện trạng. Kiểm tra các trường hợp trước đây với các mặt hàng có thời gian giao hàng dài nhất, sắp xếp các ngày cần thiết, ngày xác nhận thiết kế, ngày đầu tiên hỏi nhà cung cấp, ngày phát hành PO, ngày nhận hàng. Chọn mỗi trường hợp phát sinh phí hủy do thay đổi thiết kế và phát sinh PO kép, kiểm tra điểm đứt gãy trong phân chia trách nhiệm. Nếu cố gắng sửa toàn bộ master cho tất cả mã hàng ở giai đoạn này, dự án sẽ bị đình trệ, nên chỉ giới hạn các linh kiện thực sự cần quyết định đặt hàng trước cho thử nghiệm.
Từ ngày 31 đến 60, định nghĩa trạng thái và trường nhập liệu cho nhu cầu tạm thời, phê duyệt, cam kết của nhà cung cấp, chuyển đổi; kiểm tra luồng dữ liệu của ERP hoặc MRP hiện tại. Quy tắc phê duyệt và giới hạn hủy do các bên chịu trách nhiệm kinh doanh, mua hàng, thiết kế, kế toán quyết định. Yêu cầu nhà cung cấp phần mềm trình diễn các kịch bản ngoại lệ đã nêu, đồng thời đưa các công việc bổ sung như liên kết master, thiết lập quyền hạn vào báo giá. Trước khi điền bảng chức năng phần mềm, cần thống nhất giải thích bằng cùng dữ liệu thử nghiệm.
Từ ngày 61 đến 90, vận hành với một số trường hợp thực tế. Không tự động hóa hoàn toàn phát hành PO ngay lập tức, mà dành một giai đoạn để con người kiểm tra sự nhất quán giữa phê duyệt và tài liệu đối ngoại. Hàng tuần, rà soát các dòng chưa chuyển đổi, đặt trước hết hạn, chi phí hủy, cảnh báo trùng lặp sai và điều chỉnh quy tắc. 90 ngày không phải là cam kết tiến độ triển khai mà là mốc đánh giá. Nếu phạm vi chỉnh sửa ERP hiện tại hoặc thay đổi hợp đồng với nhà cung cấp lớn, hãy kéo dài từng giai đoạn.
Câu hỏi thường gặp
Đối với các linh kiện chưa chốt thiết kế, có bắt buộc phải đặt hàng trước bằng PO chính thức không?
Không. Có thể lựa chọn các phương thức có mức độ ràng buộc khác nhau như hỏi thời gian giao hàng, báo giá, đặt trước khung số lượng, hoặc thông báo nội bộ có điều kiện. Ngay cả khi cần PO chính thức, cần phê duyệt số lượng, thông số kỹ thuật, thời hạn hủy, giới hạn chi phí và lưu lại sự đồng ý của nhà cung cấp. Việc tài liệu nào trở thành cam kết hợp đồng phụ thuộc vào điều khoản hợp đồng và khu vực pháp lý, không nên chỉ dựa vào tên gọi trên màn hình tiêu chuẩn để đánh giá.
Phê duyệt yêu cầu mua hàng của MRP và phê duyệt đặt hàng trước có giống nhau không?
Mục đích khác nhau. Yêu cầu mua hàng của MRP là thủ tục đặt hàng dựa trên kế hoạch đã xác định và nhu cầu lấy từ master. Phê duyệt đặt hàng trước là quyết định mức độ chấp nhận rủi ro khi thông số kỹ thuật hoặc nhu cầu chưa xác định. Ngay cả khi sử dụng cùng một quy trình phê duyệt, cần thiết kế riêng biệt căn cứ cần thiết, giới hạn số tiền, điều kiện phê duyệt lại. Tùy từng sản phẩm, hành vi xác nhận đơn đặt hàng kế hoạch và phê duyệt PO sẽ khác nhau, nên cần kiểm tra thực tế trên hệ thống.
Có nên tính đặt trước vào nguồn cung của MRP không?
Tùy thuộc vào mức độ ràng buộc của đặt trước và trạng thái xác nhận của nhà cung cấp. Nếu coi các yêu cầu chưa được trả lời hoặc chỉ mới phê duyệt nội bộ là nguồn cung chắc chắn, có thể làm mất cảnh báo thiếu hàng. Ngược lại, nếu không tính PO đã xác nhận vào, sẽ dẫn đến đặt hàng trùng lặp. Cần quy định rõ ràng nguyên tắc tính nguồn cung theo từng trạng thái và kiểm tra việc không tính trùng cho cùng một dòng nhu cầu.
Khi RFP hoặc FAT/SAT, cần ưu tiên xác nhận điều gì?
Điều quan trọng nhất là có thể chuyển đổi từng phần từ nhu cầu tạm thời sang chỉ thị chính thức, đồng thời vẫn liên kết được số lượng, chi phí và lịch sử phê duyệt ngay cả khi có thay đổi thiết kế hoặc hủy bỏ. Thay vì chỉ dựa vào số lượng màn hình hay tên chức năng tiêu chuẩn, hãy kiểm tra bằng thử nghiệm luồng dữ liệu từ đầu đến cuối cho cùng một dự án. Đặc biệt chú ý đến việc đặt hàng trùng sau khi chạy lại MRP, tính nguồn cung trước khi nhà cung cấp phản hồi, và số dư trong quá trình phê duyệt thay đổi.
Tổng kết
Ba trường hợp dễ gây bối rối trong thực tiễn
Trường hợp thứ nhất là khi có hai linh kiện ứng viên, nhưng chỉ một bên có thời gian giao hàng cực kỳ dài. Trong trường hợp này, nếu đặt mua đủ số lượng cả hai để đảm bảo an toàn, chắc chắn sẽ dư thừa một trong hai loại. Bộ phận thiết kế cần xác nhận “đến khi nào có thể chốt một ứng viên” và “phạm vi có thể quyết định trước như một tiêu chuẩn chung”, còn bộ phận mua hàng cần xác nhận khung đặt trước, ngày có thể hủy, ngày bắt đầu sản xuất của từng loại. Người phê duyệt cần nắm được số tiền tối đa bị ràng buộc kép, nếu cần thì chỉ giữ trước số lượng giới hạn. Lý do quyết định cần được đính kèm vào dòng nhu cầu, đồng thời xác định người phụ trách và thời hạn đóng linh kiện không được chọn sau này.
Trường hợp thứ hai là khi cùng một linh kiện được sử dụng cho nhiều dự án khách hàng khác nhau. Nếu chuyển phần nhu cầu giảm của dự án A sang dự án B, có thể không cần hủy đơn và đặt lại đơn mới. Tuy nhiên, nếu có các điều kiện như kiểm tra riêng cho khách hàng, chỉ định lô, chứng nhận, điều kiện đóng gói thì dù mã hàng giống nhau cũng không thể chuyển đổi. Cần đối chiếu phân loại tồn kho tại kho, dòng PO gửi nhà cung cấp, truy xuất nguồn gốc cho khách hàng và lưu lại căn cứ xác định có thể chuyển đổi. Nếu cần chuyển chi phí kế toán, bộ phận kế toán sẽ xác nhận. Hệ thống đặt hàng trước nên có chức năng thay đổi phân bổ sang dự án nhận mà không xóa cam kết của dự án gốc để dễ vận hành.
Trường hợp thứ ba là khi nhà cung cấp thay đổi thời gian giao hàng, khiến hạn chót quyết định đặt hàng đến trước khi thiết kế được chốt. Nếu người phụ trách chỉ đọc email rồi “tạm thời tạo PO”, điều kiện khi phê duyệt và điều kiện thực tế sẽ không khớp nhau. Cần ghi lại ngày trả lời, người trả lời, có cam kết hay không, điểm thay đổi so với lần trước và tính toán lại chênh lệch với ngày cần thiết. Người chịu trách nhiệm sẽ so sánh các phương án như chọn vận chuyển khẩn cấp với chi phí cao để đảm bảo tiến độ, đề xuất điều chỉnh thời gian giao hàng với khách hàng, hay thay đổi thông số kỹ thuật dựa trên cùng một dữ liệu. Sau khi quyết định, cần thông báo điều kiện đặt hàng mới nhất cho nhà cung cấp và xác nhận không còn thông báo cũ tồn tại.
Điểm chung của ba ví dụ trên không phải là để hệ thống tự động chọn đáp án đúng. Mà là liên kết hạn chót quyết định, căn cứ, cam kết đối ngoại, giới hạn chi phí, người phụ trách tiếp theo vào một dòng nhu cầu duy nhất. Nếu tích hợp giả định thay đổi thiết kế vào cấu trúc dữ liệu, sẽ không cần phải chỉnh sửa lại số liệu sau này. Khi thử nghiệm, thay vì chọn các trường hợp đơn giản dễ thành công, nên xử lý từng trường hợp thực tế có nhiều băn khoăn như trên để phát hiện lỗi nhanh hơn.
Khi lưu lại kết quả thử nghiệm, không chỉ chụp màn hình mà còn cần lưu lại phiên bản nhu cầu giả đã nhập, người phê duyệt, phản hồi của nhà cung cấp, yêu cầu mua hàng và PO đã tạo, đề xuất sau khi chạy lại MRP, số dư còn lại sau khi hủy thành một bộ chứng cứ. Việc đánh giá thành công cũng không chỉ dừng lại ở “không phát sinh lỗi”. Cần xác nhận không có đề xuất số lượng sai, người phụ trách tiếp theo có phát hiện được ngoại lệ không, tài liệu gửi nhà cung cấp và hồ sơ nội bộ có khớp nhau không. Chỉ khi đó mới có thể đồng thời thực hiện được cả quyết định nhanh để đảm bảo tiến độ và phê duyệt cẩn trọng để kiểm soát chi phí.
Bảng điều kiện với nhà cung cấp cũng không nên lưu riêng thành file khác mà cần có thể tham chiếu trực tiếp từ dòng nhu cầu. Ngay cả cùng một từ “đặt trước”, nhưng nếu chỉ thông báo miệng về khung cung ứng, đã thực sự giữ vật tư hay đã bắt đầu sản xuất thì chi phí hủy sẽ khác nhau. Bảng điều kiện cần ghi rõ thời hạn hiệu lực, đối tượng giữ hàng, đã chốt đơn giá hay chưa, biên độ cho phép thay đổi số lượng, phương thức hủy, người trả lời. Nếu đến hạn phê duyệt mà vẫn chưa rõ các điều kiện quan trọng, cần hiển thị chính điểm chưa rõ đó trên màn hình phê duyệt. Không được coi các ô trống là 0 đồng hay đã cam kết để tránh tranh chấp chi phí về sau.
Ngoài ra, tại các nhà máy đa ngôn ngữ, cần cố định trước mã trạng thái và định nghĩa để đảm bảo cùng một trạng thái được hiểu giống nhau giữa hướng dẫn cho trụ sở Nhật bằng tiếng Nhật và chỉ thị hiện trường bằng tiếng Thái. Chỉ cần thống nhất từ dịch như “dự báo”, “đặt trước”, “đặt hàng” chưa chắc đã đồng nghĩa về mặt hợp đồng. Trong hệ thống, cần dùng chung mã trạng thái và liên kết hiển thị, mô tả nghiệp vụ cho từng ngôn ngữ. Đơn đặt hàng gửi nhà cung cấp phải lưu bằng ngôn ngữ và phiên bản đã được đối tác đồng ý, còn bản dịch nội bộ chỉ dùng để tham khảo và cần ghi rõ điều này. Những thiết lập tưởng như nhỏ nhặt này lại là yếu tố then chốt đảm bảo tính tái lập quyết định khi thay đổi nhân sự hoặc kiểm toán.
Đặt hàng trước cho các linh kiện có thời gian giao hàng dài không chỉ đơn giản là đặt PO sớm hơn. Đây là một chuỗi quản lý bao gồm ghi nhận nhu cầu chưa xác định kèm căn cứ, phê duyệt số tiền ràng buộc mà công ty chịu trách nhiệm, phân biệt cam kết với nhà cung cấp, giữ lại trách nhiệm khi thay đổi thiết kế hoặc hủy bỏ, và chỉ chuyển đổi một lần sang BOM chính thức, MRP, yêu cầu mua hàng. Hệ thống triển khai cần đảm bảo liên kết trạng thái và lịch sử này. Khi lập RFP và FAT/SAT, hãy kiểm tra bằng dữ liệu thử nghiệm các trường hợp ngoại lệ khó xử lý nhất.
Nếu quý vị đang cân nhắc đặt hàng trước cho linh kiện có thời gian giao hàng dài tại các cơ sở Thái Lan/ASEAN, có thể liên hệ tư vấn về điểm kết nối với ERP/MRP hiện tại cũng như quy trình phê duyệt, chuyển đổi. Ngay cả khi số mặt hàng liên quan còn ít, chúng tôi cũng có thể cùng quý vị xác nhận phạm vi quản lý cần thiết.
Thông tin tham khảo
- SAP Help Portal: Chuyển đổi từ Lệnh Kế hoạch sang Yêu cầu Mua hàng
- Microsoft Learn: Phê duyệt và quản lý Lệnh Kế hoạch
- Microsoft Learn: Xác nhận Lệnh Kế hoạch
- Microsoft Learn: Yêu cầu Mua hàng và Lập kế hoạch
- Microsoft Learn: Phê duyệt, thay đổi và hủy Đơn đặt hàng mua (PO)
- Microsoft Learn: Quản lý thay đổi thiết kế
- Thailand BOI: Hỗ trợ phát triển chuỗi cung ứng
*Các trường hợp sử dụng số lượng và số ngày trong bài viết này chỉ nhằm mục đích minh họa. Vui lòng xác nhận thời hạn giao hàng, chi phí và trách nhiệm hợp đồng cụ thể dựa trên dữ liệu thực tế và điều kiện hợp đồng của từng doanh nghiệp.*
