Quy trình yêu cầu ngoại lệ chính sách để phê duyệt minh bạch

Tại sao ngoại lệ chính sách cần một quy trình rõ ràng

Khi ngoại lệ chính sách được xử lý qua email hoặc chat, thông tin nhanh chóng bị phân tán. Người này phê duyệt trong một chuỗi tin nhắn, người khác yêu cầu thêm bối cảnh trong một cuộc trò chuyện riêng, và người thứ ba lại cho rằng ngoại lệ vẫn còn hiệu lực vài tháng sau. Đó không phải là linh hoạt. Đó là sự lộn xộn.

Một quy trình yêu cầu ngoại lệ chính sách rõ ràng tạo ra một con đường duy nhất cho mỗi yêu cầu. Mọi người biết gửi ở đâu, cần cung cấp lý do gì, ai cần phê duyệt và khi nào thì hết hạn. Điều đó làm cho quy trình dễ dàng hơn cho nhân viên và an toàn hơn cho doanh nghiệp.

Nếu không có một con đường chuẩn, các nhóm thường xử lý những tình huống rất khác nhau như thể chúng giống nhau. Một ngoại lệ hợp lệ là một quyết định tạm thời, được ghi nhận để cho phép sai khác với quy tắc vì một lý do cụ thể. Bỏ qua một quy tắc thì khác — thường có nghĩa là quy tắc bị phớt lờ, không ai chịu trách nhiệm cho quyết định, và không có hồ sơ giải thích lý do xảy ra.

Sự khác biệt đó xuất hiện trong công việc hàng ngày. Hãy tưởng tượng một quản lý cho phép thanh toán nhà cung cấp vượt ngưỡng bình thường vì vấn đề cung ứng khẩn cấp. Nếu quyết định được ghi lại với lý do, phê duyệt và ngày kết thúc, đó là ngoại lệ được kiểm soát. Nếu cùng khoản thanh toán được thực hiện chỉ với một "ok" nhanh trong chat và không có gì khác, nó trở thành một điểm yếu.

Vấn đề thường xuất hiện sau này, chứ không phải vào ngày yêu cầu. Các nhóm không còn biết ai đã phê duyệt ngoại lệ, tại sao nó được cho phép, nó kéo dài bao lâu, liệu cùng ngoại lệ có tái diễn không, hoặc ai nên xem lại nó một lần nữa. Thiếu phê duyệt, ngày tháng và hồ sơ dẫn đến sai lầm lặp lại, đối xử không đều giữa các nhóm và rắc rối khi kiểm toán. Nó cũng đặt các quản lý vào vị trí khó xử vì họ không thể chứng minh quyết định đã được xem xét đúng cách.

Một quy trình chuẩn đơn giản khắc phục điều đó. Nó biến ngoại lệ từ những ân huệ không chính thức thành quyết định kinh doanh có thể nhìn thấy được. Ngay cả một luồng nội bộ cơ bản cũng có thể chấm dứt việc phỏng đoán và giúp mọi người tuân theo cùng một quy tắc mỗi lần.

Những thông tin cần có trong mỗi yêu cầu

Một yêu cầu nên cung cấp cho người duyệt đủ bối cảnh để đưa ra quyết định mà không phải truy hỏi thêm. Nếu biểu mẫu mơ hồ, quy trình phê duyệt ngoại lệ sẽ chậm lại và các nhóm khác nhau sẽ bắt đầu đưa ra quyết định không nhất quán.

Một quy trình yêu cầu ngoại lệ tốt bắt đầu với một bộ trường tiêu chuẩn. Giữ đơn giản, nhưng đảm bảo mỗi yêu cầu trả lời cùng một nhóm câu hỏi cốt lõi.

Các trường cốt lõi

Người yêu cầu. Ghi lại người, đội và vai trò. Cần rõ ai được phép gửi yêu cầu và họ đang yêu cầu cho bản thân hay cho một phòng ban.

Chính sách bị ảnh hưởng. Nêu rõ chính sách, kiểm soát hoặc yêu cầu chính xác không thể tuân theo. Một yêu cầu chỉ nói "cần ngoại lệ" thì quá rộng để phê duyệt.

Lý do kinh doanh. Yêu cầu lý do bằng ngôn ngữ đơn giản. Người duyệt nên hiểu vấn đề sau một lần đọc ngắn, không cần thuật ngữ kỹ thuật hay viết tắt nội bộ.

Tác động, rủi ro và biện pháp giảm thiểu. Ghi lại điều gì xảy ra nếu yêu cầu được chấp thuận, điều gì có thể sai và các bước nào sẽ giảm rủi ro. Đây cũng là nơi thích hợp để ghi ngày bắt đầu và ngày kết thúc yêu cầu.

Quyết định và chủ sở hữu. Mỗi hồ sơ nên cho thấy kết quả cuối cùng, ai đã phê duyệt hoặc từ chối, và ai chịu trách nhiệm theo dõi sau quyết định.

Một ví dụ ngắn làm rõ khác biệt. Giả sử đội bán hàng cần quyền truy cập tạm thời để xuất dữ liệu khách hàng cho một lần di chuyển dữ liệu. Yêu cầu nên nêu rõ chính sách xử lý dữ liệu bị miễn trừ, giải thích rằng việc di chuyển hỗ trợ việc triển khai cho khách đã ký hợp đồng, mô tả rủi ro quyền riêng tư và đặt ngày hết hạn cố định cho quyền truy cập thêm.

Điểm cuối cùng này quan trọng hơn nhiều nhóm nghĩ. Chủ sở hữu không bao giờ nên để mở. Nếu một ngoại lệ được chấp thuận, một người cụ thể phải được đặt tên chịu trách nhiệm xem xét trước khi nó hết hạn, xác nhận nhu cầu tạm thời vẫn còn, hoặc đóng ngoại lệ.

Nếu bạn xây dựng biểu mẫu dưới dạng ứng dụng nội bộ, hãy giữ các trường này hiển thị từ khi gửi đến khi phê duyệt. Điều đó làm cho dấu vết kiểm toán cho các phê duyệt dễ theo dõi hơn sau này. Các nền tảng như AppMaster thường được sử dụng cho loại luồng nội bộ này vì biểu mẫu, logic và lịch sử trạng thái có thể lưu trong một nơi.

Cách chọn mã lý do phù hợp

Mã lý do nên giúp người ta giải thích tại sao yêu cầu ngoại lệ được đưa ra mà không làm biểu mẫu khó hoàn thành. Trong một quy trình yêu cầu ngoại lệ chính sách, mã tốt nhất là dễ chọn, dễ báo cáo và đủ rõ để hai người duyệt sẽ hiểu cùng một cách.

Bắt đầu với một danh sách ngắn. Nếu bạn cung cấp 20 lựa chọn, người ta sẽ đoán, bỏ qua chi tiết hoặc chọn cái đầu tiên có vẻ gần. Hầu hết các đội làm tốt hơn với 5 đến 8 loại phản ánh các tình huống thực tế, lặp lại.

Mã lý do tốt trông như thế nào

Một mã hữu ích đủ cụ thể để cho thấy xu hướng. "Hạn chế từ nhà cung cấp hoặc bên thứ ba" cho bạn biết nhiều hơn "Khác." "Thiếu nhân sự tạm thời" tốt hơn "Khẩn cấp." Nhãn mơ hồ tạo báo cáo lộn xộn vì chúng che giấu lý do thực sự đằng sau yêu cầu.

Một tập đơn giản có thể bao gồm:

• Xung đột pháp lý hoặc quy định
• Cam kết với khách hàng đã được đưa ra
• Hạn chế từ nhà cung cấp hoặc bên thứ ba
• Vấn đề vận hành tạm thời
• Hạn chế hệ thống hoặc thiếu tính năng

Ngay cả với mã rõ ràng, một nhãn không thể kể hết câu chuyện. Thêm một trường văn bản ngắn để người yêu cầu giải thích trường hợp trong một hoặc hai câu. Mã nên mô tả loại ngoại lệ, và văn bản tự do nên mô tả tình huống cụ thể. Ví dụ, ai đó có thể chọn "Hạn chế hệ thống hoặc thiếu tính năng" rồi ghi chú rằng ứng dụng hiện tại không thể bắt buộc một bước phê duyệt mới trước cuối tháng.

Xem lại mã định kỳ. Nếu một mã không bao giờ được dùng, hãy loại bỏ nó. Nếu mọi người liên tục chọn sai mã, hãy đổi tên nó. Nếu một nửa yêu cầu của bạn rơi vào một nhóm, hãy tách nó thành các mục rõ ràng hơn.

Một danh sách nhỏ, được duy trì tốt không chỉ giữ biểu mẫu gọn gàng. Nó làm cho xu hướng dễ thấy, giúp người duyệt nhất quán và cung cấp báo cáo sạch hơn khi bạn cần giải thích cách và lý do các ngoại lệ xảy ra.

Từng bước: xây dựng đường phê duyệt

Một đường phê duyệt tốt nên cảm thấy dễ đoán. Người yêu cầu biết chuyện gì xảy ra tiếp theo, người phê duyệt biết họ đang quyết định điều gì, và doanh nghiệp có thể thấy lý do ngoại lệ được chấp thuận hoặc từ chối.

Với quy trình yêu cầu ngoại lệ chính sách, giữ đường đi đủ ngắn để di chuyển nhanh nhưng đủ rõ để tránh phỏng đoán.

1. Bắt đầu với một biểu mẫu yêu cầu chuẩn. Hỏi chính sách bị bỏ qua, lý do, tác động kinh doanh, ai bị ảnh hưởng và mọi ghi chú hỗ trợ.
2. Thêm kiểm tra chất lượng nhanh. Đây không phải là phê duyệt thực sự. Đó là bước kiểm tra cơ bản để bắt lỗi trường trống, lý do mơ hồ hoặc thiếu bằng chứng trước khi yêu cầu đến người ra quyết định.
3. Chuyển yêu cầu theo rủi ro. Một ngoại lệ nội bộ nhỏ có thể gửi đến trưởng nhóm, trong khi trường hợp rủi ro cao hơn có thể cần compliance, security, finance hoặc ban lãnh đạo cấp cao. Quy tắc định tuyến nên dễ theo, ví dụ theo loại chính sách, chi phí, ảnh hưởng khách hàng hoặc độ nhạy dữ liệu.
4. Đặt quy tắc leo thang. Chờ đợi vô thời hạn tạo ra thỏa thuận bên lề và quyết định ngoài sổ sách. Nếu không có hành động trong một khoảng thời gian quy định, thông báo một người phê duyệt dự phòng hoặc đẩy yêu cầu lên cấp tiếp theo.
5. Ghi lại kết quả rõ ràng. Người phê duyệt nên chọn chấp thuận, từ chối hoặc yêu cầu thay đổi. Mỗi kết quả nên kèm một bình luận ngắn để người yêu cầu biết chuyện gì đã xảy ra và cần làm gì tiếp theo.

Lộ trình này hoạt động tốt nhất khi mỗi bước có người chịu trách nhiệm. Người yêu cầu gửi, một quản trị vận hành hoặc quản trị chính sách kiểm tra, người phê duyệt đúng chức năng quyết định và hệ thống ghi lại kết quả.

Một ví dụ đơn giản giúp hình dung. Nếu quản lý bán hàng xin bỏ quy tắc chiết khấu cho một khách hàng, yêu cầu trước hết được kiểm tra xem có thiếu chi tiết về giá không. Nếu chiết khấu nhỏ, trưởng khu vực có thể quyết định. Nếu vượt ngưỡng, tài chính sẽ tự động được thêm vào.

Điểm cuối cùng là quan trọng nhất: mọi quyết định phải để lại hồ sơ rõ ràng. Nếu lộ trình rõ ràng, mọi người có nhiều khả năng tuân theo nó. Đó chính là cách biến quy trình phê duyệt ngoại lệ từ thói quen lỏng sang hệ thống có kiểm soát và lặp lại được.

Cách xử lý ngày hết hạn và gia hạn

Bắt buộc giới hạn thời gian

Hầu hết ngoại lệ chính sách nên là tạm thời. Nếu một yêu cầu không có ngày kết thúc, nó thường trở thành một thay đổi quy tắc âm thầm.

Hãy bắt buộc trường ngày hết hạn, không để là ghi chú tùy chọn. Người yêu cầu nên giải thích tại sao ngoại lệ cần cho khoảng thời gian đó, có thể là 7 ngày, 30 ngày hoặc 6 tháng.

Quy trình tốt cũng gửi nhắc trước khi ngày hết hạn đến. Một mẫu đơn giản thường đủ: một nhắc 14 ngày trước khi hết hạn, một nhắc 3 ngày trước, thông báo vào ngày hết hạn và cảnh báo nếu ngoại lệ vẫn mở sau khi đã quá hạn. Điều đó cho người yêu cầu và người phê duyệt thời gian hành động trước khi hồ sơ hết hiệu lực.

Xử lý gia hạn như quyết định mới

Gia hạn không nên xảy ra chỉ vì không ai phản đối. Nên có quy tắc rõ ràng: khi nào được phép gia hạn, thông tin mới nào cần, và ai phải phê duyệt.

Một số đội cho phép một lần gia hạn nhanh cho ngoại lệ rủi ro thấp. Những đội khác yêu cầu xem xét đầy đủ mỗi lần. Cách nào cũng được miễn là quy tắc được ghi lại và áp dụng nhất quán.

Khi có thể, đóng các ngoại lệ hết hạn tự động. Nếu ngày kết thúc qua đi và không có gia hạn được phê duyệt, hồ sơ nên chuyển sang trạng thái hết hạn hoặc đã đóng. Điều đó tránh các trường hợp lộn xộn khi mọi người giả định một ngoại lệ cũ vẫn còn hiệu lực.

Lưu mọi phiên bản của yêu cầu để tham khảo. Nếu ngày thay đổi, người phê duyệt thay đổi hoặc lý do được cập nhật, đừng ghi đè hồ sơ cũ. Lưu phiên bản trước để bất kỳ ai sau này xem xét cũng có thể thấy điều gì đã được phê duyệt, khi nào nó thay đổi và vì sao.

Một ví dụ đơn giản cho thấy vì sao điều này quan trọng. Một quản lý bán hàng được ngoại lệ 30 ngày để áp dụng chiết khấu không chuẩn. Ngày 16, một lời nhắc được gửi. Ngày 27, quản lý nộp gia hạn với số liệu cập nhật. Người phê duyệt xem đó như một quyết định mới, và phê duyệt cũ vẫn nằm trong hồ sơ thay vì biến mất.

Hồ sơ kiểm toán rõ ràng nên hiển thị những gì

Một dấu vết kiểm toán tốt trả lời một câu hỏi đơn giản nhanh chóng: điều gì đã xảy ra, ai làm, và vì sao? Trong quy trình yêu cầu ngoại lệ chính sách, điều đó quan trọng không kém kết luận cuối cùng.

Bắt đầu với những người tham gia. Mỗi yêu cầu nên hiển thị ai đã gửi, ai đã xem xét và ai đã đưa ra phê duyệt cuối cùng. Nếu nhiều người xem xét, hồ sơ nên cho thấy thứ tự các lần xem xét chứ không chỉ danh sách tên.

Thời gian cũng quan trọng. Mỗi hành động chính cần có dấu thời gian: gửi, xem xét, phê duyệt, từ chối, gia hạn và đóng. Điều đó giúp biết liệu yêu cầu có được xử lý kịp thời và liệu ngoại lệ có hoạt động trong khoảng thời gian đúng đắn.

Lịch sử thay đổi quan trọng không kém. Nếu ai đó cập nhật mã lý do, thu hẹp phạm vi hoặc thay đổi ngày hết hạn, hệ thống nên giữ cả giá trị cũ và mới. Không có lịch sử đó, một hồ sơ có thể trông sạch sẽ trong khi che giấu các chỉnh sửa quan trọng.

Bình luận hữu ích khi chúng gắn với quyết định. Một ghi chú như "Phê duyệt vì hợp đồng nhà cung cấp kết thúc trong 30 ngày" là có giá trị. Một bình luận mơ hồ như "trông ổn" thì không. Bình luận nên giải thích quyết định, không mở lại toàn bộ cuộc thảo luận trong hồ sơ.

Một dấu vết rõ ràng nên hiển thị người gửi, người duyệt và người phê duyệt; dấu thời gian cho mỗi bước; trạng thái hiện tại và các thay đổi trạng thái; các chỉnh sửa về lý do, phạm vi và ngày; và các ghi chú quyết định ngắn, cùng tệp đính kèm khi cần.

Bài kiểm tra cuối cùng rất đơn giản: liệu ai đó có thể xem hồ sơ trong vài phút và hiểu toàn bộ câu chuyện không? Nếu không, dấu vết quá mỏng.

Một ví dụ đơn giản về quy trình trong thực tế

Hãy tưởng tượng một quản lý bán hàng cần phê duyệt cho một sự kiện khách hàng một lần tốn nhiều hơn giới hạn chi tiêu bình thường của đội. Chính sách cho phép quản lý phê duyệt tới $2,000, nhưng yêu cầu này là $3,500. Thay vì xử lý qua chat hoặc email, đội dùng quy trình yêu cầu ngoại lệ chính sách.

Quản lý mở yêu cầu và điền các thông tin cơ bản: số tiền, mục đích kinh doanh, nhà cung cấp và ngày cần thanh toán. Họ cũng chọn một mã lý do. Trong trường hợp này, "Cam kết với khách hàng đã được đưa ra" rõ ràng hơn nhiều so với nhãn mơ hồ như "Khác" vì nó cho người duyệt biết tại sao vấn đề tồn tại.

Hồ sơ ghi người yêu cầu là quản lý bán hàng, chính sách bị ảnh hưởng là giới hạn chi tiêu đội, ngoại lệ yêu cầu là cho phép $3,500 thay vì $2,000, và ngày hết hạn đề xuất là 14 ngày sau sự kiện. Sau khi gửi, yêu cầu chuyển tới giám đốc tài chính để xem xét. Nếu số tiền vượt ngưỡng cao hơn, có thể cần phê duyệt thứ hai từ trưởng bộ phận vận hành.

Mỗi người phê duyệt thấy cùng thông tin, thêm một ghi chú ngắn và chấp thuận hoặc từ chối yêu cầu. Nếu được chấp thuận, ngoại lệ có hiệu lực ngay lập tức và giữ ngày hết hạn gắn với hồ sơ.

Ngày hết hạn chính là điều làm cho ngoại lệ mang tính tạm thời thay vì vĩnh viễn. Sau sự kiện, ngoại lệ đóng tự động khi ngày đó qua. Đội vẫn có thể xem hồ sơ sau, nhưng không ai có thể tiếp tục dùng phê duyệt đó cho chi tiêu trong tương lai.

Nếu sự kiện bị hoãn và nhu cầu vẫn còn, quản lý không nên chỉnh sửa yêu cầu cũ và kéo dài mãi mãi. Họ nên nộp một yêu cầu gia hạn tham chiếu đến yêu cầu gốc, xác nhận lý do vẫn hợp lệ và đặt ngày hết hạn mới. Điều đó giữ dấu vết kiểm toán rõ ràng.

Hồ sơ cuối cùng nên hiển thị toàn bộ câu chuyện ở một nơi: ai đã yêu cầu, mã lý do nào được chọn, ai đã phê duyệt, khi nào hết hạn, và liệu nó có được gia hạn hay đóng không. Nếu ai đó xem lại sau sáu tháng, họ nên hiểu quyết định trong chưa đầy một phút.

Những lỗi thường gặp gây nhầm lẫn

Hầu hết vấn đề trong quy trình yêu cầu ngoại lệ chính sách không bắt nguồn từ ý đồ xấu. Chúng bắt nguồn từ quy tắc mơ hồ, quá nhiều người phê duyệt và quyết định được đưa ra ngoài hệ thống.

Một lỗi phổ biến là gửi mọi yêu cầu qua cùng một chuỗi phê duyệt dài. Nếu ngoại lệ rủi ro thấp và cao cùng đi theo một đường, yêu cầu đơn giản bị kẹt phía sau những trường hợp phức tạp. Mọi người mất kiên nhẫn và bắt đầu tìm đường tắt.

Mã lý do là một điểm yếu khác. Nếu mã chồng chéo, như "nhu cầu khẩn cấp," "trường hợp đặc biệt," và "vấn đề vận hành," người ta sẽ chọn bất cứ gì nghe có vẻ an toàn. Sau đó, báo cáo trở nên khó tin vì các yêu cầu tương tự nằm rải rác trong các nhãn khác nhau.

Những dấu hiệu cảnh báo khác xuất hiện nhanh. Loại yêu cầu giống nhau được phê duyệt bởi những người khác nhau mỗi lần. Ngoại lệ tạm thời vẫn còn hoạt động vì không ai đặt ngày hết hạn. Quản lý phê duyệt qua chat hoặc email nhưng hồ sơ chính không được cập nhật. Bình luận chứa bối cảnh quan trọng, nhưng các chỉnh sửa vào yêu cầu không được theo dõi.

Thiếu ngày hết hạn tạo rủi ro thầm lặng. Một miễn trừ tạm thời có thể trở thành vĩnh viễn chỉ vì không ai nhớ xem lại. Đặt ngày kết thúc khi tạo ngoại lệ và xử lý gia hạn như một quyết định mới, không phải là gia hạn informal.

Phê duyệt informal gây ra cùng mức độ nhầm lẫn. Nếu ai đó ghi "đã phê duyệt" trong chuỗi tin nhắn, nhưng hồ sơ yêu cầu vẫn mở hoặc không đầy đủ, không ai biết thực sự gì đã được cho phép. Hồ sơ nên là nguồn sự thật duy nhất.

Dấu vết kiểm toán thường trông hoàn chỉnh cho đến khi ai đó hỏi một câu khó. Nếu nó chỉ cho thấy phê duyệt cuối cùng mà không có các trường đã thay đổi, bình luận thêm hoặc ai đã chỉnh sửa yêu cầu sau khi xem xét, lịch sử là chưa đầy đủ.

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

Một quy trình có thể trông hoàn thiện trong sơ đồ nhưng vẫn thất bại ngay ngày đầu sử dụng. Trước khi triển khai, hãy thử nghiệm từ ba góc nhìn: người yêu cầu, người phê duyệt và người có thể cần xem xét hồ sơ vài tháng sau.

Đảm bảo biểu mẫu nhanh để hoàn thành. Nếu mất hơn vài phút, người ta sẽ làm vội, bỏ qua chi tiết hoặc chọn sai tùy chọn. Xác nhận rằng yêu cầu luôn tới đúng người phê duyệt bằng cách thử một vài trường hợp mẫu từ các đội và vai trò khác nhau.

Kiểm tra rằng mỗi ngoại lệ phải bao gồm cả mã lý do và ngày kết thúc. Sau đó xem chế độ xem lịch sử như thể bạn đang kiểm toán sau này. Bạn nên có thể thấy ai đã gửi, ai phê duyệt hoặc từ chối, gì đã thay đổi và khi nào quyết định xảy ra.

Cuối cùng, thử các nhắc và quy tắc đóng với dữ liệu mẫu thực. Đừng giả định thông báo hết hạn, nhắc gia hạn hoặc bước đóng tự động sẽ hoạt động chỉ vì chúng đã được cấu hình.

Một trường hợp thử nghiệm đơn giản hữu ích. Giả sử trưởng nhóm xin ngoại lệ tạm thời cho quy tắc mua sắm trong 30 ngày. Yêu cầu nên dễ nộp, chuyển đến đúng quản lý, ghi lý do, gửi nhắc trước khi hết hạn, rồi đóng hoặc gia hạn với dấu vết kiểm toán rõ ràng.

Nếu một phần cảm thấy mơ hồ khi thử nghiệm, nó sẽ còn tệ hơn khi dùng hàng ngày. Đó thường là nơi gây ra nhầm lẫn: trường mơ hồ, thiếu ngày, người phê duyệt sai, hoặc hồ sơ không cho thấy toàn bộ câu chuyện.

Các bước thực tế tiếp theo

Cách tốt nhất để triển khai quy trình yêu cầu ngoại lệ chính sách là giữ phiên bản đầu tiên nhỏ. Chọn một lĩnh vực chính sách nơi ngoại lệ thường xảy ra, như phê duyệt mua sắm, yêu cầu truy cập hoặc gia hạn hạn chót. Bắt đầu hẹp giúp phát hiện lỗ hổng trước khi quy trình lan rộng khắp doanh nghiệp.

Chạy quy trình với các trường hợp thực trong một thời gian thử ngắn. Quan sát thời gian xử lý, nơi mọi người bị mắc và trường nào gây nhầm lẫn. Nếu người yêu cầu liên tục hỏi mã lý do nghĩa là gì, hoặc người phê duyệt thường trả lại hồ sơ, đó là thông tin hữu ích.

Giữ việc triển khai thực tế. Bắt đầu với một chính sách và một chuỗi phê duyệt. Thu thập phản hồi từ cả người yêu cầu và người phê duyệt. Xem lại vài trường hợp đầu tiên để tìm trường thiếu hoặc quy tắc mơ hồ. Sau đó tinh chỉnh cảnh báo, nhắc hết hạn và các ghi chú yêu cầu dựa trên những gì học được.

Hỏi những câu đơn giản. Biểu mẫu có dễ hoàn thành trong một lần không? Người phê duyệt có đủ bối cảnh để quyết định mà không phải truy hỏi thêm không? Nếu cả hai nhóm vẫn cần email hoặc chat bên lề để hoàn tất yêu cầu, quy trình cần chỉnh sửa.

Sau vòng đầu, cải thiện những phần ảnh hưởng nhiều nhất đến sự rõ ràng. Thường là giảm các mã lý do mơ hồ, thêm phần lý do kinh doanh bắt buộc hoặc đặt nhắc tự động trước khi ngoại lệ hết hạn. Những thay đổi nhỏ ở đây có thể làm cho quy trình phê duyệt ngoại lệ nhanh hơn và đáng tin cậy hơn nhiều.

Cũng nên xác định ai chịu trách nhiệm quản lý quy trình sau khi ra mắt. Một người hoặc một đội nên xem xét vấn đề mới, cập nhật quy tắc và kiểm tra xem phê duyệt có theo chính sách hay không. Nếu không có chủ sở hữu rõ ràng, ngay cả quy trình tốt cũng sẽ trở nên lộn xộn theo thời gian.

Nếu bạn muốn xây dựng quy trình mà không cần dự án phát triển dài, AppMaster có thể là một lựa chọn thực tế để tạo ứng dụng nội bộ với biểu mẫu, logic phê duyệt, nhắc nhở và hồ sơ rõ ràng cho mỗi quyết định. Mục tiêu không phải làm cho ngoại lệ trở nên khó khăn. Mà là làm cho chúng rõ ràng, nhất quán và dễ xem xét về sau.