Hệ thống yêu cầu mua hàng nội bộ: tránh điểm nghẽn

Vì sao các yêu cầu mua hàng bị mắc kẹt

Hầu hết sự chậm trễ trong mua sắm bắt đầu trước khi có người phê duyệt hoặc từ chối yêu cầu. Một nhân viên yêu cầu mua máy tính xách tay qua email, gửi giá trong ứng dụng trò chuyện rồi thêm một dòng vào bảng tính cho bộ phận tài chính. Mỗi nơi chỉ lưu một phần thông tin. Sau đó, nhân viên mua sắm phải tự tập hợp nhà cung cấp, chi phí, lý do kinh doanh, người phụ trách ngân sách và thời hạn.

Điều này tạo ra nhiều công việc trùng lặp. Quản lý hỏi lại những thông tin mà nhân viên đã gửi cho tài chính. Tài chính kiểm tra ngân sách nhưng không biết trưởng phòng đã phê duyệt nhu cầu hay chưa. Nhân viên yêu cầu cũng không biết yêu cầu đang ở đâu hoặc ai cần xử lý tiếp theo.

Thiếu thông tin gây chậm trễ

Quy trình phê duyệt mua hàng sẽ chậm lại khi yêu cầu không có đủ thông tin mà mỗi người cần. Các thiếu sót thường gặp gồm:

• Không có mô tả mặt hàng, số lượng hoặc báo giá của nhà cung cấp
• Không có phòng ban, trung tâm chi phí hoặc số tiền ngân sách
• Không có lý do kinh doanh hoặc ngày cần giao hàng
• Không xác định người phê duyệt hoặc người phụ trách mua sắm
• Không có lịch sử bình luận, thay đổi hoặc các quyết định trước đó

Chỉ một thông tin thiếu cũng có thể khiến yêu cầu quay lại từ đầu. Một trưởng nhóm có thể phê duyệt gia hạn phần mềm trị giá 1.200 USD, rồi bộ phận tài chính mới phát hiện chưa ai xác định ngân sách. Thay vì đặt hàng, cả nhóm mất nhiều ngày để tìm người phụ trách khoản chi.

Một hồ sơ và trách nhiệm rõ ràng

Hệ thống yêu cầu mua hàng nội bộ giữ toàn bộ yêu cầu trong cùng một nơi, từ lúc gửi cho đến khi bàn giao sang đơn đặt hàng. Người yêu cầu chỉ cần nhập nhu cầu một lần. Quản lý, nhân viên tài chính và nhân viên mua sắm cùng xem một bộ thông tin, thêm bình luận vào cùng hồ sơ và để lại lịch sử quyết định rõ ràng.

Nhãn trạng thái dễ hiểu giúp giảm những lần hỏi lại không cần thiết. Một yêu cầu có thể cho biết nó đang chờ kiểm tra ngân sách, phê duyệt của quản lý, xử lý của nhân viên mua sắm hay thông tin từ nhà cung cấp. Mỗi giai đoạn cần có một người hoặc vai trò cụ thể, cùng quy tắc thay thế khi người phụ trách vắng mặt.

Ứng dụng mua sắm không cần mã giúp triển khai mô hình này mà không buộc đội ngũ vận hành phải quản lý nhiều biểu mẫu và bảng tính. AppMaster có thể hỗ trợ biểu mẫu yêu cầu, trường ngân sách, logic phê duyệt và hàng đợi cho nhân viên mua sắm trong cùng một ứng dụng. Mỗi yêu cầu cần có một nơi lưu trữ, một người phụ trách hiện tại và đủ thông tin để tiến tới đơn hàng.

Xác định thông tin cần có trong mỗi yêu cầu

Biểu mẫu yêu cầu cần cung cấp đủ thông tin để quản lý và nhân viên mua sắm nhanh chóng đưa ra quyết định. Nếu nhân viên phải giải thích những thông tin cơ bản qua các tin nhắn tiếp theo, biểu mẫu đang quá sơ sài. Nếu biểu mẫu hỏi những chi tiết tài chính mà họ không thể biết, họ sẽ đoán hoặc bỏ cuộc.

Mỗi yêu cầu cần có tên mặt hàng, số lượng, nhà cung cấp, chi phí đơn vị ước tính, tổng chi phí và lý do kinh doanh. Thêm phòng ban, trung tâm chi phí, người yêu cầu và ngày cần có hàng khi những thông tin này ảnh hưởng đến ngân sách hoặc việc giao hàng. Sau khi nhân viên đăng nhập, hệ thống có thể tự điền tên và phòng ban của họ.

Một lý do ngắn gọn hiệu quả hơn một ô văn bản trống quá lớn. Ví dụ: «Thêm năm tài khoản hỗ trợ khách hàng cho ca tối mới». Câu này cho người phê duyệt biết lý do thực tế, số lượng và mối liên hệ với công việc hiện tại.

Dùng hai loại yêu cầu

Giao dịch theo danh mục và giao dịch mua đột xuất cần các biểu mẫu khác nhau. Một mặt hàng trong danh mục đã có mô tả, nhà cung cấp, giá được phê duyệt và đôi khi cả thông tin hợp đồng. Nhân viên chỉ cần chọn mặt hàng, nhập số lượng và giải thích nhu cầu. Cách này giúp các yêu cầu phổ biến luôn nhất quán.

Một giao dịch mua đột xuất cần nhiều bối cảnh hơn vì bộ phận mua sắm phải đánh giá trước khi đặt hàng. Hãy yêu cầu mô tả mặt hàng hoặc dịch vụ, nhà cung cấp ưu tiên và thông tin liên hệ nếu biết, báo giá hoặc chi phí ước tính, số lượng và tần suất thanh toán, lý do kinh doanh cùng ngày cần giao hàng.

Đừng bắt nhân viên phải tìm nhà cung cấp trước khi có thể yêu cầu mua một thứ gì đó. Họ có thể biết mình cần một chiếc bàn đứng nhưng chưa biết nhà cung cấp nào đáp ứng quy định của công ty. Bộ phận mua sắm có thể hoàn tất phần này sau.

Chỉ giữ lại các trường bắt buộc thật sự cần thiết

Chỉ yêu cầu một trường khi có người cần nó để phê duyệt, lập ngân sách hoặc mua hàng. Mặt hàng, số lượng, chi phí ước tính, trung tâm chi phí và lý do thường thuộc nhóm này. Chỉ bắt buộc tệp đính kèm khi giá trị chi tiêu vượt một ngưỡng nhất định hoặc với các danh mục như thuê bao phần mềm.

Các trường điều kiện giúp biểu mẫu dễ sử dụng hơn. Yêu cầu phần mềm có thể hỏi số người dùng, ngày gia hạn và liệu phần mềm có xử lý dữ liệu khách hàng hay không. Yêu cầu mặt hàng vật lý có thể hỏi địa chỉ giao hàng. Mỗi quy trình phê duyệt mua hàng nhận được đúng thông tin cần thiết mà không buộc mọi nhân viên phải điền một biểu mẫu dài.

Trước khi triển khai, hãy gửi ba yêu cầu thử nghiệm: một mặt hàng trong danh mục, một giao dịch mua từ nhà cung cấp mới và một dịch vụ định kỳ. Nếu người phê duyệt vẫn hỏi một câu hiển nhiên, hãy thêm trường hoặc làm rõ trường hiện có.

Tạo danh mục giúp gửi yêu cầu nhanh hơn

Danh mục loại bỏ công việc lặp lại. Thay vì yêu cầu mỗi nhân viên tự mô tả máy tính xách tay, giấy phép phần mềm hoặc ghế văn phòng, hãy cung cấp một danh sách ngắn các lựa chọn đã được phê duyệt.

Mỗi mặt hàng trong danh mục nên có mô tả dễ hiểu, giá đơn vị thông thường và nhà cung cấp ưu tiên. Thêm những chi tiết giúp tránh phải hỏi lại, chẳng hạn như mã hàng, thời hạn hợp đồng, kích cỡ có sẵn hoặc việc quản lý có cần xác nhận nhu cầu hay không.

Ví dụ, mục «Máy tính xách tay tiêu chuẩn» có thể ghi mẫu máy, nhà cung cấp được phê duyệt, giá 1.200 USD và bảo hành ba năm. Người yêu cầu chọn số lượng rồi giải thích ai sẽ sử dụng. Bộ phận mua sắm lần nào cũng nhận được cùng một bộ thông tin hữu ích.

Giữ lựa chọn đơn giản

Đừng biến danh mục thành bản sao của mọi trang web nhà cung cấp. Hãy bắt đầu với những mặt hàng nhân viên thường đặt, sau đó thêm mục mới khi cùng một yêu cầu nhập tự do xuất hiện nhiều lần. Một danh mục dài và sắp xếp kém sẽ tạo thêm chậm trễ.

Nhóm mặt hàng theo các danh mục quen thuộc như phần mềm, thiết bị, vật tư văn phòng và dịch vụ chuyên môn. Dùng chức năng tìm kiếm và tên ngắn để mọi người tìm thấy mặt hàng trước khi bắt đầu gõ mô tả.

Một mục trong danh mục thường cần tên mặt hàng, mô tả, giá đơn vị hoặc khoảng giá dự kiến, nhà cung cấp ưu tiên, đơn vị tính và các hạn chế. Ví dụ, một gói thuê bao có thể hiển thị «mỗi người dùng, mỗi tháng» và ghi rõ rằng quản lý phải phê duyệt.

Chừa chỗ cho ngoại lệ

Đôi khi nhân viên sẽ cần một thứ không có trong danh sách. Hãy giữ tùy chọn nhập tự do, nhưng yêu cầu đủ thông tin để bước tiếp theo có thể bắt đầu: nhu cầu, chi phí ước tính, nhà cung cấp nếu biết và lý do kinh doanh.

Hãy xem các yêu cầu nhập tự do là một hàng đợi cần xem xét, không phải là dấu hiệu danh mục thất bại. Bộ phận mua sắm có thể so sánh báo giá, phê duyệt nhà cung cấp hoặc quyết định thêm mặt hàng vào danh mục cho những lần yêu cầu sau.

Trong ứng dụng mua sắm không cần mã được xây dựng bằng AppMaster, việc chọn một mặt hàng trong danh mục có thể tự điền giá, nhà cung cấp và các trường yêu cầu. Nhờ đó, quy trình phê duyệt ngân sách có dữ liệu sạch hơn và giảm công việc sửa lỗi trước khi bàn giao sang đơn đặt hàng.

Thêm kiểm tra ngân sách trước bước phê duyệt

Yêu cầu cần thể hiện bối cảnh tài chính trước khi bất kỳ ai bắt đầu nhiệm vụ phê duyệt. Yêu cầu người gửi chọn phòng ban và trung tâm chi phí, sau đó ghi nhận số tiền và loại tiền tệ. Hệ thống có thể dùng các trường này để tìm ngân sách phù hợp.

Hãy giữ bước kiểm tra đơn giản đối với người yêu cầu. Họ nên nhìn thấy tổng giá trị yêu cầu, ngân sách còn lại và số tiền còn lại sau khi phê duyệt. Một thông báo như «Yêu cầu này vượt ngân sách còn lại 420 USD» giúp quản lý không phải phát hiện vấn đề sau đó trong chuỗi email.

Bộ phận tài chính cần chịu trách nhiệm về số liệu ngân sách. Nhân viên có thể cập nhật số tiền được phê duyệt cho từng phòng ban hoặc trung tâm chi phí vào đầu kỳ và điều chỉnh khi kế hoạch thay đổi. Hệ thống yêu cầu mua hàng nội bộ cũng cần theo dõi các yêu cầu đã được phê duyệt nhưng chưa trở thành hóa đơn. Nếu không, một nhóm có thể trông như vẫn còn ngân sách dù thực tế đã cam kết số tiền đó.

Kiểm tra tổng giá trị thực tế của yêu cầu

Hãy tính số tiền mà bộ phận mua sắm thực sự phải trả. Bao gồm số lượng, giá đơn vị, thuế, phí vận chuyển, phí thiết lập và các khoản định kỳ khi có. Một gói thuê bao phần mềm giá 900 USD cộng phí triển khai 150 USD là một yêu cầu trị giá 1.050 USD.

Chạy quy trình phê duyệt ngân sách ngay khi người yêu cầu gửi biểu mẫu, trước khi hệ thống chuyển yêu cầu cho người phê duyệt. Cách này tránh lãng phí thời gian xem xét và cho phép người yêu cầu sửa trung tâm chi phí, giảm đơn hàng hoặc giải thích ngoại lệ.

Với ứng dụng mua sắm không cần mã, đây có thể là một quy tắc trực quan: đọc trung tâm chi phí đã chọn, so sánh tổng giá trị yêu cầu với ngân sách còn lại rồi lưu kết quả vào hồ sơ yêu cầu. AppMaster có thể mô hình hóa dữ liệu yêu cầu, tạo logic trong Business Process Editor và hiển thị kết quả trên biểu mẫu nội bộ.

Xác định cách xử lý yêu cầu vượt ngân sách

Đừng để yêu cầu vượt ngân sách ở một trạng thái không rõ ràng. Hãy tạo một tuyến xử lý phù hợp với chính sách chi tiêu. Bạn có thể trả yêu cầu về cho người gửi kèm phần chênh lệch, chuyển cho chủ ngân sách xin ngoại lệ, gửi nhu cầu khẩn cấp đến tài chính hoặc giữ lại đến kỳ ngân sách tiếp theo cùng ngày và lý do cụ thể.

Ghi lại kết quả kiểm tra ngân sách và mọi quyết định về ngoại lệ. Khi bộ phận mua sắm bắt đầu đặt hàng, nhân viên có thể biết khoản chi có phù hợp với ngân sách ban đầu hay không và ai đã phê duyệt phần vượt thêm. Tài chính cũng có thể giải thích vì sao một trung tâm chi phí vượt kế hoạch.

Thiết lập tuyến phê duyệt dễ theo dõi

Hệ thống yêu cầu mua hàng nội bộ cần có quy tắc điều hướng trước khi bất kỳ ai gửi yêu cầu. Gửi từng yêu cầu đến những người có thể đánh giá khoản chi, thay vì một hộp thư chung chỉ được kiểm tra thỉnh thoảng.

Dựa tuyến xử lý vào thông tin đã có trong biểu mẫu. Phòng ban, trung tâm chi phí, danh mục mua hàng và tổng giá trị thường cung cấp đủ bối cảnh. Một yêu cầu mua vật tư văn phòng trị giá 40 USD có thể chỉ cần quản lý nhóm. Một hợp đồng phần mềm mới có thể cần chủ ngân sách, CNTT, bảo mật và mua sắm.

Giữ tuyến ngắn khi rủi ro thấp. Thêm người phê duyệt «cho chắc» sẽ biến một quy trình phê duyệt mua hàng đơn giản thành chuỗi chậm trễ. Mỗi người phê duyệt cần có lý do rõ ràng để phê duyệt, từ chối hoặc yêu cầu thêm thông tin.

Dùng các quy tắc dễ dự đoán

Nhân viên nên biết yêu cầu sẽ đi đâu trước khi gửi. Các quy tắc dễ dự đoán cũng giảm tranh luận khi yêu cầu bị chậm.

Ví dụ, một công ty có thể dùng các quy tắc sau:

• Yêu cầu dưới 500 USD gửi cho quản lý phòng ban.
• Yêu cầu từ 500 đến 5.000 USD gửi cho quản lý và chủ trung tâm chi phí.
• Yêu cầu về phần mềm và dịch vụ đám mây cũng gửi cho CNTT hoặc bộ phận bảo mật.
• Yêu cầu trên 5.000 USD gửi cho bộ phận mua sắm sau khi được phê duyệt ngân sách.
• Mua sắm tài sản cố định gửi cho chủ tài chính bất kể số tiền.

Quy tắc không nhất thiết phải giống hệt ở mọi phòng ban. Bộ phận kinh doanh có thể cần phê duyệt cho các công cụ tiếp xúc khách hàng, trong khi vận hành có thể cần thêm bước kiểm tra thiết bị. Hãy dùng cùng một logic cơ bản trên toàn công ty để nhân viên không phải học lại quy trình mỗi lần.

Dự phòng trường hợp vắng mặt và giữ hồ sơ đầy đủ

Mỗi người phê duyệt cần có người thay thế. Nếu quản lý nghỉ phép, hệ thống nên gửi yêu cầu mới cho người thay thế đã chỉ định hoặc cho phép quản trị viên phân công lại công việc đang chờ. Người yêu cầu không nên phải tìm người khác qua email hoặc trò chuyện.

Đặt mục tiêu phản hồi. Ví dụ, thông báo cho người phê duyệt sau hai ngày làm việc và gửi yêu cầu cho người thay thế sau năm ngày. Việc nhắc cấp cao hơn cần đưa yêu cầu tiến lên nhưng vẫn giữ tuyến ban đầu và lịch sử quyết định.

Giữ mọi quyết định trong hồ sơ yêu cầu. Hiển thị ai đã phê duyệt hoặc từ chối, thời điểm thực hiện và bình luận của họ. Một lý do từ chối như «Dùng giấy phép nhóm hiện có cho đến kỳ gia hạn» giúp người yêu cầu biết bước tiếp theo và cung cấp bối cảnh cho bộ phận mua sắm.

AppMaster cho phép đội ngũ mô hình hóa các trường yêu cầu, xây dựng logic phê duyệt trong quy trình nghiệp vụ trực quan và hiển thị trạng thái hiện tại cho người yêu cầu. Trách nhiệm luôn rõ ràng thay vì biến mất trong các chuỗi email.

Xây dựng luồng yêu cầu từng bước

Một luồng yêu cầu rõ ràng giúp các giao dịch đơn giản không biến mất trong email. Mỗi trạng thái cần mô tả tình hình hiện tại và mỗi người cần biết khi nào mình phải hành động.

Bắt đầu với một nhóm trạng thái nhỏ: Bản nháp, Đã gửi, Đã phê duyệt, Bị từ chối, Đã đặt hàng và Đã nhận. Tránh các nhãn gần như có cùng ý nghĩa, chẳng hạn «đang chờ xem xét» và «đang chờ phê duyệt». Mọi người sẽ dùng chúng không nhất quán và báo cáo sẽ bị ảnh hưởng.

Yêu cầu bắt đầu ở trạng thái bản nháp. Người yêu cầu có thể lưu, thay đổi mặt hàng hoặc số lượng hay xóa yêu cầu. Ở giai đoạn này, hệ thống không nên gửi thông báo hoặc giữ ngân sách.

Khi người yêu cầu gửi biểu mẫu, trạng thái chuyển sang Đã gửi. Khóa giá, thông tin nhà cung cấp và số tiền yêu cầu trừ khi ai đó trả yêu cầu về để chỉnh sửa. Người phê duyệt có thể phê duyệt, từ chối hoặc trả lại kèm bình luận ngắn.

Sau khi phê duyệt, chuyển yêu cầu cho bộ phận mua sắm. Nhân viên chỉ nên đánh dấu Đã đặt hàng sau khi tạo hoặc đặt đơn mua hàng. Quyền được chi tiền không chứng minh rằng ai đó đã mua mặt hàng.

Khi hàng đến, quyền truy cập dịch vụ bắt đầu hoặc thuê bao được xác nhận, người nhận đánh dấu yêu cầu là Đã nhận. Nhờ vậy, tài chính và người yêu cầu có hồ sơ đáng tin cậy về những gì đã nhận.

Giao cho từng vai trò các hành động rõ ràng

Một hệ thống yêu cầu mua hàng nội bộ hoạt động tốt nhất khi mỗi thay đổi trạng thái có người phụ trách. Không cho phép mọi người dùng chỉnh sửa mọi yêu cầu đã gửi.

• Người yêu cầu tạo bản nháp, gửi yêu cầu và sửa các yêu cầu được trả lại.
• Quản lý và chủ ngân sách phê duyệt, từ chối hoặc trả lại yêu cầu kèm lý do.
• Nhân viên mua sắm ghi thông tin nhà cung cấp, chi tiết đơn đặt hàng và trạng thái đã đặt hàng.
• Nhân viên nhận hàng xác nhận giao hàng và đánh dấu yêu cầu là đã nhận.
• Nhân viên tài chính xem toàn bộ lịch sử và sửa một số trường giới hạn, chẳng hạn mã tham chiếu kế toán.

Quản trị viên nên xử lý các ngoại lệ, chẳng hạn người phê duyệt rời công ty hoặc yêu cầu trùng lặp. Giữ nhật ký kiểm tra cho mọi thay đổi trạng thái, bao gồm người thực hiện, thời điểm và bình luận nếu có.

Thông báo khi ai đó cần hành động

Gửi thông báo khi một yêu cầu đã gửi đến người phê duyệt. Bao gồm tiêu đề yêu cầu, số tiền, phòng ban và quyết định cần đưa ra. Một thông báo mơ hồ như «Bạn có nhiệm vụ mới» làm chậm hành động vì người nhận phải tìm thêm bối cảnh.

Thông báo cho người yêu cầu khi ai đó phê duyệt, từ chối hoặc trả lại yêu cầu. Bắt buộc có bình luận khi từ chối hoặc trả lại. «Quý này chưa có ngân sách» giúp người yêu cầu biết cần làm gì, còn «Không» thì không.

Bộ phận mua sắm nên nhận thông báo sau khi phê duyệt cuối cùng. Người yêu cầu nên được cập nhật khi bộ phận mua sắm đánh dấu yêu cầu là Đã đặt hàng và Đã nhận. Nếu không ai xử lý sau một khoảng thời gian nhất định, hãy nhắc người phụ trách hiện tại và gửi bản sao cho người phê duyệt dự phòng.

Với AppMaster, ứng dụng mua sắm không cần mã có thể mô hình hóa trạng thái trong Data Designer và áp dụng các thay đổi được phép trong Business Process Editor. Mỗi lần bàn giao đều nằm trong hồ sơ thay vì phụ thuộc vào trí nhớ của một người.

Ví dụ: yêu cầu thuê bao phần mềm

Maya, một quản lý marketing, cần 15 thuê bao cho công cụ lập kế hoạch mạng xã hội. Cô mở hệ thống yêu cầu mua hàng nội bộ và chọn công cụ từ danh mục phần mềm thay vì tạo yêu cầu nhập tự do.

Mục trong danh mục có nhà cung cấp, loại gói, giá mỗi người dùng, chu kỳ thanh toán và nhóm phụ trách hợp đồng. Maya nhập 15 tài khoản, chọn trung tâm chi phí Marketing và thêm lý do: nhóm cần lên lịch chung và phê duyệt các bài đăng chiến dịch.

Ứng dụng tính chi phí cả năm trước khi cô gửi yêu cầu. Marketing còn đủ ngân sách phần mềm nên yêu cầu vượt qua bước kiểm tra ngân sách. Nếu ngân sách không đủ, ứng dụng có thể dừng yêu cầu và yêu cầu Maya chọn trung tâm chi phí khác hoặc xin thêm ngân sách. Cách này ngăn quản lý phê duyệt một giao dịch mà tài chính không thể thanh toán.

Trưởng phòng của Maya nhận được yêu cầu vì khoản chi nằm trong giới hạn của quản lý. Màn hình phê duyệt hiển thị chi phí, số người dùng, lý do kinh doanh và số dư ngân sách. Người quản lý phê duyệt yêu cầu.

Bộ phận mua sắm nhận được hồ sơ đầy đủ gồm nhà cung cấp và gói dịch vụ, tổng chi phí năm và ngày gia hạn, trung tâm chi phí và kết quả ngân sách, lý do của Maya cùng thời điểm phê duyệt của quản lý. Điều phối viên mua sắm kiểm tra xem công ty đã có thỏa thuận với nhà cung cấp hay chưa. Nếu đã có, điều phối viên tạo đơn đặt hàng từ thông tin đã lưu. Nếu chưa, họ bắt đầu quy trình xem xét nhà cung cấp trước khi đặt hàng.

Điều phối viên ghi số đơn đặt hàng và đánh dấu yêu cầu là Đã đặt hàng. Maya có thể xem cập nhật mà không cần hỏi bộ phận mua sắm. Khi nhà cung cấp xác nhận 15 giấy phép, điều phối viên đánh dấu yêu cầu là Đã nhận và ghi lại người sẽ quản trị tài khoản.

Luồng này giữ từng quyết định gắn với yêu cầu. Tài chính có thể biết vì sao nhóm mua phần mềm, ngân sách nào đã chi trả và ai phê duyệt khoản chi.

Những sai lầm làm chậm việc mua sắm

Một quy trình mua hàng có thể trông đơn giản trên sơ đồ nhưng vẫn khiến người dùng khó chịu. Vấn đề thường xuất hiện khi hệ thống coi mọi yêu cầu đều đặc biệt hoặc không kiểm soát được các thay đổi sau phê duyệt.

Gửi mọi yêu cầu lên cấp cao

Nhiều nhóm gửi mọi yêu cầu cho một quản lý cấp cao. Người đó trở thành điểm nghẽn cho các mặt hàng thông thường như bàn phím thay thế, gia hạn phần mềm hàng tháng hoặc vật tư dưới một hạn mức nhỏ. Nếu quản lý vắng mặt hai ngày, tất cả đều phải chờ.

Hãy ghép tuyến phê duyệt với chi phí, phòng ban và loại yêu cầu. Trưởng nhóm có thể phê duyệt một mặt hàng tiêu chuẩn trong danh mục dưới hạn mức nhất định. Chủ phòng ban có thể xem xét các giao dịch lớn hơn. Tài chính có thể tham gia khi yêu cầu ảnh hưởng đến ngân sách hoặc vượt hạn mức. Lãnh đạo cấp cao chỉ nên nhận các trường hợp ngoại lệ, không phải yêu cầu thông thường.

Cho phép thay đổi yêu cầu đã phê duyệt mà không có thông báo

Phê duyệt cuối cùng áp dụng cho một mặt hàng, số lượng, nhà cung cấp và mức giá cụ thể. Nếu các chi tiết đó thay đổi, phê duyệt có thể không còn phù hợp với khoản chi.

Đặt quy tắc cho các chỉnh sửa quan trọng. Thay đổi từ 10 lên 12 giấy phép hoặc từ 500 lên 1.200 USD cần đưa yêu cầu trở lại người xem xét liên quan. Các ghi chú nhỏ như người liên hệ giao hàng có thể tiếp tục được chỉnh sửa mà không cần khởi động lại quy trình phê duyệt mua hàng.

Ứng dụng mua sắm không cần mã có thể giữ lịch sử chỉnh sửa và mở lại bước phê duyệt khi các trường được kiểm soát thay đổi. Nhờ vậy, tài chính không bị bất ngờ khi so sánh số tiền đã phê duyệt với hóa đơn.

Đóng yêu cầu quá sớm

Phê duyệt không phải là điểm kết thúc của việc mua sắm. Đội ngũ mua sắm vẫn cần ghi nhà cung cấp, số đơn đặt hàng, giá cuối cùng, ngày đặt và trạng thái giao hàng. Nếu ai đó đóng yêu cầu trước khi có những thông tin này, nhân viên sẽ phải tìm lại trong email và bảng tính.

Dùng các trạng thái rõ ràng như Đã phê duyệt, Đã đặt hàng, Đã nhận và Đã đóng. Chỉ chuyển sang Đã đóng sau khi bộ phận mua sắm ghi chi tiết đơn hàng và xác nhận việc bàn giao. Một thuê bao hàng năm đã được phê duyệt nên giữ ở trạng thái Đã phê duyệt cho đến khi người mua ghi nhận đơn hàng hoặc mã tham chiếu gia hạn.

Sự phân biệt này giúp báo cáo đáng tin cậy hơn. Các nhóm có thể biết yêu cầu nào đã phê duyệt nhưng vẫn cần xử lý, đơn hàng nào đang chờ giao và giao dịch nào đã hoàn tất.

Kiểm tra nhanh trước khi triển khai

Một lần chạy thử ngắn có thể phát hiện phần lớn vấn đề trước khi nhân viên phụ thuộc vào hệ thống yêu cầu mua hàng nội bộ. Hãy mời một nhóm nhỏ gửi các yêu cầu thực tế như vật tư văn phòng, gia hạn phần mềm và hợp đồng dịch vụ. Bao gồm người yêu cầu, người phê duyệt và nhân viên tạo đơn đặt hàng.

Mỗi yêu cầu cần có một người phụ trách rõ ràng và trạng thái dễ thấy. Người phụ trách phải thay đổi khi trách nhiệm chuyển từ người yêu cầu sang quản lý hoặc người mua. Nhãn trạng thái cần giải thích điều gì đã xảy ra, chẳng hạn Bản nháp, Đã gửi, Đã phê duyệt, Bị từ chối hoặc Đã bàn giao cho bộ phận mua sắm.

Trước khi mở ứng dụng cho tất cả mọi người, hãy xác nhận rằng mọi yêu cầu đều hiển thị người phụ trách, trạng thái hiện tại, số tiền và người phê duyệt tiếp theo. So sánh các quy tắc phê duyệt với hạn mức chi tiêu và quy định thực tế của từng phòng ban. Kiểm tra xem bộ phận mua sắm có thể thấy nhà cung cấp, giá báo, số lượng được phê duyệt và ngày cần giao hay không.

Thử một yêu cầu vượt ngân sách và xác nhận ứng dụng sẽ chặn yêu cầu hoặc gửi đến đúng người. Từ chối một yêu cầu khác với lý do rõ ràng, sau đó xác nhận người yêu cầu nhận được lý do và có thể cập nhật biểu mẫu.

Dùng số liệu thực tế để kiểm tra ngân sách. Cho một nhóm ngân sách tháng còn lại là 2.000 USD, sau đó gửi yêu cầu trị giá 2.400 USD. Quyết định xem hệ thống sẽ chặn yêu cầu, xin tài chính phê duyệt hay cho phép chủ ngân sách điều chuyển tiền. Tất cả người liên quan phải nhìn thấy cùng một kết quả.

Cũng cần kiểm tra các thay đổi sau phê duyệt. Người yêu cầu có thể tăng đơn hàng từ 10 lên 15 màn hình, hoặc nhà cung cấp có thể tăng giá báo. Quy trình phê duyệt mua hàng phải đưa yêu cầu đi phê duyệt lại hoặc chỉ rõ những thay đổi nào không cần xem xét thêm. Thay đổi âm thầm sẽ tạo tranh chấp về sau.

Cuối cùng, hãy thử nghiệm bước bàn giao sang đơn đặt hàng. Bộ phận mua sắm cần nhận thông tin đã phê duyệt trong một nơi thay vì nhập lại từ email hoặc trò chuyện. Trong AppMaster, đội ngũ có thể thử các luồng bằng hồ sơ mẫu và điều chỉnh quy tắc trực quan trước khi xuất bản ứng dụng. Giữ một nhật ký ngắn về các lần kiểm thử thất bại, sửa quy tắc gây ra từng lỗi rồi chạy lại.

Chọn bước tiếp theo

Hãy bắt đầu với một phòng ban có nhiều giao dịch lặp lại và chuỗi phê duyệt dễ quản lý. Phần mềm CNTT, vật tư văn phòng hoặc thuê bao marketing là những điểm khởi đầu phù hợp. Cung cấp cho nhóm đó một danh mục ngắn với các mặt hàng phổ biến, giá ước tính và thông tin bộ phận mua sắm cần.

Giữ phiên bản đầu tiên tập trung. Người yêu cầu cần gửi được một nhu cầu rõ ràng, người phê duyệt cần thấy chi phí và trạng thái ngân sách, còn bộ phận mua sắm cần nhận được hồ sơ đầy đủ sau phê duyệt. Chỉ thêm các loại yêu cầu đặc biệt sau khi luồng cơ bản hoạt động ổn định.

Sau vài tuần đầu, hãy hỏi những người sử dụng từng phần của hệ thống yêu cầu mua hàng nội bộ để lấy phản hồi. Người yêu cầu có thể chỉ ra các trường gây khó hiểu. Người phê duyệt có thể nói họ cần thêm bối cảnh ở đâu. Nhân viên mua sắm có thể chỉ ra thông tin nhà cung cấp còn thiếu hoặc các yêu cầu vẫn đến ngoài ứng dụng.

Dùng phản hồi đó để xóa các trường không ai dùng, thêm mục danh mục cho giao dịch lặp lại, làm rõ hạn mức phê duyệt, hiển thị người chịu trách nhiệm tiếp theo và ghi lại lý do một yêu cầu được trả lại hoặc từ chối.

AppMaster có thể giúp đội ngũ tạo ứng dụng mua sắm không cần mã mà không phải bắt đầu từ một dự án kỹ thuật trống. Đội ngũ có thể xây dựng biểu mẫu yêu cầu cho nhân viên, dùng Business Process Editor cho việc kiểm tra ngân sách và tuyến phê duyệt, đồng thời tạo màn hình riêng cho quản lý và nhân viên mua sắm. Data Designer có thể lưu danh mục, phòng ban, nhà cung cấp, ngân sách và yêu cầu trong cùng một nơi.

Một chương trình thử nghiệm nhỏ nhanh chóng làm lộ ra các vấn đề thực tế. Nếu nhân viên vẫn gửi yêu cầu qua email, hãy tìm hiểu nguyên nhân trước khi thêm quy tắc. Hãy xây dựng một tuyến yêu cầu mà mọi người chọn vì nó rõ ràng và nhanh hơn cách làm tạm thời. Khi chương trình thử nghiệm hoạt động trơn tru, điều chỉnh cấu trúc cho phòng ban tiếp theo, đồng thời giữ danh mục và quy tắc phê duyệt gắn với cách phòng ban đó chi tiêu.