Triển khai quy trình phê duyệt đề nghị mua hàng trong nhà máy

Khi nhà máy báo cần mua gấp phụ tùng thay thế, bộ phận mua hàng vẫn không thể đặt hàng nếu mặt hàng, mục đích, ngày cần, ngân sách và người duyệt nằm rải rác trong nhiều email. Quy trình phê duyệt đề nghị mua hàng (yêu cầu mua hàng, PR) phải ghi lại nhu cầu tại hiện trường, kiểm tra thẩm quyền và ngân sách, rồi chuyển thông tin đã duyệt sang đơn đặt hàng (PO) một cách an toàn. Bài viết này tổng hợp yêu cầu và ví dụ kiểm thử để bên mua tại cơ sở sản xuất ở Thái Lan dùng trong RFP, thí điểm, FAT và SAT.

Yêu cầu mua hàng và mua sớm giải quyết hai vấn đề khác nhau

PR là văn bản nội bộ nêu cần mua gì, vì sao, khi nào và chi phí dự kiến. Phê duyệt PR không đồng nghĩa với đặt hàng cho nhà cung cấp hay hình thành hợp đồng. Tài liệu quy trình PR của Microsoft mô tả thứ tự từ bản nháp đến phê duyệt, sau đó mới tạo PO từ các dòng yêu cầu. PR đã duyệt có thể chờ mà chưa thành PO; điều kiện cũng có thể thay đổi sau khi chuyển đổi. Hệ thống không nên gộp PR, phê duyệt, PO và nhận hàng thành một trạng thái “đã duyệt”.

Chủ đề này khác với quản lý mua sớm vật tư có thời gian cung ứng dài, nơi thiết kế hoặc nhu cầu còn chưa chắc chắn và doanh nghiệp phải quyết định chấp nhận rủi ro nào trước đơn hàng chính thức. Ở đây trọng tâm là PR thông thường: dữ liệu yêu cầu đầy đủ, luồng phê duyệt, phân quyền, ngân sách, trả lại để sửa, người được ủy quyền, lịch sử thay đổi và liên kết PO. Mua sớm ngoại lệ cần được phân loại riêng và phê duyệt rõ ràng, không lẫn vào tuyến tiêu chuẩn.

Tổng quan hệ thống quản lý mua hàng cho doanh nghiệp sản xuất bao quát cả so sánh báo giá và quản lý sau đặt hàng. Bài này giới hạn giai đoạn từ tạo PR đến bàn giao cho PO, nên tập trung vào tuyến duyệt, thay đổi, trả lại và phòng ngừa yêu cầu trùng, thay vì so sánh phần mềm đánh giá nhà cung cấp hay đối chiếu hóa đơn.

Vật tư gián tiếp, phụ tùng bảo trì, đồ gá, gia công ngoài, vật tư tiêu hao và đầu tư thiết bị có người yêu cầu, người duyệt, ý nghĩa ngày cần và chứng từ khác nhau. Cũng phải phân biệt nhu cầu sản xuất do MRP tự sinh với yêu cầu do bộ phận chủ động lập. Dù cùng hiện trên một màn hình, hệ thống cần giữ nguồn gốc và người chịu trách nhiệm để tránh mua trùng và phục vụ kiểm toán. Bài viết tập trung vào PR nội bộ do hiện trường hoặc phòng ban khởi tạo.

Trước hết hãy lập bản đồ tuyến phê duyệt hiện tại

Trước khi chọn giao diện, hãy lần theo khoảng mười yêu cầu thực tế. Ghi chúng bắt đầu bằng lời nói, chat, giấy, email hay ERP; ai kiểm tra thông tin nào; khi nào đủ điều kiện để đặt hàng. Mười trường hợp là gợi ý thực hành để phát hiện ngoại lệ, không phải cỡ mẫu thống kê. Nên có hỏng máy khẩn cấp, bảo trì định kỳ, sửa khuôn, gia công ngoài, vượt ngân sách và nhà cung cấp chưa đăng ký.

Vẽ các bước tạo yêu cầu, chỉnh dữ liệu, kiểm tra kỹ thuật, kiểm tra ngân sách, phê duyệt, rà soát mua hàng, lấy báo giá/chọn nhà cung cấp, tạo và phát hành PO, nhận hàng và đối chiếu hóa đơn. Với từng bước, ghi người phụ trách, người thay thế, đầu vào, tiêu chí, đầu ra, thời hạn và bằng chứng. Với phụ tùng bảo trì, trưởng bảo trì đánh giá mã máy và nguy cơ dừng chuyền, kỹ sư xác nhận tương thích, còn mua hàng đánh giá giá và nhà cung cấp. Đừng giao mọi đánh giá chuyên môn cho một quản lý.

Yêu cầu “số hóa duyệt qua email” chưa đủ. Hãy tách việc nhập lại nhiều lần, chờ duyệt lâu, thiếu lý do trả lại, ủy quyền không kiểm soát và thay đổi điều kiện sau duyệt. Đo thời gian cơ sở từ lập đến duyệt, số lần trả lại, thay đổi sau duyệt và PR chờ chuyển PO, kèm nhóm hàng và bộ phận. Đặt mục tiêu từ dữ liệu của mình, không lấy tỷ lệ rút ngắn của công ty khác làm căn cứ.

Phê duyệt cả chứng từ hay từng dòng?

Một PR có thể chứa các dòng có chủ ngân sách, nhóm hàng và ngày cần khác nhau. Microsoft trình bày cả quy trình theo chứng từ và xét duyệt từng dòng. Duyệt cả chứng từ đơn giản nhưng một dòng sai có thể giữ lại toàn bộ. Duyệt theo dòng chuyển đúng chuyên gia nhưng cần quy định điều kiện hoàn tất, từ chối một phần, ngưỡng cộng gộp và tách PO. Chọn theo ngoại lệ thực tế của hàng hóa và tổ chức.

Hãy thử PR có mô tơ dự phòng và văn phòng phẩm. Mô tơ có thể cần mã máy, kiểm tra tương thích và mức khẩn; văn phòng phẩm cần giá danh mục và ngân sách phòng ban. Nếu gửi cho hai người duyệt, phải xác định trạng thái PR cuối cùng là duyệt, duyệt một phần, trả lại hay từ chối. Nếu chỉ dòng đã duyệt được chuyển sang PO, kiểm thử để dòng bị từ chối không âm thầm xuất hiện lại.

Xác định dữ liệu PR cho cả đặt hàng và kiểm toán

Phần đầu tối thiểu gồm số PR, người tạo, người yêu cầu thực, pháp nhân, nhà máy, phòng ban, trung tâm chi phí, tiền tệ, ngày cần, nơi giao, mục đích, lý do khẩn, tệp đính kèm, trạng thái, phiên bản và thời điểm tạo/cập nhật. Dòng hàng có thể cần mã hàng/dịch vụ, mô tả, số lượng, đơn vị, phiên bản thông số, hãng ưu tiên, hàng thay thế cho phép, đơn giá dự tính, cách tính thuế, mục đích sử dụng và mã thiết bị hoặc lệnh sản xuất. Bắt buộc mọi trường mọi lúc khiến người dùng điền giả; hãy đặt điều kiện theo nhóm và tình huống.

Chính sách mua hàng của Microsoft nêu ví dụ thiết lập theo tổ chức, nhóm mua hàng, trường bắt buộc trước khi gửi, điều kiện cần RFQ và điều kiện tạo PO từ PR đã duyệt. Chuyển các ý đó thành quy tắc RFP, đừng sao chép tên màn hình sản phẩm: yêu cầu đồ gá phải kèm bản vẽ, một số nhóm do mua hàng chọn nhà cung cấp, và yêu cầu giá trị cao chưa có báo giá phải qua rà soát mua hàng.

Ranh giới giữa danh mục hàng và nhập tự do

Với hàng có sẵn, lấy mô tả, đơn vị chuẩn, nhà cung cấp tiềm năng và thời gian cung ứng từ mã hàng. Chỉ cho nhập tự do khi cần và yêu cầu thông số, công dụng, khả năng thay thế, báo giá. Cấm mọi mã chưa đăng ký sẽ đẩy sửa chữa lần đầu hoặc chi tiết mẫu về email. Thả tự do hoàn toàn lại tạo hàng tương đương trùng và khó so giá. Quy định kiểm tra hàng mới và mã tạm theo nhóm.

Số lượng phải đi với đơn vị. “10” không cho biết là chiếc, hộp hay mét. Nếu đơn vị mua và đơn vị kho trong ERP khác nhau, lưu căn cứ quy đổi. Nếu ngưỡng duyệt dùng đổi tiền, ghi ngày tỷ giá, nguồn, quy tắc làm tròn và số tiền có gồm thuế hay không. Với báo giá ngoại tệ tại nhà máy Thái Lan, quyết định mức chênh giữa ước tính PR và giá PO có cần duyệt lại không. Dùng tỷ giá và thuế suất trong danh mục được phê duyệt tại thời điểm xử lý, không lấy số cố định trong bài viết.

Tệp đính kèm và phiên bản

Liệt kê tài liệu theo nhóm: bản vẽ đồ gá, thông số thiết bị, báo giá, ảnh, biên bản hỏng, chấp thuận của khách. Không chỉ lưu giờ gửi mà còn giữ chính xác phiên bản từng người duyệt đã xem. Khi người yêu cầu thay thông số lúc đang duyệt, ghi thay đổi và lý do; thay đổi quan trọng phải duyệt lại. Hiển thị phiên bản tệp cùng phiên bản dòng để tránh tệp mới nhưng số lượng hoặc giá trên màn hình vẫn cũ.

Nếu tự chuyển tệp từ email cá nhân, kiểm tra quyền truy cập và thời hạn lưu. Báo giá có thể chứa giá và liên hệ; phân biệt quyền của người yêu cầu, người duyệt, mua hàng, kiểm toán và nhà cung cấp bảo trì theo hợp đồng. Lợi ích của số hóa là truy được tài liệu nào đã hỗ trợ quyết định nào.

Định tuyến duyệt theo rủi ro và nhiệm vụ, không chỉ giá trị

Đầu vào định tuyến có thể gồm pháp nhân, cơ sở, phòng ban, nhóm, giá trị, trung tâm chi phí, thiết bị/lệnh sản xuất, mức khẩn, kết quả ngân sách, tình trạng nhà cung cấp và CAPEX/OPEX. Quá nhiều điều kiện khiến quy tắc khó giải thích. Bắt đầu từ quy chế thẩm quyền và yêu cầu tiêu biểu, rồi bổ sung ngoại lệ thực tế. Nếu không tìm được người duyệt, đưa vào hàng chờ để quản trị viên xử lý, không tự duyệt vô điều kiện.

Tài liệu Oracle nêu nhóm duyệt, cấp bậc, tuyến quản lý, một người duyệt và tuyến tự định nghĩa. Microsoft có duyệt theo chứng từ/dòng và phối hợp quản lý, người mua, người kiểm tra chi phí. Đây là ví dụ khả năng sản phẩm, không chứng minh kiểm soát của doanh nghiệp đã phù hợp. Bên mua phải quyết định ai duyệt việc gì dựa trên bằng chứng nào, người tạo có được duyệt cuối yêu cầu của chính mình không và ủy quyền có hiệu lực khi nào.

Tách thẩm quyền chi tiền khỏi đánh giá kỹ thuật

Trưởng bộ phận có hạn mức duyệt không nhất thiết xác nhận phụ tùng phù hợp về kỹ thuật. Ghi kiểm tra kỹ thuật, ngân sách, phê duyệt chi và rà soát mua hàng thành các hành động riêng. Kỹ sư kiểm bản vẽ và máy, chủ ngân sách kiểm nguồn, người có thẩm quyền duyệt chi, mua hàng xác định nhà cung cấp và giá. Dù tại cơ sở nhỏ một người kiêm nhiều việc, hệ thống vẫn nên giữ từng hành động và bằng chứng.

Đưa phân tách nhiệm vụ vào RFP. Tối thiểu kiểm tra người lập với người duyệt cuối, và người tạo nhà cung cấp với người duyệt đổi tài khoản thụ hưởng. Cặp nào bị cấm tùy quy chế, nhưng hệ thống phải lưu ID, vai trò, quan hệ ủy quyền và quyền tại thời điểm xử lý. Gắn quy tắc vào tên cá nhân dễ hỏng khi chuyển việc; ưu tiên vai trò và cơ cấu tổ chức, ngoại lệ chỉ định tên phải có hạn.

Ngưỡng và chia nhỏ yêu cầu

Xác định ngưỡng áp dụng cho toàn PR, từng dòng hay tổng một dự án. Một ca sửa máy có thể bị chia thành nhiều PR nhỏ để tránh cấp duyệt cao hơn. Hệ thống không phát hiện được mọi gian lận, nhưng xem theo mã dự án, máy, nhóm hàng gần nhau, người yêu cầu và nhà cung cấp đề xuất sẽ giúp rà soát. Số tiền và khoảng thời gian cụ thể lấy từ quy chế công ty, không dùng ví dụ tùy ý.

Quy định khi báo giá tăng sau duyệt. Chính sách Microsoft có cơ chế đưa dòng vượt biên độ giá khi tạo PO về xét thủ công. RFP nên nêu điều kiện duyệt lại theo số tiền tuyệt đối bên cạnh tỷ lệ, thay đổi nhà cung cấp, thông số và ngày giao. PR đã duyệt không cho phép tùy ý đổi mọi nội dung PO.

Người ủy quyền, vắng mặt và khẩn cấp

Người duyệt nghỉ hoặc chuyển việc không nên làm nhà máy dừng. Đăng ký người thay thế trước với thời hạn, pháp nhân, nhóm và hạn mức, người thiết lập và cách thu hồi. Lưu cả người duyệt gốc lẫn người thao tác. Thử quyền hết hạn không dùng được và gửi thông báo đồng thời không tạo hai lần duyệt.

Mua khẩn không có nghĩa bỏ phê duyệt. Với máy dừng ban đêm, xác định lý do, tác động, vì sao không lấy được báo giá, người có quyền tạm thời và bước mua hàng rà soát sau. Nếu cho phép duyệt hồi tố, nêu hồ sơ cần bổ sung, hạn chót và cách chuyển cấp khi quá hạn. Nếu tuyến khẩn được dùng thường xuyên, phân tích riêng tốc độ duyệt và vấn đề tồn kho/kế hoạch bảo trì.

Quản lý ngân sách như trạng thái riêng với phê duyệt

Người có thẩm quyền đồng ý không chứng minh còn tiền. Quy định kiểm ngân sách theo trung tâm chi phí, dự án, tài khoản và kỳ; chỉ cảnh báo hay giữ chỗ ngân sách. Oracle giải thích rằng khi bật kiểm soát, có thể kiểm tiền trước khi gửi và giữ chỗ khi gửi hoặc khi duyệt tùy cấu hình. Thời điểm đúng phụ thuộc nghiệp vụ kế toán và ERP của doanh nghiệp.

Thử thay đổi tỷ giá/giá trước PO, nhiều PR cùng sử dụng một ngân sách, hoàn giữ chỗ khi từ chối/hủy và trường hợp qua kỳ. Quy định thiếu ngân sách thì giữ lại, xét ngoại lệ hay trả về. Nếu duyệt xong nhưng chưa có tiền, bộ phận mua phải thấy rõ “đã duyệt, chưa bảo đảm ngân sách”. Chữ ký của tài chính không thay cho kết quả kiểm tiền thành công.

Với kết nối ngân sách bất đồng bộ, số dư trên màn hình có thể cũ vài phút. Quy định kiểm lại lúc gửi, duyệt hay đổi sang PO và không hiển thị “đã kiểm” sau lỗi hoặc timeout. Lưu ID truy vấn ngoài, giờ, dòng liên quan, kết quả và lịch sử thử lại. Nếu chưa nối hệ thống ngân sách, vẫn nên có trường người kiểm và căn cứ.

Thiết kế trả lại, thay đổi và hủy như tuyến xử lý thường xuyên

Yêu cầu thực tế hiếm khi hoàn tất lần đầu. Trả lại phải nêu thiếu gì, ai sửa trường nào, bình luận và hạn gửi lại. Từ chối nghĩa là không chấp nhận nhu cầu, nên tách khỏi trả lại. Rút đơn theo ý người lập không được hủy dòng đã tạo PO. Kiểm tra việc hoàn ngân sách và đảo công việc mua hàng khi hủy.

Tài liệu SAP nêu duyệt nhiều bước và điều kiện khởi động lại quy trình sau khi sửa. Bên mua phải quy định tác động của thay đổi số lượng, đơn giá, thông số, ngày giao, trung tâm chi phí, nhà cung cấp đề xuất và tệp. Khởi động lại do sửa lỗi chính tả sẽ gây chậm; giữ duyệt cũ sau đổi quan trọng lại cho phép đặt hàng theo nội dung người duyệt chưa thấy. Hãy lập ma trận thay đổi quan trọng.

Nhật ký kiểm toán cần giữ giờ, người dùng, giá trị cũ/mới, lý do và phiên bản tuyến cho tạo, sửa, gửi, trả lại, gửi lại, duyệt, từ chối, ủy quyền, hủy và bàn giao PO. Không cho người dùng ghi đè lịch sử. “Người cập nhật cuối” không chứng minh nội dung tại thời điểm quyết định. Xác định cách xử lý yêu cầu đang chạy theo quy tắc cũ khi sửa quy tắc để không diễn giải lại duyệt cũ theo quy tắc mới.

Ngăn yêu cầu trùng và thao tác đồng thời xung đột

Một máy hỏng có thể khiến kỹ thuật viên yêu cầu qua chat còn trưởng ca viết đơn giấy. Hiển thị ứng viên trùng theo mã dự án, mã máy, mặt hàng, ngày cần và nguồn, rồi để người phụ trách xác nhận. Đề xuất trùng không phải tự từ chối: yêu cầu thêm số lượng hoặc cùng phụ tùng cho máy khác có thể hợp lệ. Khi xác nhận trùng, giữ liên kết từ PR đã rút sang PR còn hiệu lực, không xóa dấu vết.

Nếu hai người duyệt cùng thao tác, một người trả lại còn người kia bấm Duyệt, thao tác trên màn hình cũ không được ghi đè trạng thái mới. So phiên bản yêu cầu hoặc số cập nhật và báo tải lại. Bấm đúp hay mạng gửi lại phải được tính một sự kiện duyệt; lỗi truyền nhìn như chưa gửi không được tạo duyệt trùng. Việc này bảo vệ cả tính đúng của dấu vết kiểm toán.

Dùng thông báo để hỗ trợ thay đổi trạng thái

Email và chat là kênh thông báo, không phải hồ sơ duyệt gốc. Nếu email có nút duyệt, cần liên kết có chữ ký, kiểm quyền, hạn dùng và chống thực hiện lặp. Mất email vẫn phải thấy việc trong danh sách chờ của hệ thống. Quá SLA thì chuyển cho người thay thế hoặc quản trị, đồng thời cho người yêu cầu biết chủ việc kế tiếp. Tăng số thông báo không tự giải quyết tồn đọng.

Làm rõ ranh giới với ERP, MES và hệ thống bảo trì

Nếu ERP là nguồn dữ liệu chuẩn của hàng hóa, nhà cung cấp, trung tâm chi phí và PO, quy trình mới không nên quản lý bản sao độc lập. Đặc tả kết nối phải có khóa, phiên bản, hướng/tần suất đồng bộ, cách hiển thị khi trễ, thử lại khi lỗi và chống trùng. Tham chiếu qua lại số PR và PO ERP, cho truy cập trạng thái mới nhất từ hai màn hình. Không cần thay ngay hệ thống nhận hàng và hóa đơn, nhưng phải lần được PR đã duyệt tới PO và lần nhận tương ứng.

Nếu nhu cầu bắt nguồn từ MES hoặc bảo trì, chuyển mã máy, lệnh công việc, nguyên nhân dừng, dây chuyền và ngày cần vào PR. Phân biệt tạo tự động với con người và dùng khóa idempotency để một phiếu sự cố không tạo hai PR. Bắt buộc ID nhà cung cấp trước khi mua hàng chọn sẽ làm mờ trách nhiệm chọn. Tách “nhà cung cấp đề xuất” và “nhà cung cấp đã chọn”, lưu lịch sử đổi.

Bàn giao PR đã duyệt sang PO không chỉ là xuất CSV. Lập bảng ánh xạ hàng, số lượng, đơn vị, phiên bản thông số, điều kiện giá, nơi giao, ngày cần, thuế, tiền tệ, dự án và chứng cứ duyệt. Nếu mua hàng gộp/tách dòng, theo dõi quan hệ nhiều nhiều với dòng PR gốc. Thử rằng tạo PO thất bại không hiện “đã đặt” và gửi lại không tạo PO thứ hai. Nếu đã gửi nhưng mất phản hồi, hỏi hệ thống ngoài trước khi thử lại.

Xác định thay người duyệt theo thời điểm và từng yêu cầu

Khi người duyệt chuyển việc hoặc nghỉ, chỉ đổi danh mục quản lý “từ hôm nay” vẫn để PR đang chạy mắc kẹt. Quyết định chuyển toàn bộ việc chờ sang người mới, chuyển sang người được ủy quyền của người cũ, hay để quản trị quyết từng trường hợp. Khi chuyển, lưu người phụ trách trước, lý do, người thực hiện, giờ và người được báo. Không xóa bước người cũ đã duyệt, cũng không tự duyệt bước người mới chưa xem. Tái cơ cấu có thể chỉ đổi trung tâm chi phí nên phải kiểm riêng danh mục người duyệt và thuộc tính kế toán của yêu cầu.

Ủy quyền nghỉ phép có kế hoạch, quản trị chuyển việc khi ốm đột ngột và quyền khẩn khi máy dừng ban đêm khác nhau về người thiết lập và cách kiểm toán. Quy định phạm vi người duyệt tự chọn người thay thế và khi nào cần cấp trên cho phép. Nếu người thay thế là chính người yêu cầu trong vụ việc, phát hiện xung đột lợi ích và định tuyến khác. Khi người gốc trở lại sau khi đã báo người thay thế, làm rõ ai sở hữu việc chờ trên màn hình và lịch sử. Gửi email cho cả hai không tự phân định trách nhiệm.

Xác định điểm khởi động duyệt lại sau thay đổi quan trọng

Khởi động lại từ đầu vì bổ sung nhỏ khiến hiện trường chờ; chỉ gửi người duyệt cuối có thể khiến PO mang thông số kỹ sư chưa xem. Xác định điểm bắt đầu theo trường đổi: đổi mã máy hay kiểu phụ tùng quay về kiểm kỹ thuật; đổi trung tâm chi phí hay giá trị quay về kiểm ngân sách và duyệt chi; sửa chính tả chỉ ghi lịch sử và giữ tuyến. Nếu đổi nhiều trường cùng lúc, đặt ưu tiên như quay về bước sớm nhất bị ảnh hưởng.

Màn hình cần hiển thị khác biệt giữa phiên bản người duyệt đã xem và phiên bản hiện tại. Giữ sự kiện duyệt cũ làm bằng chứng nhưng không tính là duyệt phiên bản mới. Nếu mua hàng đổi đơn giá, số lượng, nhà cung cấp hoặc ngày giao sau duyệt PR, quy chế phải quyết định duyệt lại PR hay duyệt riêng trên PO là đủ. Lưu biên độ cho phép và trường liên quan cùng phiên bản. Ngay cả khi dòng không đổi, thay PDF báo giá có thể cần xem lại nếu căn cứ giá mà người duyệt dùng đã đổi.

Kiểm thử gửi lại PO và lỗi một phần

Một PR không nhất thiết thành một PO: có thể gộp nhiều PR cùng nhà cung cấp hoặc tách một PR theo ngày giao. Lưu quan hệ giữa ID dòng PR, ID sự kiện tích hợp và ID dòng PO của ERP để từ màn hình tra cứu quay về phê duyệt gốc. Nếu mất kết nối sau gửi, hỏi ERP xem PO đã tạo chưa trước khi gửi lại. Tạo PO mới chỉ vì màn hình timeout có thể gây đặt hàng trùng.

Khi chỉ vài dòng thành PO còn phần khác lỗi, đừng đánh dấu cả PR “hoàn tất”; hiển thị trạng thái từng dòng và người xử lý lại. Nếu sửa lỗi bằng đổi hàng hoặc giá trị, đối chiếu phiên bản đã duyệt. Gửi lại vì lỗi kỹ thuật không cần duyệt mới, nhưng thay nội dung nghiệp vụ phải theo quy tắc thay đổi. FAT nên thử gửi một sự kiện hai lần, chỉ làm mất phản hồi ERP và để một dòng bị từ chối; trong mọi trường hợp không được còn PO trùng hay dòng không theo dõi được.

Viết RFP theo ngoại lệ, không theo số màn hình

“Có thể gửi và duyệt” không đủ so nhà cung cấp. Nêu cơ sở, pháp nhân, nhóm hàng, số người dùng, quy chế thẩm quyền và ranh giới ERP; giao các kịch bản PR thường, khẩn, nhiều trung tâm chi phí, thiếu ngân sách, người duyệt vắng, đổi thông số, tích hợp PO lỗi và nhà cung cấp chưa đăng ký. Yêu cầu trả lời trong cùng bảng: chuẩn, cấu hình, phát triển riêng hay xử lý thủ công.

Yêu cầu dữ liệu gồm tổ chức, người dùng/quyền, hàng/nhóm, giá trị/tiền tệ, ngân sách, phiên bản tệp, lịch sử duyệt, tham chiếu PO và thời gian lưu. Phi chức năng gồm thiết bị hiện trường/di động, ngôn ngữ hiển thị và tìm kiếm, quy trình khi lỗi, xuất audit log, sao lưu, rà soát quyền và chuyển dữ liệu. Kiểm tra ngôn ngữ từng bộ phận thực dùng tại Thái Lan, không mặc định bắt buộc Thái, Nhật, Anh ở mọi nơi. Dữ liệu cá nhân và hợp đồng theo chính sách công ty.

Khi chấm điểm, phân biệt demo với khả năng tái hiện bằng dữ liệu/quyền thật. “Cấu hình người duyệt được” quá chung. Hỏi ngày quản lý chuyển việc thì PR đang chờ đến ai và sau khi quyền ủy nhiệm hết hạn nút Duyệt có biến mất không. Đánh giá phần quản trị nội bộ tự đổi được và cách kiểm thử, phê duyệt, hoàn tác. Quy tắc xung đột khi thêm cơ sở làm chi phí vận hành tăng dù giá ban đầu thấp.

Chia phạm vi triển khai

Bắt đầu một nhà máy, một phòng hoặc hai nhóm hàng nhưng có tuyến chuẩn và ngoại lệ quan trọng. Thí điểm loại hết ca khẩn/trả lại sẽ chỉ phát hiện lỗi khi chạy thật. Ghi phần chưa triển khai và cách đánh số/chống nộp trùng khi vẫn dùng tuyến cũ. Quyết định PR đang chạy sẽ chuyển sang hệ thống mới hay hoàn tất tuyến cũ.

Đào tạo không chỉ là bấm Gửi. Người duyệt cần biết kiểm gì và chuyển lại nội dung nào cho kỹ thuật/mua hàng; mua hàng kiểm chênh lệch trước PO; quản trị đặt ủy quyền, xem tồn đọng và đổi quy tắc. Mỗi vai trò chạy ca gần dữ liệu thật, kể cả trả lại và hủy. Xác định đầu mối hỗ trợ sau mở, kênh xin đổi cấu hình và cách tạm xử lý khi hệ thống lỗi.

Tiêu chí nghiệm thu quy trình PR tại FAT và SAT

FAT kiểm quy tắc và kết nối ở môi trường đã cấu hình; SAT dùng người, cơ cấu, thiết bị và giờ làm việc thực của nhà máy. Điều kiện đạt là trạng thái, quyền và bằng chứng từ nhập đến PO đúng kỳ vọng, không chỉ là mở được màn hình. Bảng dưới là mẫu; phải thay hạn mức và cấp duyệt theo quy chế của mình.

Cho dữ liệu biên: dưới, bằng và trên ngưỡng duyệt; biên sau đổi tiền; số lượng 0/âm; sai đơn vị; tệp cùng tên khác phiên bản; mã hàng không tồn tại; người duyệt đã chuyển việc. Bài viết không đặt số tiền cụ thể. Viết kết quả mong đợi về thuế, tỷ giá và làm tròn trước khi chạy; bên mua xác nhận trạng thái kỳ vọng từ trước để người thử không đổi điều kiện đạt tùy kết quả.

SAT cũng cần kiểm độ trễ mạng nhà máy, di động, thông báo chậm, múi giờ và ranh giới ngày. Thử yêu cầu khẩn ca đêm có bị gửi nhầm người duyệt ngày hôm sau không và lịch nghỉ của các pháp nhân khác nhau. Sau đổi cấu hình, kiểm thử hồi quy rằng lịch sử cũ không đổi và tuyến PR đang xử lý được giữ hoặc đánh giá lại đúng ý. Sau sự cố, kiểm hàng chờ, sự kiện chưa gửi và PR chưa thành PO.

Sau vận hành, đo chất lượng và lý do tồn đọng

Đo riêng từ tạo đến gửi lần đầu, từ gửi đến duyệt cuối, và từ duyệt đến tạo PO. Hiển thị trung vị cùng các ca chờ dài để việc khẩn nhanh hơn không che mất PR thường chậm hơn. Theo dõi tỷ lệ/lý do trả lại, duyệt ủy quyền, giữ vì ngân sách, thay đổi quan trọng sau duyệt, lỗi tạo PO và PR trùng cho một dự án. Rút ngắn giờ duyệt nhưng tăng lỗi nhập hay vi phạm kiểm soát không phải thành công.

Danh sách tồn đọng cần hiện người phụ trách, số ngày, nguyên nhân và bước kế. Chờ quản lý, chờ mua hàng chọn nhà cung cấp và lỗi tra ngân sách đòi hỏi giải pháp khác nhau. Họp hàng tháng để chỉnh trường nhập nhóm thường gặp, quy tắc duyệt, ủy quyền hay tích hợp ngân sách. Mỗi sửa quy tắc cần giữ lý do, chủ trách nhiệm, ngày hiệu lực và kết quả kiểm thử.

FAQ: Triển khai phê duyệt PR trong nhà máy

Duyệt PR rồi có thể đặt hàng ngay không?

Không. PR xác nhận nhu cầu và quyền chi nội bộ; phát hành PO cho nhà cung cấp là bước riêng. Mua hàng kiểm báo giá, nhà cung cấp, đơn giá, điều kiện hợp đồng và xin duyệt lại khi thay đổi quan trọng. Tự tạo PO cũng cần giới hạn nhóm và ngoại lệ, kiểm lỗi và trùng.

Nhà máy nhỏ có cần nhiều cấp duyệt không?

Không cần tăng cấp chỉ vì số lượng. Xác định việc kiểm tương thích kỹ thuật, ngân sách, thẩm quyền chi và điều kiện mua hàng. Nếu một người kiêm vai trò, ghi lý do và chứng cứ từng việc. Có thể thêm kiểm tra chỉ cho khoản lớn, hàng đặc biệt hoặc nhà cung cấp mới. Tuyến theo quy chế công ty.

Ước tính chi phí hệ thống thế nào?

Ngoài giấy phép còn việc làm sạch danh mục tổ chức/hàng, cấu hình quyền/quy tắc, kết nối ERP/ngân sách, di chuyển, FAT/SAT, đào tạo và bảo trì thay đổi. Ngoại lệ và ranh giới ERP thường quyết định công sức. Gửi cùng kịch bản cho mọi bên bán và yêu cầu tách chức năng chuẩn, cấu hình, phát triển riêng, cách xử lý thủ công.

Đã có mua hàng trong ERP thì cần quy trình khác không?

Kiểm chức năng chuẩn của ERP trước. Nếu đáp ứng nhập tại hiện trường, di động, ủy quyền, nhiều cơ sở, phiên bản tệp, ngân sách và audit log thì có thể không cần thêm. Nếu thiếu, ERP vẫn giữ dữ liệu gốc còn giao diện phía trước cải thiện lập PR. Ưu tiên ranh giới trách nhiệm và khả năng bảo trì hơn sở thích giao diện.

Kết luận

Quy trình PR của nhà máy biến nhu cầu hiện trường thành yêu cầu có thể giải trình, ghi quyết định kỹ thuật, ngân sách, thẩm quyền và mua hàng, rồi chỉ chuyển nội dung đã duyệt sang PO. Trước khi triển khai, làm rõ phạm vi, ngoại lệ, mức duyệt theo chứng từ/dòng, duyệt lại sau thay đổi quan trọng, trạng thái ngân sách, người được ủy quyền và kết nối ERP trong RFP. FAT/SAT phải kiểm cả trả lại, vắng mặt, đổi giá và lỗi tích hợp bên cạnh tuyến bình thường.

Nếu cần xây tuyến PR và hạng mục RFP phù hợp ERP cùng quy chế duyệt ở nhà máy Thái Lan, hãy liên hệ TOMAS TECH. Có thể bắt đầu từ yêu cầu và quy tắc đang dùng để xác định phạm vi triển khai.

Tài liệu tham khảo

• Microsoft Learn: Purchase requisition workflow
• Microsoft Learn: Purchasing policies overview
• Microsoft Learn: Purchase requisition overview
• Microsoft Learn: Procurement and sourcing workflows
• SAP Help Portal: Flexible Workflow for Purchase Requisitions
• SAP Help Portal: Workflow Features for Purchase Requisitions
• Oracle Fusion Cloud Procurement: Approval Rules
• Oracle Fusion Cloud Procurement: Perform Check Funds on Requisitions