Xây dựng ứng dụng yêu cầu công tác với giới hạn phê duyệt

Vì sao yêu cầu công tác của cả nhóm thường bị đình trệ

Một yêu cầu công tác thường bắt đầu với vài thông tin đơn giản: ngày đi, điểm đến và chi phí ước tính. Sau đó, thông tin bị phân tán giữa email, trò chuyện và bảng tính. Nhân viên gửi các lựa chọn chuyến bay qua email, thêm chi phí khách sạn vào bảng tính và nhắc đến cuộc gặp khách hàng trong tin nhắn. Quản lý chỉ thấy một phần yêu cầu và phải hỏi thêm những phần còn thiếu.

Những khoảng trống nhỏ này gây ra chậm trễ. Giá vé thay đổi trong lúc ai đó tìm tệp đính kèm. Bộ phận tài chính không biết tổng chi phí đã bao gồm hành lý, phương tiện đi lại tại địa phương hay thuế khách sạn chưa. Nhân viên có thể đặt vé trước khi được phê duyệt vì giá vé sắp tăng.

Email cũng khiến việc xác định phiên bản hiện tại trở nên khó khăn. Nhân viên có thể cập nhật lịch trình sau khi quản lý phê duyệt, trong khi quyết định phê duyệt vẫn dựa trên chi phí ước tính trước đó. Bảng tính dùng chung giúp dễ theo dõi hơn, nhưng hiếm khi ghi lại ai đã phê duyệt khoản chi, phê duyệt lúc nào hoặc sau đó có gì thay đổi.

Giới hạn phê duyệt không rõ ràng cũng thường gây chậm trễ. Quản lý có thể phê duyệt chuyến đi 900 USD mà không biết bộ phận tài chính phải xem xét các chuyến đi trên 750 USD. Hoặc nhân viên gửi mọi yêu cầu đến trưởng bộ phận dù quản lý trực tiếp của họ có thể phê duyệt. Cả hai cách đều làm quy trình chậm hơn và dẫn đến các quyết định thiếu nhất quán.

Ngoại lệ chính sách cần được hiển thị rõ như thông tin chuyến đi. Chuyến bay muộn, giá khách sạn cao hơn gần địa điểm gặp khách hàng hoặc chuyến đi gấp đều có thể hợp lý. Vấn đề bắt đầu khi phần giải thích nằm trong một tin nhắn riêng hoặc không được ghi lại. Sau đó, bộ phận tài chính nhìn thấy một khoản chi vượt ngân sách nhưng không biết vì sao quyết định đó được đưa ra.

Một ứng dụng yêu cầu công tác thực tế giữ quyết định trong cùng một hồ sơ. Mỗi yêu cầu nên có chi phí hành trình ước tính, mục đích công tác, tổng dự kiến, lý do ngoại lệ nếu cần và lịch sử phê duyệt. Sau chuyến đi, hồ sơ đó có thể chứa các liên kết theo dõi chi phí để cả nhóm so sánh khoản chi thực tế với kế hoạch đã được duyệt.

Mục tiêu rất đơn giản: cung cấp cho nhân viên một quy trình rõ ràng, cho người phê duyệt những thông tin cần thiết và cho bộ phận tài chính một hồ sơ có thể kiểm tra mà không phải tìm trong hộp thư.

Xác định trách nhiệm trước khi xây dựng

Ứng dụng yêu cầu công tác hoạt động tốt nhất khi mỗi người có trách nhiệm rõ ràng. Hãy bắt đầu với nhân viên lên kế hoạch cho chuyến đi, quản lý kiểm tra tính cần thiết về mặt công việc và bộ phận tài chính xem xét ngân sách, chính sách. Một số nhóm cũng cần điều phối viên công tác để đặt các chuyến đi đã được duyệt hoặc người phê duyệt cấp điều hành cho những khoản chi lớn.

Giữ vai trò tập trung. Nhân viên tạo yêu cầu và thêm ngày đi, điểm đến, chi phí ước tính cùng lý do công tác. Quản lý phê duyệt, từ chối hoặc yêu cầu chỉnh sửa. Bộ phận tài chính xem xét các yêu cầu vượt giới hạn chi tiêu, vi phạm chính sách hoặc cần cách thanh toán đặc biệt. Sau chuyến đi, nhân viên thêm hồ sơ chi phí hoặc liên kết biên lai.

Quyết định nội dung có thể thay đổi sau khi gửi

Nhân viên thường cần sửa chi phí chuyến bay hoặc thay đổi ngày họp. Cho phép họ tự do chỉnh sửa bản nháp, sau đó áp dụng quy tắc rõ ràng khi yêu cầu đã được gửi. Những thay đổi nhỏ trước khi phê duyệt thường không có vấn đề. Nếu tổng chi phí, điểm đến hoặc ngày đi thay đổi sau khi phê duyệt, hãy gửi yêu cầu qua quy trình xem xét lại.

Ví dụ, nhân viên gửi yêu cầu chuyến đi 900 USD đến Chicago và được quản lý phê duyệt. Nếu chi phí tăng lên 1.450 USD do giá vé tăng, ứng dụng nên cảnh báo quản lý và giữ lại số tiền trước đó cùng lý do thay đổi.

Không để nhân viên thay đổi yêu cầu đã được duyệt mà không có thông báo. Bộ phận tài chính cần so sánh ngân sách được duyệt với hồ sơ chi phí cuối cùng, còn các thay đổi âm thầm khiến việc so sánh này không đáng tin cậy.

Đặt ranh giới phê duyệt rõ ràng

Hãy viết các giới hạn phê duyệt trước khi xây dựng biểu mẫu hoặc tự động hóa. Có thể dựa trên chi phí chuyến đi, phòng ban hoặc cả hai. Quản lý kinh doanh có thể phê duyệt các chuyến thăm khách hàng thông thường, còn bộ phận tài chính xem xét chuyến đi quốc tế hoặc yêu cầu vượt một mức nhất định.

Một chính sách đơn giản có thể như sau:

• Quản lý phê duyệt các chuyến đi tối đa 1.000 USD trong phòng ban của mình.
• Trưởng bộ phận phê duyệt yêu cầu từ 1.001 đến 3.000 USD.
• Bộ phận tài chính xem xét yêu cầu trên 3.000 USD, chuyến đi quốc tế và các ngoại lệ chính sách.
• Ban điều hành phê duyệt chuyến công tác vượt ngân sách của phòng ban.

Hãy điều chỉnh các giới hạn này theo cách công ty đang ra quyết định chi tiêu. Một công ty nhỏ hiếm khi cần đến năm cấp phê duyệt. Nếu quy trình quá chậm, mọi người sẽ tìm cách обход qua nó.

Trong ứng dụng công tác no-code xây dựng bằng AppMaster, bạn có thể lưu phòng ban, quản lý và giới hạn phê duyệt của từng nhân viên trong mô hình dữ liệu. Sau đó, quy trình có thể phân luồng yêu cầu dựa trên chi phí ước tính và thông tin chuyến đi. Bộ phận tài chính chỉ thấy những yêu cầu cần xử lý, còn các chuyến đi thông thường được giải quyết nhanh hơn.

Cũng cần quyết định ai có thể ghi đè một lần từ chối, hủy chuyến đi đã được duyệt hoặc tiếp quản khi quản lý vắng mặt. Những quy tắc nhỏ này giúp yêu cầu không bị bỏ quên trước hạn đặt vé.

Chọn các trường cho từng yêu cầu công tác

Ứng dụng yêu cầu công tác cần đủ thông tin để đưa ra quyết định nhanh mà không biến một chuyến đi ngắn thành biểu mẫu dài. Hãy bắt đầu với những thông tin giải thích ai đi, đi đâu và vì sao chuyến đi cần thiết.

Đặt tên nhân viên và nhóm ở gần đầu biểu mẫu. Nếu một người gửi thay cho nhân viên khác, hãy thêm cả trường người yêu cầu và người đi công tác. Ghi điểm đến dưới dạng thành phố và quốc gia thay vì một câu tự do để sau này bộ phận tài chính có thể nhóm các chuyến đi. Mục đích cụ thể cũng rất hữu ích: «Gặp khách hàng để lập kế hoạch triển khai tháng 5» cung cấp nhiều bối cảnh hơn «Gặp khách hàng».

Bắt buộc nhập ngày khởi hành và ngày trở về. Chỉ thêm giờ khi nhóm cần thông tin này để đặt vé hoặc tính công tác phí. Ứng dụng có thể tự tính số đêm, giúp người phê duyệt hiểu rõ hơn trước khi mở toàn bộ yêu cầu.

Tách riêng các khoản ước tính

Dùng các trường số riêng cho phương tiện di chuyển, khách sạn và bữa ăn. Một tổng duy nhất che khuất nơi tiền được sử dụng và khiến việc so sánh với chính sách công tác khó hơn. Thêm phương tiện tại địa phương khi taxi, xe thuê hoặc tàu tạo ra chi phí đáng kể.

Tự động tính tổng chi phí ước tính. Nhân viên đi Berlin trong hai đêm có thể nhập 320 USD cho chuyến bay, 440 USD cho khách sạn, 120 USD cho bữa ăn và 60 USD cho phương tiện địa phương. Yêu cầu hiển thị tổng 940 USD, đồng thời vẫn cho thấy từng khoản chi.

Dùng loại tiền mà bộ phận tài chính yêu cầu. Với chuyến đi quốc tế, hãy thêm loại tiền đề nghị và số tiền quy đổi ước tính theo đồng tiền nội địa. Nhờ vậy, quản lý không phê duyệt 900 mà không biết đó là USD, euro hay bảng Anh.

Thêm bằng chứng và bối cảnh khi cần

Thêm khu vực tệp đính kèm cho báo giá chuyến bay hoặc khách sạn, thư mời sự kiện và chương trình làm việc với khách hàng. Trường ghi chú có thể lưu những chi tiết không phù hợp với trường tiêu chuẩn, chẳng hạn khách sạn bắt buộc của hội nghị hoặc cuộc họp đã đổi ngày.

Để phần ghi chú là tùy chọn, nhưng yêu cầu tệp đính kèm khi yêu cầu vượt ngưỡng chi phí hoặc có ngoại lệ. Chỉ hiển thị các trường phù hợp trong lúc nhân viên điền biểu mẫu. Cách này giúp yêu cầu thông thường ngắn gọn.

Không yêu cầu biên lai trước chuyến đi. Thay vào đó, thêm trường liên kết chi phí sau chuyến đi để bộ phận tài chính hoặc nhân viên hoàn thành khi chuyến đi kết thúc. Trường này kết nối yêu cầu đã phê duyệt với hồ sơ chi phí cuối cùng.

Xử lý ngoại lệ chính sách mà không che giấu

Ứng dụng nên hiển thị ngoại lệ chính sách từ sớm thay vì chôn chúng trong bình luận hoặc chỉ phát hiện sau khi ai đó đặt vé. Nhân viên vẫn có thể yêu cầu ngoại lệ, nhưng cả người đi và người phê duyệt phải thấy rõ khoản chi tăng thêm hoặc quy tắc bị vi phạm.

Viết quy tắc bằng ngôn ngữ dễ hiểu. Tránh các nhãn mơ hồ như «giá vé hợp lý». Hãy nêu rõ giới hạn và điều kiện: chuyến bay hạng phổ thông cho chuyến đi dưới sáu giờ, phòng khách sạn tối đa 220 USD mỗi đêm và đi tàu khi chi phí thấp hơn chuyến bay ngắn. Đặt ghi chú chính sách ngắn cạnh trường liên quan.

So sánh chi phí nhập vào với quy tắc chính sách. Nếu nhân viên nhập giá khách sạn 310 USD mỗi đêm trong khi giới hạn là 220 USD, hãy hiển thị phần chênh lệch và yêu cầu lý do trước khi gửi. Một trường lý do riêng hiệu quả hơn ô ghi chú chung, nơi mọi người thường quên giải thích ngoại lệ.

Dùng một nhóm lựa chọn lý do ngắn, kèm chỗ nhập chi tiết:

• Không có lựa chọn phù hợp trong giới hạn chính sách
• Địa điểm khách hàng hoặc lịch họp yêu cầu lựa chọn này
• Nhu cầu tiếp cận hoặc y tế
• Lo ngại về an toàn
• Lý do khác, kèm giải thích bằng văn bản

Các ngoại lệ khác nhau cần những người xem xét khác nhau. Quản lý thường có thể phê duyệt giá khách sạn cao hơn khi cuộc gặp khách hàng khiến điều đó cần thiết. Bộ phận tài chính nên xem xét các ngoại lệ ảnh hưởng đến ngân sách, cách xử lý thuế, hoàn trả chi phí hoặc hạn mức chi tiêu của phòng ban. Quy trình phê duyệt công tác nên phân luồng yêu cầu phù hợp thay vì yêu cầu mọi người phê duyệt đánh giá mọi quy tắc.

Ví dụ, nhân viên có thể đến gặp khách hàng trong một hội nghị lớn, khi khách sạn gần đó có giá vượt mức thông thường. Yêu cầu có thể hiển thị giới hạn chuẩn, giá đã chọn, khoản tăng thêm mỗi đêm và lời giải thích của nhân viên. Quản lý quyết định chuyến đi có cần thiết hay không. Bộ phận tài chính chỉ xem xét nếu ngoại lệ vượt ngưỡng trong chính sách công tác.

Giữ chi tiết ngoại lệ hiển thị sau khi gửi. Hiển thị chúng trên màn hình phê duyệt, trong lịch sử phê duyệt và cạnh các liên kết theo dõi chi phí sau chuyến đi. Nếu chi phí cuối cùng khác với ước tính, cả nhóm có thể thấy vì sao quyết định ban đầu cho phép khoản chi cao hơn.

Tạo giới hạn phê duyệt mà mọi người có thể tuân theo

Nhân viên nên dự đoán được yêu cầu sẽ đi qua những ai trước khi gửi. Hãy dựa trên tổng chi phí ước tính của chuyến đi, không chỉ riêng giá vé. Bao gồm chỗ ở, phương tiện địa phương, phí đăng ký và mức chi phí bữa ăn hợp lý. Một chuyến bay 450 USD có thể trở thành chuyến đi 1.600 USD khi cộng các khoản còn lại.

Hiển thị giới hạn ngay trong ứng dụng để nhân viên hiểu vì sao một yêu cầu đến quản lý còn yêu cầu khác đến bộ phận tài chính. Ví dụ:

• Yêu cầu tối đa 750 USD gửi đến quản lý trực tiếp.
• Yêu cầu từ 751 đến 2.500 USD gửi đến quản lý và trưởng bộ phận.
• Yêu cầu trên 2.500 USD gửi đến quản lý, trưởng bộ phận và bộ phận tài chính.
• Mọi yêu cầu ngoài chính sách đều gửi đến bộ phận tài chính, không phụ thuộc chi phí.

Dùng thông tin phòng ban và quản lý của người yêu cầu để tự động chọn người xem xét. Mọi người không cần tìm trong danh sách dài hoặc đoán ai phụ trách quyết định tiếp theo. Nếu quản lý vắng mặt, hãy chỉ định quản lý dự phòng có cùng vai trò phê duyệt.

Bộ phận tài chính cần xem xét nhiều hơn những tổng chi phí cao. Họ cũng có thể cần xem xét ghế cao cấp, điểm đến quốc tế, loại tiền khác hoặc đặt vé vi phạm quy tắc mua trước. Yêu cầu người gửi giải thích ngoại lệ bằng một hoặc hai câu trực tiếp.

Ghi lại mọi quyết định cùng tên người xem xét, quyết định, ngày giờ và bình luận. Bắt buộc có bình luận khi từ chối hoặc phê duyệt ngoại lệ chính sách. Một ghi chú như «Đã phê duyệt vì khách hàng chuyển cuộc họp sang thứ Hai» sẽ cung cấp bối cảnh hữu ích cho nhân viên và bộ phận tài chính sau này.

Lưu các giới hạn trong một bảng chính sách có thể chỉnh sửa thay vì chôn chúng trong logic quy trình. Nhân viên vận hành có thể thay đổi ngưỡng khi ngân sách thay đổi. Gắn các yêu cầu cũ với quy tắc đã áp dụng tại thời điểm người xem xét đưa ra quyết định để lịch sử phê duyệt luôn rõ ràng.

Xây dựng quy trình từng bước

Gán trạng thái rõ ràng cho mọi yêu cầu. Nhân viên cần biết chuyến đi đang ở đâu mà không phải kiểm tra tin nhắn hoặc hỏi bộ phận tài chính. Một quy trình đơn giản là đủ: Bản nháp, Đã gửi, Cần chỉnh sửa, Đã phê duyệt, Đã đặt, Đã hoàn tất và Bị từ chối.

Nhân viên tạo yêu cầu ở trạng thái Bản nháp và có thể tự do chỉnh sửa. Khi gửi, ứng dụng ghi lại ngày gửi và chuyển yêu cầu đến đúng quản lý. Quản lý có thể phê duyệt, từ chối hoặc trả lại kèm bình luận. Giữ các quyết định và bình luận trước đó trong hồ sơ để không ai mất bối cảnh.

Dùng một biểu mẫu yêu cầu, chỉ thay đổi khi cần thêm thông tin. Mọi yêu cầu cần người đi, điểm đến, ngày đi, mục đích công tác, chi phí phương tiện, chi phí chỗ ở và tổng chi phí. Thêm trường liên kết báo giá hoặc tệp đính kèm khi có tài liệu hỗ trợ.

Nếu chi phí khách sạn vượt giới hạn công ty, hiển thị các trường về quy tắc chính sách, số tiền vượt giới hạn và lời giải thích ngắn. Nhân viên nên giải thích vấn đề trước khi quản lý nhận yêu cầu.

Lưu thông tin phê duyệt trong cùng hồ sơ: số tiền được duyệt, ngày quyết định, tên người phê duyệt, bình luận và điều kiện. Quản lý có thể phê duyệt chuyến đi 1.200 USD nhưng yêu cầu nhân viên chọn chuyến bay rẻ hơn. Hãy đặt điều kiện đó trong yêu cầu thay vì để lại trong chuỗi trò chuyện.

Các chế độ xem riêng giúp mọi người tập trung vào công việc. Nhân viên cần thấy bản nháp, yêu cầu đã gửi, quyết định và liên kết chi phí. Quản lý cần thấy các yêu cầu đang chờ quyết định, chi phí ước tính, ngoại lệ và giới hạn phê duyệt. Bộ phận tài chính cần thấy chuyến đi đã duyệt, chi phí dự kiến, trạng thái đặt chỗ và hồ sơ chi phí sau chuyến đi.

AppMaster có thể hỗ trợ cấu trúc này với trình xây dựng giao diện trực quan, mô hình dữ liệu PostgreSQL và các quy trình kiểm tra số tiền, phân luồng yêu cầu và cập nhật trạng thái. Giới hạn quyền chỉnh sửa theo vai trò. Nhân viên không nên thay đổi tổng chi phí đã duyệt mà không qua một lần xem xét khác, trong khi bộ phận tài chính có thể thêm liên kết theo dõi chi phí và đánh dấu yêu cầu là Đã hoàn tất sau khi quyết toán.

Như vậy, cùng một hồ sơ sẽ theo dõi chuyến đi từ chi phí ước tính ban đầu đến báo cáo chi phí cuối cùng.

Ví dụ: chuyến thăm khách hàng có ngoại lệ

Maya cần đến thăm khách hàng trong hai ngày. Cô nhập ngày đi, điểm đến, tên khách hàng và mục đích công tác. Ứng dụng yêu cầu chi phí ước tính cho chuyến bay, khách sạn, phương tiện địa phương và bữa ăn, sau đó tính tổng là 1.860 USD.

Quản lý của Maya có thể phê duyệt chuyến đi tối đa 1.500 USD. Vì chi phí ước tính vượt giới hạn, quy trình gửi yêu cầu đến quản lý để đề xuất, sau đó chuyển đến giám đốc bộ phận để quyết định cuối cùng. Cả hai người xem xét đều thấy lý do cần phê duyệt cấp hai.

Maya chọn khách sạn gần văn phòng khách hàng. Giá mỗi đêm cao hơn giới hạn chính sách 25 USD, nhưng khách sạn rẻ hơn sẽ khiến cô mất thêm 45 phút di chuyển mỗi chiều và không hỗ trợ nhận phòng muộn. Ứng dụng yêu cầu ghi chú ngoại lệ trước khi gửi. Cô viết: «Hội thảo với khách hàng bắt đầu lúc 8 giờ sáng trong cả hai ngày. Khách sạn này nằm trong khoảng cách đi bộ và hỗ trợ nhận phòng muộn sau chuyến bay buổi tối.»

Quản lý thấy bản tóm tắt chi phí, giới hạn phê duyệt và giải thích về khách sạn ở cùng một nơi. Họ phê duyệt yêu cầu và thêm ghi chú cho giám đốc: «Hội thảo với khách hàng cần bắt đầu sớm. Đề xuất phê duyệt.»

Giám đốc nhận được yêu cầu được đánh dấu là vượt giới hạn và có ngoại lệ chính sách. Sau khi phê duyệt, ứng dụng ghi lại quyết định, tên người phê duyệt, thời gian và bình luận. Maya thấy trạng thái rõ ràng thay vì phải thúc giục phê duyệt qua email.

Sau chuyến đi, Maya thêm liên kết đến biên lai chuyến bay, hóa đơn khách sạn và báo cáo chi phí. Cô nhập tổng cuối cùng là 1.792 USD. Cả nhóm có thể so sánh chi phí ước tính với khoản chi thực tế và thấy ngoại lệ khách sạn đã làm tăng 50 USD, trong khi chuyến bay rẻ hơn dự kiến.

Bộ phận tài chính có thể xem báo cáo chi phí mà không cần mở lại toàn bộ cuộc trao đổi. Quản lý cũng có thể biết nhân viên thường yêu cầu ngoại lệ đến mức nào, chuyến đi nào vượt giới hạn và liệu chi phí ước tính có khớp với khoản chi cuối cùng hay không.

Những sai lầm gây ra vấn đề trong phê duyệt

Quy tắc phê duyệt sẽ thất bại khi không phản ánh cách các nhóm thực sự đi công tác. Quản lý kinh doanh có thể cần phê duyệt chuyến thăm khách hàng 1.800 USD, trong khi trưởng nhóm hỗ trợ xử lý các chuyến đi nội địa ngắn dưới 500 USD. Một giới hạn chung cho mọi phòng ban khiến yêu cầu thông thường phải chờ quá lâu hoặc gửi yêu cầu đắt tiền đến người không có thẩm quyền ngân sách phù hợp.

Hãy đặt giới hạn theo phòng ban, vai trò, loại chuyến đi hoặc kết hợp các yếu tố này khi cần. Giữ phiên bản đầu tiên đơn giản. Trưởng nhóm có thể phê duyệt chuyến đi tối đa 750 USD, trưởng bộ phận tối đa 2.500 USD và bộ phận tài chính xử lý mọi khoản cao hơn.

Bảo vệ các con số đã được duyệt. Nếu nhân viên thay đổi chi phí chuyến bay từ 420 lên 690 USD sau khi phê duyệt, hãy gửi yêu cầu quay lại để xem xét. Nếu không, quản lý phê duyệt một số tiền nhưng công ty lại thanh toán số tiền khác.

Hãy kích hoạt phê duyệt lại khi:

• Chi phí ước tính tăng cao hơn số tiền đã duyệt.
• Một khoản thay đổi khiến chuyến đi chuyển sang nhóm phê duyệt cao hơn.
• Nhân viên thêm ngoại lệ chính sách sau khi phê duyệt.
• Điểm đến, ngày đi hoặc mục đích công tác thay đổi.

Tránh dùng ghi chú tự do làm nơi duy nhất ghi ngoại lệ. Bình luận như «đặt vé muộn» không cho quản lý biết yêu cầu vi phạm quy tắc nào. Hãy tạo các trường riêng cho ngoại lệ: loại, lý do, chi phí tăng thêm và giải thích ngắn. Ứng dụng có thể hiển thị ngoại lệ cạnh tổng hành trình thay vì ẩn trong chuỗi trao đổi.

Không đóng chuyến đi ngay khi nhân viên trở về. Giữ chuyến đi mở cho đến khi nhân viên thêm liên kết theo dõi chi phí hoặc xác nhận không còn khoản chi nào. Nếu nhân viên được duyệt 900 USD cho chuyến đi hội nghị nhưng sau đó gửi chi phí 1.040 USD, ứng dụng nên ghi nhận phần chênh lệch và chuyển cho người phụ trách xem xét. Trạng thái như «Đang chờ liên kết chi phí» giúp yêu cầu luôn được nhìn thấy.

Kiểm tra ứng dụng trước khi ra mắt

Hãy thử nghiệm ứng dụng với những người sẽ gửi, phê duyệt và xem xét yêu cầu công tác. Một màn hình có thể trông hoàn chỉnh nhưng vẫn chuyển yêu cầu đến sai người hoặc che khuất chi tiết chi phí mà bộ phận tài chính cần.

Mỗi yêu cầu cần có một người đi hoặc chủ sở hữu được chỉ định, kể cả khi trợ lý nhập yêu cầu thay cho người khác. Người đó nên nhận cập nhật trạng thái và cung cấp thông tin còn thiếu. Cách này tránh nhầm lẫn khi quản lý hỏi về ngày đi, mục đích hoặc chi phí ước tính mới.

Kiểm tra giới hạn phê duyệt bằng những con số thực tế. Tạo một yêu cầu dưới giới hạn của quản lý, một yêu cầu vừa vượt giới hạn và một yêu cầu cao hơn nhiều. Người xem xét phải thấy tổng chi phí ước tính, quy tắc khiến yêu cầu được chuyển đến họ và các quyết định trước đó.

Dùng danh sách kiểm tra ngắn trước khi ra mắt:

• Gửi một chuyến đi thông thường và xác nhận đúng quản lý nhận được yêu cầu.
• Gửi một yêu cầu có ngoại lệ chính sách và xác nhận lý do vẫn hiển thị.
• Từ chối một yêu cầu kèm bình luận, sau đó xác nhận nhân viên có thể sửa và gửi lại.
• Thêm thư mục biên lai sau chuyến đi hoặc URL báo cáo chi phí và xác nhận bộ phận tài chính có thể truy cập.
• Kiểm tra những gì nhân viên, quản lý, bộ phận tài chính và quản trị viên có thể xem và chỉnh sửa.

Cần đặc biệt cẩn thận khi kiểm tra quyền. Nhân viên có thể cần truy cập hành trình và chi phí của chính mình, trong khi quản lý cần các yêu cầu của nhóm. Bộ phận tài chính có thể cần chi phí và liên kết chi phí nhưng không cần các ghi chú riêng tư không liên quan đến hoàn trả. Quản trị viên cần đủ quyền để sửa lỗi phân luồng mà không trở thành người phê duyệt mặc định.

Hãy thử một chuyến thăm khách hàng kéo dài hai ngày với chi phí chuyến bay ước tính 480 USD, khách sạn 360 USD và phương tiện địa phương 150 USD. Sau đó đổi chi phí khách sạn thành 620 USD và đánh dấu là ngoại lệ. Ứng dụng phải giữ lại các chi tiết chi phí và lời giải thích, phân luồng yêu cầu theo tổng chi phí cao hơn và ghi lại quyết định cuối cùng.

Nếu xây dựng ứng dụng bằng AppMaster, hãy kiểm tra các trường hợp này trong phiên bản mà nhóm sẽ sử dụng. Logic trực quan của nền tảng có thể phân luồng yêu cầu theo số tiền, phòng ban hoặc trạng thái ngoại lệ, còn quyền truy cập theo vai trò kiểm soát ai thấy từng trường. Một thử nghiệm với năm người thường phát hiện nhãn khó hiểu và khoảng trống trong phân luồng nhanh hơn một đợt xem xét nội bộ kéo dài.

Bắt đầu nhỏ và cải thiện quy trình

Bắt đầu với một nhóm, chẳng hạn nhóm kinh doanh hoặc hỗ trợ khách hàng, cùng một nhóm quy tắc ngắn. Phiên bản đầu tiên chỉ cần những thông tin quyết định chuyến đi có thể tiến hành hay không: người đi, mục đích, ngày đi, điểm đến, chi phí ước tính và phê duyệt của quản lý.

Giữ các giới hạn đầu tiên dễ giải thích. Quản lý có thể phê duyệt chuyến đi tối đa 1.500 USD, còn trưởng bộ phận xem xét các khoản cao hơn. Gửi những yêu cầu ngoài chính sách, chẳng hạn chuyến bay cao cấp hoặc đặt vé muộn, đến đúng người xem xét cùng ghi chú ngoại lệ.

Đừng thêm mọi trường có thể có ngay từ ngày đầu. Biểu mẫu dài khiến mọi người quay lại email, tái tạo đúng vấn đề theo dõi mà ứng dụng cần giải quyết.

Sau vài yêu cầu đầu tiên, hãy hỏi nhân viên và người phê duyệt họ đã dừng lại ở đâu hoặc cần hỏi điều gì. Câu trả lời thường cho thấy một trường bị thiếu, giới hạn chi phí khó hiểu hoặc bước phê duyệt không phù hợp với quy trình thực tế của nhóm.

Những cải tiến ban đầu thường gồm thêm trường khách hàng hoặc dự án, tách chi phí chuyến bay và khách sạn, yêu cầu lý do ngoại lệ, điều chỉnh giới hạn phê duyệt hoặc thêm liên kết báo cáo chi phí sau chuyến đi.

Khi có thể, hãy thay đổi từng việc một. Nếu thay đổi mười quy tắc cùng lúc, bạn sẽ khó biết điều gì đã giải quyết vấn đề hoặc gây ra chậm trễ mới. Sau một tháng, hãy xem lại các yêu cầu đang chờ và bị từ chối. Tìm những ngoại lệ lặp lại, yêu cầu bị giữ lâu ở một người phê duyệt và các trường hợp chi phí ước tính thường khác với khoản chi cuối cùng.

AppMaster cho phép các nhóm tạo ứng dụng công tác no-code với biểu mẫu, phê duyệt và báo cáo trong cùng một ứng dụng. Hãy bắt đầu với biểu mẫu yêu cầu và quy tắc phê duyệt nhóm cần hiện nay, sau đó chỉ thêm nhà cung cấp ưu tiên, báo cáo ngân sách hoặc liên kết theo dõi chi phí trực tiếp khi chúng giải quyết một vấn đề thực tế.