Ngoại lệ trong quy trình nghiệp vụ: những nhánh giúp công việc không bị đình trệ

Vì sao các vấn đề thường ngày trong quy trình cần những nhánh xử lý rõ ràng

Hầu hết quy trình trông khá đơn giản trên sơ đồ: một người gửi yêu cầu, quản lý phê duyệt, rồi đội ngũ hoàn thành công việc. Công việc thực tế hiếm khi đi theo một đường thẳng như vậy. Biểu mẫu có thể đến mà thiếu mã trung tâm chi phí, khách hàng có thể yêu cầu ngoại lệ hoặc người phê duyệt có thể bỏ lỡ thời hạn.

Khi không có hướng xử lý được định nghĩa, quy trình sẽ đình trệ. Mọi người sao chép thông tin vào chat, gửi email nhắc việc hoặc lập bảng tính để theo dõi vấn đề. Yêu cầu ban đầu bị bỏ lửng trong khi nhiều người giữ những phiên bản thông tin khác nhau.

Các nhánh ngoại lệ rõ ràng giúp yêu cầu vẫn nằm trong quy trình. Quy trình có thể yêu cầu người gửi bổ sung thông tin, trả lại yêu cầu bị từ chối kèm lý do hoặc giao nhiệm vụ quá hạn cho người phụ trách dự phòng. Mọi người đều thấy trạng thái hiện tại và biết ai cần hành động tiếp theo.

Điều này cũng giúp báo cáo hữu ích hơn. Nếu có mười yêu cầu mua sắm phải chờ mã ngân sách, biểu mẫu tiếp nhận đang có một vấn đề lặp lại. Nếu yêu cầu thường xuyên chuyển sang kiểm tra thủ công, các quy tắc phê duyệt có thể cần điều chỉnh. Tin nhắn chat thường che khuất những xu hướng này.

Lỗi quy trình và quyết định nghiệp vụ cần được xử lý khác nhau. Lỗi quy trình khiến quy trình dừng lại vì dữ liệu bắt buộc bị thiếu hoặc không hợp lệ. Chẳng hạn, nhân viên gửi yêu cầu thanh toán chi phí nhưng không có biên lai. Quy trình nên trả yêu cầu về và nêu rõ nhân viên cần bổ sung gì.

Quyết định nghiệp vụ cần sự phán đoán. Một đơn hàng có thể vượt hạn mức chi tiêu thông thường, nhưng quản lý vẫn có thể phê duyệt vì nhà cung cấp cần thay thế gấp một linh kiện. Dữ liệu đã đầy đủ, nhưng chỉ các quy tắc thì không thể tự quyết định kết quả.

Gọi cả hai trường hợp là «lỗi» sẽ gây nhầm lẫn. Người gửi có thể không biết mình cần sửa một trường, cung cấp bằng chứng hay chờ quyết định. Hãy đặt cho mỗi ngoại lệ một tên dễ hiểu, một người phụ trách rõ ràng và kết quả được xác định trước.

Ví dụ, một quy trình được xây dựng trong AppMaster có thể trả yêu cầu chưa đầy đủ về cho người gửi, đồng thời chuyển các ngoại lệ chính sách cho quản lý. Hồ sơ yêu cầu vẫn ở một nơi thay vì bị chuyển qua nhiều hộp thư. Lựa chọn đơn giản này có thể giảm đáng kể công việc theo dõi về sau.

Xác định từng ngoại lệ trước khi xây dựng quy trình

Quy trình cần có các nhánh rõ ràng cho những thời điểm tiến trình bình thường bị dừng lại. Hãy bắt đầu với bốn ngoại lệ phổ biến trong quy trình nghiệp vụ: thiếu thông tin, yêu cầu bị từ chối, công việc quá hạn và trường hợp cần kiểm tra thủ công. Mỗi trường hợp cần một quy tắc riêng thay vì trạng thái mơ hồ kiểu «đã xảy ra sự cố».

Với mỗi ngoại lệ, hãy ghi lại điều kiện kích hoạt, người phụ trách, thời hạn và hành động tiếp theo. Cách này giúp yêu cầu không bị nằm im trong hàng đợi chỉ vì không ai biết ai phải phản hồi.

Hãy sớm quyết định mỗi nhánh sẽ trả công việc về cho người gửi hay kết thúc yêu cầu. Trường hợp thiếu thông tin thường quay lại người đã gửi yêu cầu. Yêu cầu bị từ chối có thể được trả lại để chỉnh sửa, nhưng yêu cầu vi phạm chính sách cố định nên được đóng kèm lý do rõ ràng. Nhân viên không nên phải đoán xem mình có thể gửi lại hay không.

Dùng tên trạng thái mô tả đúng tình trạng hiện tại. «Chờ người gửi», «Đã từ chối», «Quá hạn» và «Cần kiểm tra thủ công» hiệu quả hơn các nhãn như «Ngoại lệ 2» hoặc «Đang chờ xử lý». Người xem danh sách phải hiểu chuyện gì đã xảy ra và ai là người cần chuyển mục đó sang bước tiếp theo.

Đặt thời hạn cho chính ngoại lệ, không chỉ cho yêu cầu ban đầu. Chẳng hạn, cho người gửi hai ngày làm việc để tải lên hóa đơn còn thiếu. Nếu họ không phản hồi, quy trình có thể gửi lời nhắc rồi đóng yêu cầu sau một khoảng thời gian được xác định trước. Nhờ vậy, công việc cũ không âm thầm chất đống.

Trong một ứng dụng no-code, hãy xây dựng ngoại lệ thành những thay đổi trạng thái dễ nhìn thấy và các nhánh riêng trong quy trình nghiệp vụ. AppMaster's visual Business Process Editor có thể lập bản đồ quyết định, giao người phụ trách và chuyển yêu cầu sang bước tiếp theo. Dùng cùng một cách diễn đạt trong danh sách trạng thái, thông báo và màn hình nhân viên.

Xử lý yêu cầu thiếu thông tin

Yêu cầu có trường bị bỏ trống không nên nằm chung hàng đợi với công việc đã sẵn sàng để phê duyệt. Hãy đặt cho nó một trạng thái rõ ràng, chẳng hạn «Đang chờ thông tin», rồi đưa ra khỏi nhánh phê duyệt đang hoạt động. Nhờ vậy, mọi người biết vì sao tiến trình dừng lại thay vì cho rằng người xét duyệt đã bỏ sót yêu cầu.

Trạng thái này nên kích hoạt một tin nhắn trực tiếp đến người gửi. Tránh những ghi chú mơ hồ như «Cần thêm thông tin». Hãy nêu rõ mục còn thiếu và giải thích thế nào là phản hồi phù hợp: «Vui lòng đính kèm báo giá của nhà cung cấp và nhập chi phí hàng tháng trước khi chúng tôi có thể xem xét yêu cầu mua sắm này.»

Giữ yêu cầu ban đầu ở trạng thái mở và cho phép chỉnh sửa. Người gửi nên có thể thêm báo giá hoặc sửa ngày mà không phải nhập lại phòng ban, mã ngân sách và phần mô tả. Một nhánh xử lý ngoại lệ tốt sẽ giữ lại các thông tin đã được kiểm tra, cùng với bình luận và thời điểm yêu cầu đổi trạng thái.

Làm rõ đường dẫn trả lại

Khi người gửi bổ sung thông tin, hãy chuyển yêu cầu đến một bước tiếp theo đã được xác định. Thông thường, yêu cầu sẽ quay lại người đã yêu cầu bổ sung thông tin. Nếu thông tin mới làm thay đổi quyết định, yêu cầu có thể phải quay lại bước phê duyệt đầu tiên.

Hãy ghi lại các trường hoặc tài liệu còn thiếu, người chịu trách nhiệm phản hồi, người kiểm tra thông tin cập nhật, thời hạn phản hồi và lý do đóng nếu yêu cầu kết thúc. Hồ sơ này giúp giải đáp các câu hỏi về sau. Quản lý có thể thấy yêu cầu hóa đơn phải chờ chứng từ thuế, thay vì cho rằng bộ phận tài chính phê duyệt chậm.

Dùng lời nhắc và quy tắc đóng

Đặt lời nhắc trước thời hạn phản hồi. Một lời nhắc sau hai ngày làm việc và một lời nhắc khác vào ngày đến hạn là cách làm thực tế. Gửi lời nhắc cho người gửi, sau đó chỉ thêm quản lý của họ khi quy trình yêu cầu chuyển cấp.

Các ngoại lệ trong quy trình nghiệp vụ cũng cần điểm kết thúc. Nếu không ai phản hồi sau một khoảng thời gian nhất định, hãy đóng yêu cầu với trạng thái «Chưa hoàn tất» và ghi lại lý do. Đừng xóa yêu cầu. Người gửi có thể cần xem lịch sử khi tạo yêu cầu mới.

Một công cụ quy trình no-code như AppMaster có thể lưu trạng thái yêu cầu, gửi thông báo và chuyển biểu mẫu đã cập nhật về cho người xét duyệt thông qua các quy trình nghiệp vụ trực quan. Đồng nghiệp phải có thể biết mục nào còn thiếu, ai cần hành động và điều gì sẽ xảy ra nếu không ai xử lý.

Xử lý yêu cầu bị từ chối mà không mất ngữ cảnh

Yêu cầu bị từ chối không nên biến mất trong hộp thư hoặc nằm dưới một nhãn trạng thái mơ hồ. Người gửi cần biết vấn đề nằm ở đâu, ai đưa ra quyết định và họ có thể sửa hay không. Quản lý cũng cần cùng một hồ sơ khi phát sinh câu hỏi về sau.

Lưu lý do trong một trường có cấu trúc, thay vì chỉ ghi trong bình luận tự do. Biểu mẫu yêu cầu mua sắm có thể đưa ra những lý do như «Không có ngân sách», «Yêu cầu trùng lặp», «Thiếu phê duyệt» hoặc «Vi phạm chính sách». Thêm một trường bình luận ngắn cho những chi tiết không nằm trong các lý do có sẵn.

Cách này giúp báo cáo dễ dùng hơn. Quản lý có thể biết phần lớn yêu cầu thất bại vì nhân viên bỏ sót mã trung tâm chi phí hay vì chính sách khó hiểu. Nó cũng ngăn người xét duyệt viết nhiều phiên bản của cùng một lý do, chẳng hạn «vượt ngân sách» và «ngân sách quá cao».

Một yêu cầu bị từ chối có ba kết quả có thể xảy ra. Trả lại để chỉnh sửa khi người gửi có thể khắc phục vấn đề, chẳng hạn thiếu báo giá, lý do nghiệp vụ chưa rõ hoặc số tiền không đúng. Đóng yêu cầu khi nó vi phạm một quy tắc đã nêu, chẳng hạn dùng nhà cung cấp chưa được phê duyệt hoặc vượt hạn mức cho phép. Chuyển các trường hợp chưa chắc chắn sang kiểm tra thủ công khi quản lý hoặc người phụ trách tuân thủ cần đưa ra quyết định.

Yêu cầu được trả lại nên giữ nguyên thông tin ban đầu, tệp đính kèm và lịch sử phê duyệt. Yêu cầu người gửi chỉnh sửa hồ sơ hiện tại thay vì tạo hồ sơ khác. Quy trình có thể đặt trạng thái «Yêu cầu chỉnh sửa», giao lại cho người gửi và gửi kèm lý do từ chối cùng bình luận của người xét duyệt.

Khi người gửi nộp lại, hãy ghi lại phiên bản mới và chuyển đến đúng người xét duyệt. Giữ lần từ chối trước đó trong lịch sử. Nó giải thích vì sao yêu cầu bị dừng và cho thấy người gửi đã xử lý vấn đề hay chưa.

Yêu cầu đã đóng cũng cần được lưu giữ đầy đủ. Giữ người gửi, người xét duyệt, ngày quyết định, mã từ chối, ghi chú và bằng chứng đính kèm trong cùng một hồ sơ. Người gửi nên xem được các yêu cầu đã đóng của mình, còn quản lý có thể xem toàn bộ lịch sử của đội ngũ.

Trong AppMaster, mô hình dữ liệu có thể bao gồm trạng thái yêu cầu, lý do từ chối, ghi chú của người xét duyệt, ngày quyết định và bảng lịch sử. Quy trình nghiệp vụ trực quan có thể trả các yêu cầu có thể sửa về cho người gửi và tự động đóng các trường hợp vi phạm chính sách. Những chỉnh sửa thường gặp vẫn được xử lý, còn các quyết định cuối cùng vẫn được ghi lại.

Đặt quy tắc cho nhiệm vụ quá hạn

Thời hạn nên phù hợp với công việc thay vì dùng một bộ đếm mặc định cho mọi nhiệm vụ. Quản lý có thể cần một ngày làm việc để phê duyệt một khoản chi thông thường, trong khi việc kiểm tra pháp lý có thể cần năm ngày. Năng lực của đội ngũ cũng quan trọng. Thời hạn hai giờ không có nhiều ý nghĩa nếu người được giao dành phần lớn ngày để làm việc với khách hàng.

Ghi quy tắc thời hạn vào quy trình. Nêu rõ thời điểm bắt đầu tính giờ, cuối tuần có được tính hay không và sự kiện nào đánh dấu nhiệm vụ hoàn thành. Quy tắc rõ ràng giúp tránh tranh cãi khi yêu cầu đến muộn vào thứ Sáu hoặc phải chờ thông tin từ một đội khác.

Gửi lời nhắc trước thời hạn. Lời nhắc ở mốc 75% tổng thời gian thường cho người phụ trách đủ thời gian hành động. Với nhiệm vụ năm ngày, hãy gửi lời nhắc vào ngày thứ tư. Nội dung nên có tên nhiệm vụ, thời hạn, người phụ trách hiện tại và hành động cần thực hiện. Câu «Bạn có một nhiệm vụ đang chờ» cung cấp rất ít thông tin hữu ích.

Khi hết hạn, giao hành động tiếp theo cho một người hoặc vai trò cụ thể có thẩm quyền quyết định. Đừng gửi công việc trễ vào hộp thư chung. Cách này che khuất trách nhiệm và thường tạo thêm một nhiệm vụ quá hạn khác.

Kết quả nên phù hợp với loại chậm trễ. Tạm dừng yêu cầu nếu nhiệm vụ trễ ngăn cản một quyết định an toàn, chẳng hạn kiểm tra tuân thủ còn thiếu. Giao lại nhiệm vụ nếu người phụ trách ban đầu vắng mặt hoặc không còn năng lực xử lý. Tiếp tục với cảnh báo rõ ràng nếu chậm trễ không ảnh hưởng đến bước tiếp theo, chẳng hạn ghi chú nội bộ bị trễ. Chuyển cấp cho quản lý khi chậm trễ ảnh hưởng đến cam kết với khách hàng, thanh toán hoặc thời hạn bên ngoài.

Đặt giới hạn cho việc chuyển cấp lặp lại. Một yêu cầu mua sắm có thể chuyển từ nhân viên mua hàng đến trưởng bộ phận thu mua sau một lời nhắc quá hạn, rồi đến quản lý tài chính sau thêm một ngày làm việc. Lịch sử yêu cầu phải được giữ nguyên để người phụ trách mới xem được các bình luận và tệp đính kèm trước đó.

Các ngoại lệ trong quy trình nghiệp vụ cần nhiều hơn một cảnh báo. Chúng cần người phụ trách, quy tắc quyết định và kết quả được ghi lại. Trong AppMaster, quy trình nghiệp vụ trực quan có thể chuyển nhiệm vụ quá hạn cho đúng người và giữ yêu cầu tiếp tục tiến triển mà không cần những bảng tính thời hạn riêng.

Thêm bước kiểm tra thủ công mà mọi người có thể sử dụng

Một số yêu cầu không phù hợp với bất kỳ quy tắc nào. Tên nhà cung cấp có thể không quen thuộc, khoản chi có thể vượt hạn mức thông thường hoặc hai trường dữ liệu có thể mâu thuẫn. Những trường hợp này cần một người quyết định thay vì một nhánh tự động.

Hãy giữ quy trình kiểm tra thủ công tập trung. Chỉ gửi những yêu cầu thực sự cần phán đoán và làm rõ lý do chuyển giao. Trạng thái mơ hồ như «Cần xem xét» tạo thêm việc vì người xét duyệt phải tự tìm hiểu tại sao quy trình dừng lại.

Cung cấp đủ ngữ cảnh cho người xét duyệt

Màn hình kiểm tra nên hiển thị yêu cầu ban đầu, trường hoặc quy tắc kích hoạt ngoại lệ, các bình luận trước đó và tệp hỗ trợ. Quản lý phê duyệt một giao dịch mua sắm cần thấy số tiền, nhà cung cấp, mã ngân sách, người gửi và báo giá ở cùng một nơi.

Đưa ra các lựa chọn tương ứng với nhánh tiếp theo của quy trình: phê duyệt và chuyển yêu cầu đi tiếp, từ chối và đóng, trả lại cho người gửi chỉnh sửa hoặc chuyển cấp cho một người hay đội ngũ cụ thể. Yêu cầu một lý do ngắn cho mỗi quyết định về ngoại lệ. «Vượt ngân sách» hoặc «Thiếu báo giá có chữ ký» giúp người gửi biết phải làm gì và để lại hồ sơ cho người xét duyệt tiếp theo. Các phê duyệt thông thường không cần phần giải thích dài.

Đặt thời hạn cho quyết định

Công việc thủ công có thể trở thành công việc quá hạn nếu không ai sở hữu quyết định. Đặt thời hạn ngay khi quy trình giao người xét duyệt, chẳng hạn hai ngày làm việc cho một yêu cầu mua sắm tiêu chuẩn. Gửi lời nhắc trước hạn, sau đó chuyển yêu cầu cho người xét duyệt dự phòng hoặc quản lý nếu người được giao không có mặt.

Tránh gửi cùng một yêu cầu cho tất cả mọi người cùng lúc, trừ khi bất kỳ ai trong số họ đều có quyền quyết định. Cách này có thể tạo ra những câu trả lời mâu thuẫn. Trước tiên hãy giao cho một người, ghi lại từng hành động và khóa yêu cầu sau quyết định cuối cùng.

Trong AppMaster, một Business Process có thể chuyển ngoại lệ thành nhiệm vụ kiểm tra, lưu quyết định và bình luận rồi tiếp tục theo các nhánh phê duyệt, từ chối hoặc yêu cầu chỉnh sửa riêng. Nhiệm vụ vẫn gắn với yêu cầu ban đầu, nên mọi người không phải ghép lại lịch sử từ các email.

Ví dụ: yêu cầu mua sắm đi lệch khỏi quy trình

Một nhân viên gửi yêu cầu mua 2.400 USD màn hình mới. Yêu cầu có danh sách hàng hóa và phòng ban, nhưng thiếu báo giá của nhà cung cấp. Thay vì gửi cho quản lý, quy trình đặt trạng thái «Đang chờ thông tin» và giao nhiệm vụ tiếp theo cho người gửi.

Người gửi nhận được thông báo nêu rõ tài liệu còn thiếu và thời hạn bổ sung. Quản lý không nhận yêu cầu chưa hoàn chỉnh, nên hàng đợi phê duyệt vẫn hữu ích. Khi người gửi tải báo giá lên, quy trình ghi lại thời điểm tải, đổi trạng thái thành «Sẵn sàng kiểm tra ngân sách» và gửi yêu cầu cho người phụ trách tài chính.

Bộ phận tài chính kiểm tra ngân sách còn lại của phòng ban và từ chối yêu cầu vì số tiền vượt hạn mức hàng tháng. Quy trình yêu cầu bị từ chối giữ nguyên biểu mẫu, báo giá, bình luận và lịch sử phê duyệt trong cùng một nơi. Trạng thái đổi thành «Bị từ chối vì ngân sách», còn người gửi nhận được cập nhật rõ ràng: «Hãy giảm đơn hàng xuống 1.800 USD hoặc chờ đến tháng sau.»

Người gửi xóa hai chiếc màn hình rồi gửi lại yêu cầu. Quy trình tạo một nhiệm vụ kiểm tra tài chính mới thay vì bắt người gửi bắt đầu lại. Bộ phận tài chính phê duyệt số tiền đã chỉnh sửa. Trạng thái chuyển thành «Chờ quản lý phê duyệt» và quản lý nhận được nhiệm vụ cùng toàn bộ lịch sử lần từ chối trước.

Khi phê duyệt đến muộn

Quản lý có hai ngày làm việc để phản hồi. Vào ngày thứ hai, quy trình gửi lời nhắc. Nếu hết hạn, quy tắc quản lý nhiệm vụ quá hạn đổi trạng thái thành «Phê duyệt của quản lý quá hạn» và giao nhiệm vụ chuyển cấp cho trưởng nhóm của quản lý.

Người gửi cũng nhận được cập nhật. Họ có thể thấy yêu cầu đang chờ quyết định được chuyển cấp, cùng thời hạn ban đầu và thời điểm chuyển cấp trong hồ sơ yêu cầu.

Trưởng nhóm phê duyệt đơn hàng sau khi kiểm tra ghi chú ngân sách và báo giá nhà cung cấp. Quy trình đặt yêu cầu ở trạng thái «Đã phê duyệt để mua», giao cho bộ phận mua hàng đặt đơn và thông báo người gửi rằng đơn hàng có thể được tiến hành.

Ví dụ này cho thấy vì sao các ngoại lệ trong quy trình nghiệp vụ cần trạng thái và người phụ trách riêng. Mỗi nhánh nói rõ một người phải làm gì tiếp theo, còn người gửi nhận được cập nhật mà không cần chạy theo mọi người qua chat. Khi bộ phận mua hàng hoàn tất đơn hàng, hồ sơ vẫn lưu yêu cầu bổ sung báo giá, lần từ chối của tài chính, lần gửi lại, phê duyệt trễ và quyết định cuối cùng.

Những sai lầm thường gặp khi xây dựng nhánh ngoại lệ

Các đội ngũ thường xây dựng đường đi thuận lợi trước, sau đó thêm một nhánh chung cho mọi trường hợp khác. Nhánh này thường đổ về một quản lý vốn đã bận rộn. Thông tin thiếu, yêu cầu bị từ chối và phê duyệt trễ cần những người và hành động khác nhau. Gửi tất cả vào một hộp thư chỉ làm công việc chậm lại và che khuất những vấn đề mà đội ngũ có thể khắc phục.

Dùng tên cho biết chuyện gì đã xảy ra và người tiếp theo cần làm gì. «Có vấn đề» và «Cần chú ý» buộc người xét duyệt phải mở từng mục trước khi hiểu tình hình. Các nhãn như «Thiếu báo giá nhà cung cấp», «Bị tài chính từ chối» hoặc «Phê duyệt trễ hai ngày» tạo điểm bắt đầu hữu ích cho người tiếp nhận.

Một vài quy tắc thiết kế có thể ngăn ngoại lệ biến thành những chuỗi email theo dõi:

• Chuyển mỗi ngoại lệ cho người có thể hành động, kèm người phụ trách dự phòng khi họ vắng mặt.
• Cảnh báo người phụ trách trước khi hết hạn, sau đó chuyển cấp nếu không ai phản hồi.
• Yêu cầu người xét duyệt chọn lý do và thêm ghi chú ngắn trước khi từ chối, trả lại hoặc phê duyệt một mục.
• Giữ yêu cầu ban đầu, tệp đính kèm và các bình luận trước đó khi có người yêu cầu chỉnh sửa.
• Ghi lại thời điểm ngoại lệ bắt đầu, người xử lý và thời điểm kết thúc.

Thời hạn không có cảnh báo gây ra một dạng rắc rối đặc biệt. Một nhiệm vụ có thể nằm im nhiều ngày trong khi mọi người đều nghĩ người khác đang phụ trách. Quy tắc quản lý nhiệm vụ quá hạn nên thông báo cho người được giao trước, rồi thông báo cho cấp quản lý cụ thể sau một khoảng thời gian đã định. Dùng quy tắc có thể đo lường, chẳng hạn một lời nhắc sau 24 giờ và chuyển cấp sau 48 giờ.

Các bước kiểm tra cũng cần có giới hạn. Nếu người xét duyệt có thể đưa ra bất kỳ quyết định nào mà không ghi lý do, quy trình kiểm tra thủ công sẽ khó được cải thiện. Theo thời gian, đội ngũ có thể thấy cùng một yêu cầu bị trả lại nhiều lần mà không biết vấn đề nằm ở chi phí, chính sách, bằng chứng thiếu hay trường biểu mẫu sai.

Giữ nguyên yêu cầu khi trả lại để chỉnh sửa. Người gửi phải thấy lý do từ chối bên cạnh thông tin đã gửi, chỉ cập nhật những trường bị ảnh hưởng và gửi lại cùng hồ sơ. Tạo yêu cầu mới sẽ làm mất ngữ cảnh, tạo thêm việc và khiến báo cáo về quy trình yêu cầu bị từ chối kém chính xác.

Xử lý ngoại lệ tốt để lại một hồ sơ mà bất kỳ ai cũng có thể nhanh chóng hiểu. Hồ sơ cho biết vấn đề là gì, ai phụ trách hành động tiếp theo và vì sao yêu cầu đổi hướng.

Kiểm tra nhanh và bước tiếp theo

Một ngoại lệ trong quy trình không bao giờ được để yêu cầu nằm trong một hàng đợi không có tên. Với mỗi nhánh ngoại lệ, hãy xác định sự kiện bắt đầu, người phụ trách và hành động kết thúc. Nhờ vậy, các ngoại lệ trong quy trình nghiệp vụ trở thành công việc thường ngày thay vì việc điều tra vào phút chót.

Trước khi công bố quy trình, hãy kiểm tra xem mọi ngoại lệ đã có điều kiện kích hoạt rõ ràng hay chưa, chẳng hạn trường bắt buộc bị bỏ trống, yêu cầu bị từ chối hoặc quá hạn. Chỉ định một người phụ trách hành động tiếp theo, ngay cả khi nhiều người có thể xem yêu cầu. Thông báo phải nói rõ chuyện gì đã xảy ra, người nhận cần làm gì và khi nào phải làm. Giữ trạng thái hiện tại cùng lịch sử quyết định hiển thị cho những nhân viên cần hành động, đồng thời chuyển việc quá hạn cho một người hoặc vai trò cụ thể thay vì hộp thư chung.

Kiểm thử các nhánh bằng tình huống thực tế. Gửi một yêu cầu không có tệp đính kèm. Từ chối một yêu cầu kèm lý do. Để một yêu cầu phê duyệt vượt thời hạn mà không xử lý. Sau đó kiểm tra xem đúng người có nhận được thông báo hữu ích và có thể hoàn thành nhiệm vụ mà không cần hỏi thêm bối cảnh hay không.

Quy trình yêu cầu bị từ chối cũng cần có đường dẫn quay lại người gửi. Giữ yêu cầu ban đầu, lý do từ chối và ghi chú của người xét duyệt cùng nhau. Người gửi phải có thể sửa vấn đề và gửi lại thay vì tạo một hồ sơ trùng lặp làm mất quyết định trước đó.

Với việc quản lý nhiệm vụ quá hạn, hãy quyết định điều gì xảy ra sau mỗi lần bỏ lỡ thời hạn. Lời nhắc đầu tiên có thể gửi cho người phụ trách nhiệm vụ. Lần chuyển cấp sau đó có thể gửi cho quản lý hoặc người xét duyệt dự phòng. Đừng gửi lời nhắc vô thời hạn. Hãy đặt một thời điểm mà ai đó phải hoàn thành, giao lại, gia hạn hoặc đóng nhiệm vụ.

AppMaster cho phép đội ngũ tạo các nhánh này bằng quy trình nghiệp vụ trực quan. Đội ngũ có thể mô hình hóa thay đổi trạng thái, thời hạn, thông báo, phê duyệt và kiểm tra thủ công mà không cần tự viết logic quy trình. Hãy bắt đầu với một quy trình có khối lượng lớn, kiểm thử các tình huống ngoại lệ cùng những người sử dụng quy trình và điều chỉnh các nhánh khi công việc thực tế cho thấy điểm thiếu.

Xem lại quy trình sau vài tuần đầu tiên. Đếm những ngoại lệ xảy ra thường xuyên nhất và đọc ghi chú từ các lần kiểm tra thủ công. Nếu cùng một thông tin thiếu gây chậm trễ lặp đi lặp lại, hãy sửa biểu mẫu yêu cầu hoặc thêm bước kiểm tra sớm hơn. Những điều chỉnh nhỏ ở đầu quy trình sẽ ngăn ngoại lệ tích tụ về sau.