Phần mềm quy trình phê duyệt thủ công hoạt động tốt nhất khi bạn xác định trạng thái, người chịu trách nhiệm, hạn chót và ngoại lệ trước khi thêm nhắc nhở hoặc quy tắc tự động.
Email hoạt động cho phê duyệt khi quy trình nhỏ và không chính thức. Một người gửi yêu cầu, người khác trả lời, và công việc tiến triển. Nhưng khi nhiều người tham gia hơn, các vết nứt hiện ra rất nhanh.
Vấn đề đầu tiên là tính hiển thị. Yêu cầu phê duyệt nằm cạnh bản tin, lời mời lịch và tin nhắn hàng ngày. Ai đó định xem lại sau, rồi nó rơi xuống đáy hộp thư và biến mất.
Vấn đề tiếp theo là nhầm lẫn phiên bản. Một người trả lời luồng gốc, người khác chuyển tiếp tệp đính kèm đã sửa, và người khác lại phê duyệt một bản cũ hơn. Sau vài vòng, chẳng ai chắc file, giá cả hay câu chữ nào là hiện hành.
Quyền sở hữu cũng mơ hồ. Nếu một yêu cầu cần ý kiến từ tài chính, pháp chế và trưởng nhóm, ai chịu trách nhiệm khi việc ngưng trệ? Trong email, câu trả lời thường không rõ ràng. Mọi người nghĩ người khác đang xử lý, nên không ai làm gì.
Mọi thứ tệ hơn khi ai đó nghỉ hoặc đường đi thay đổi theo số tiền, rủi ro hoặc loại khách hàng. Những ngoại lệ đó thường nằm trong đầu mọi người thay vì một quy trình chung. Điều đó khiến đường đi phê duyệt khó dự đoán và còn khó theo dõi hơn.
Chi phí lớn hơn vài phản hồi chậm. Trì hoãn có thể trì hoãn mua sắm, hợp đồng, ra mắt, quyết định tuyển dụng và công việc cho khách hàng. Đội phải đi truy cập cập nhật thay vì làm công việc chính.
Một ví dụ đơn giản cho thấy vấn đề. Một yêu cầu giảm giá bán hàng gửi cho quản lý bằng email, rồi được chuyển tiếp cho tài chính. Tài chính yêu cầu con số sửa lại, nhưng nhân viên sales chỉ cập nhật một luồng. Quản lý phê duyệt phiên bản trước đó, tài chính chờ xác nhận, và khách hàng không nghe tin trong hai ngày.
Đó là lý do nhiều đội bắt đầu tìm phần mềm quy trình phê duyệt thủ công. Vấn đề thực sự không chỉ là tốc độ. Email che giấu trạng thái, quyền sở hữu, hạn chót và ngoại lệ cho tới khi có sự cố.
Trước khi bạn xây dựng bất cứ thứ gì trong phần mềm, hãy ghi lại quy trình phê duyệt đang vận hành thực tế. Nếu bỏ qua bước đó, bạn có khả năng sao chép sự rối rắm từ email vào công cụ mới thay vì sửa nó.
Bắt đầu nhỏ. Đừng chuyển mọi luồng phê duyệt cùng lúc. Chọn một quy trình xảy ra thường xuyên, gây trì hoãn, hoặc tạo nhiều công việc theo dõi nhất, như yêu cầu mua sắm, duyệt nội dung, phê duyệt chiết khấu, hoặc yêu cầu truy cập.
Rồi xem vài ví dụ thực tế. Ba đến năm luồng email gần đây thường đủ để cho thấy mẫu. Dùng các trường hợp thực, không dựa trên trí nhớ. Mọi người quên các bàn giao nhỏ, trả lời phụ và ngoại lệ phút cuối.
Khi xem các ví dụ đó, ghi lại những điều cơ bản bằng ngôn ngữ đơn giản:
Cũng ghi lại thông tin mỗi bước cần. Quản lý có thể cần số ngân sách, tên nhà cung cấp và ngày cần hàng trước khi quyết định. Nếu thông tin đó thường thiếu, vấn đề trì hoãn không phải là phê duyệt mà là chất lượng yêu cầu.
Hạn chót cũng thuộc bản đồ. Ghi lại thời gian mỗi bước nên mất, chuyện gì xảy ra nếu không ai phản hồi, và liệu yêu cầu khẩn có đi theo đường khác không. Liệt kê quy tắc ngoại lệ luôn. Có thể phê duyệt trên một mức nhất định cần tài chính xem xét. Có thể người phê duyệt dự phòng sẽ vào thay nếu người chính vắng.
Đặt toàn bộ quy trình trên một trang dùng từ mọi người đã quen. Viết “Finance checks the amount” hoặc “Manager asks for missing details,” chứ không phải thứ trừu tượng và kiểu hệ thống. Mục tiêu là quy trình mọi người nhận ra, không phải sơ đồ trông bóng bẩy.
Khi những người làm công việc nói, “Đúng, đây là cách nó thực sự diễn ra,” bản đồ của bạn đã sẵn sàng.
Một danh sách trạng thái tốt nên qua một bài kiểm tra đơn giản: nếu hai người đọc cùng một yêu cầu, họ nên đi đến cùng kết luận về bước tiếp theo.
Đó là lý do phần mềm quy trình phê duyệt thủ công hoạt động tốt nhất với danh sách trạng thái ngắn, rõ ràng. Hầu hết đội không cần mười nhãn. Họ cần một vài nhãn cho biết yêu cầu đang đứng ở đâu ngay bây giờ.
Một điểm khởi đầu thực tế có thể như sau:
Mỗi trạng thái nên mang một ý nghĩa duy nhất. “Waiting for approval” nghĩa là yêu cầu sẵn sàng và ai đó phải xem. “Needs changes” nghĩa là chưa được phê duyệt nhưng có thể quay lại sau khi cập nhật. “Rejected” nghĩa là yêu cầu dừng lại trừ khi có quy tắc cho phép mở lại.
Sự nhầm lẫn bắt đầu khi đội tạo các nhãn gần giống như “Pending,” “In review,” “Under review,” và “Awaiting sign-off.” Với hệ thống, chúng khác nhau. Với con người, thường cùng một ý. Điều đó dẫn đến báo cáo lộn xộn, bàn giao không rõ, và nhiều câu hỏi phụ.
Nếu một trạng thái cần giải thích dài, hãy đổi tên nó. Nhãn tốt dễ quét trong danh sách, dashboard hoặc màn hình di động. Mọi người nên hiểu ngay mà không cần mở bản ghi.
Cũng thông minh khi tách trạng thái khỏi quyền sở hữu. “Waiting for approval” thường rõ hơn “With finance.” Cái trước cho biết trạng thái của yêu cầu. Cái sau trộn trạng thái với người xem hiện tại.
Bắt đầu với tập nhỏ nhất có thể dùng. Bạn luôn có thể thêm trạng thái sau nếu điều đó giải quyết vấn đề thực sự.
Một quy trình sụp đổ nhanh khi một bước thuộc về “nhóm” thay vì một cá nhân. Mỗi giai đoạn cần một chủ sở hữu rõ ràng. Người đó có thể xin ý kiến người khác, nhưng một tên hoặc vai trò phải chịu trách nhiệm di chuyển yêu cầu.
Điều này càng quan trọng hơn khi bạn chuyển từ chuỗi email sang phần mềm. Trong email, mọi người dựa vào thói quen. Ai đó để ý luồng, chuyển tiếp, hoặc nhắc người tiếp theo. Phần mềm không thể phụ thuộc vào loại suy đoán đó.
Với mỗi bước, trả lời bốn câu hỏi đơn giản:
Bàn giao cũng nên rõ ràng. Nếu quản lý phê duyệt và tài chính xem xét tiếp theo, hãy nói rõ trong quy trình. Đừng để là “gửi đến finance” trừ khi hệ thống biết người hoặc vai trò cụ thể nào sẽ nhận.
Lấy ví dụ yêu cầu thiết bị đơn giản. Nó bắt đầu với quản lý của nhân viên. Nếu chi phí vượt một mức, nó chuyển sang tài chính. Nếu người tài chính vắng, một controller dự phòng tiếp quản sau một ngày làm việc. Nếu người yêu cầu lập sai, chỉ người yêu cầu và người phê duyệt đầu tiên có thể mở lại. Nếu yêu cầu không còn cần nữa, chỉ người yêu cầu hoặc quản lý phòng ban có thể hủy.
Những quy tắc này có thể cảm thấy nghiêm ngặt, nhưng chúng ngăn những rối rắm thường thấy: yêu cầu bị treo, duyệt trùng, và khoảng trống dài nơi ai cũng nghĩ người khác chịu trách nhiệm.
Một quy trình bị tắc khi chỉ có một hạn chót cho toàn bộ yêu cầu. Mỗi giai đoạn cần ngày hoàn thành riêng để đội thấy chính xác chỗ nào đang mất thời gian.
Ví dụ, xem xét có thể được cho một ngày làm việc, tài chính hai ngày, và pháp chế ba ngày. Trong hầu hết trường hợp, đồng hồ nên bắt đầu khi yêu cầu vào một trạng thái, không phải khi email đầu tiên được gửi. Điều đó giúp việc phát hiện việc quá hạn dễ dàng hơn.
Trước khi tự động hóa, xác định bốn điều cơ bản:
Khi trễ hạn, hãy quyết trước bước tiếp theo. Một quy tắc đơn giản thường hiệu quả nhất: gửi một lời nhắc, rồi nâng cấp cho người dự phòng hoặc trưởng nhóm nếu không có thay đổi. Đừng để công việc quá hạn nằm trong cùng trạng thái mà không có hành động.
Yêu cầu khẩn cấp cần đường đi riêng nhưng giữ hạn hẹp. Nếu mọi thứ đều có thể đánh dấu là khẩn cấp, nhãn đó trở nên vô dụng. Giới hạn cho vài trường hợp rõ ràng, như vấn đề ảnh hưởng khách hàng hoặc thời hạn tuân thủ.
Quy tắc ngoại lệ quan trọng không kém. Nếu yêu cầu thiếu thông tin, chuyển nó sang trạng thái như “Waiting for requester” và tạm dừng đồng hồ. Nếu bị từ chối nhưng có thể sửa, gửi nó vào làm lại thay vì đóng. Nếu nằm ngoài chính sách bình thường, điều hướng đến người phê duyệt ngoại lệ được nêu tên thay vì để mọi người ứng biến bằng email.
Một yêu cầu mua sắm đơn giản cho thấy tại sao điều này quan trọng. Tài chính nhận yêu cầu nhưng thiếu báo giá nhà cung cấp. Nếu không có quy tắc, hạn chót tài chính hết và mọi người bối rối. Với quy tắc, yêu cầu chuyển sang “Missing information,” người yêu cầu trở thành chủ sở hữu tích cực, và hạn chót tạm dừng cho đến khi báo giá được thêm.
Hãy tưởng tượng một yêu cầu mua laptop mới. Nhân viên điền biểu mẫu với món hàng, chi phí, lý do và ngày cần. Quy trình không cần phức tạp.
Một phiên bản cơ bản có thể dùng các trạng thái sau:
Yêu cầu bắt đầu ở Submitted và đến quản lý. Nếu nhân viên chỉ ghi “laptop for new hire” và không có mã ngân sách, quản lý không nên phê duyệt rồi giải thích trong email phụ. Sạch hơn là chuyển trạng thái sang Needs more info và gửi trả lại. Nhân viên trở thành chủ sở hữu, thêm chi tiết thiếu và gửi lại.
Khi yêu cầu hoàn chỉnh, quản lý xem và chuyển sang Manager approved. Quyền sở hữu sau đó chuyển cho tài chính. Tài chính kiểm tra ngân sách, quy tắc nhà cung cấp và giới hạn chi tiêu. Nếu mọi thứ ổn, trạng thái thành Finance approved.
Bây giờ thêm ngoại lệ thực tế. Người phê duyệt tài chính nghỉ ốm ba ngày. Nếu không có quy tắc, yêu cầu chỉ ngồi yên. Cấu hình tốt hơn là nêu tên người dự phòng trước. Sau khi hạn chót qua, hoặc ngay khi biết vắng mặt, yêu cầu chuyển sang người dự phòng thay vì chờ vô thời hạn.
Khi tài chính phê duyệt, yêu cầu thành Completed. Nếu đội sau muốn thêm bước mua riêng, bạn có thể thêm sau. Phiên bản đầu nên giữ đơn giản.
Sai lầm lớn nhất là sao chép chính xác quy trình email. Điều đó có vẻ an toàn, nhưng thường khóa các vấn đề cũ vào hệ thống mới.
Email che giấu điểm yếu. Mọi người giải thích trong các luồng phụ, đi theo cách thủ công để cập nhật, và phê duyệt mà không có quy tắc rõ ràng. Nếu cùng quy trình đó chuyển vào phần mềm không đổi, sự bối rối không biến mất. Chỉ là nó dễ thấy hơn.
Sai lầm khác là thêm quá nhiều chi tiết quá sớm. Đội tạo danh sách trạng thái dài vì muốn mọi bước nhỏ đều hiển thị. Thực tế, điều đó làm quy trình khó theo dõi hơn. Nếu một yêu cầu có thể được đánh dấu pending review, under review, waiting for comments, sent back, resubmitted và ready for sign-off, hầu hết mọi người sẽ không biết dùng nhãn nào.
Cùng vấn đề xảy ra với người duyệt. Nếu thêm năm người chỉ để phòng trường hợp, công việc chậm lại và không ai cảm thấy thực sự chịu trách nhiệm.
Một vài dấu hiệu cảnh báo xuất hiện nhanh:
Đội cũng vội thiết lập nhắc nhở và nâng cấp trước khi quy tắc cơ bản được chốt. Nhắc nhở chỉ có ích khi hệ thống đã biết chờ nghĩa là gì, ai trễ, và bước tiếp theo là gì. Nếu các quy tắc mơ hồ, nhắc nhở chỉ tạo ra nhiễu.
Sai lầm khác là bỏ qua ngoại lệ cho tới sau khi ra mắt. Chuỗi phê duyệt thực luôn có ngoại lệ. Ai đó nghỉ ốm. Yêu cầu khẩn cấp. Biểu mẫu thiếu. Một mục bị từ chối quay lại sau khi chỉnh sửa. Nếu những tình huống đó không được lập kế hoạch sớm, mọi người sẽ quay lại email lần đầu có chuyện lạ xảy ra.
Đơn giản tốt hơn đầy đủ ở ngày đầu. Sửa các bước yếu trước, giữ ít trạng thái, phân công một người cho mỗi bước, và quyết ngoại lệ trước khi thêm tự động hóa.
Trước khi bật quy tắc định tuyến, nhắc nhở hoặc nâng cấp, kiểm tra xem quy trình có đủ rõ để hoạt động không email hay không.
Bài kiểm tra hữu ích rất đơn giản: một yêu cầu chuẩn có thể đi từ bắt đầu đến kết thúc theo một đường rõ ràng trong hầu hết trường hợp không? Nếu không, sửa đường đi trước.
Trả lời những câu sau:
Nếu bạn không thể trả lời rõ, tạm dừng. Nhãn sạch, quyền sở hữu rõ và quy tắc ngoại lệ viết ra cứu nhiều thời gian hơn tự động hóa thông minh.
Đó là lý do nhiều đội phác thảo quy trình trong tài liệu đơn giản hoặc trên bảng trắng trước khi xây dựng trong công cụ. Nếu bạn đang tạo ứng dụng phê duyệt nội bộ, Koder.ai có thể là cách thực tế để biến mô tả bằng ngôn ngữ thường thành phần mềm làm việc mà không cần chu kỳ phát triển dài.
Đừng triển khai quy trình mới cho toàn công ty cùng lúc. Bắt đầu với một đội và một loại yêu cầu, như phê duyệt mua sắm hoặc duyệt nội dung. Một thí điểm nhỏ giúp dễ phát hiện vấn đề trước khi nó lan rộng.
Đây là lúc phần mềm quy trình phê duyệt thủ công tạo niềm tin hoặc gây phản kháng. Nếu mọi người hoàn thành yêu cầu thực tế với ít bối rối hơn email, việc áp dụng sẽ dễ hơn nhiều.
Chọn một luồng xảy ra đủ thường để kiểm tra, nhưng không rủi ro nếu bạn cần thay đổi sau một tuần. Hãy rõ với nhóm thí điểm rằng mục tiêu không phải hoàn hảo, mà là tìm những chỗ vụn vặt khi việc triển khai còn nhỏ.
Trong thí điểm, để ý những lúc mọi người rời hệ thống và làm thủ công. Đó thường là dấu rõ ràng nhất còn thiếu.
Chú ý:
Sau vài trường hợp thực, siết chặt những điều cơ bản trước khi thêm chức năng. Sửa bàn giao mơ hồ, đơn giản tên trạng thái, và điều chỉnh hạn chót cho phù hợp. Hoãn báo cáo, nâng cấp và tự động bổ sung cho tới khi luồng cốt lõi hoạt động trơn.
Chu kỳ rà soát đơn giản hữu ích. Kiểm tra sau 5–10 yêu cầu đầu tiên, rồi lại sau hai tuần. Hỏi một câu rõ ràng: chỗ nào mọi người vẫn cần thủ thuật?
Nếu bạn muốn thử công cụ nội bộ nhanh, Koder.ai hữu ích để nguyên mẫu loại quy trình đó từ chat và biến nó thành ứng dụng hoạt động. Thường vậy là đủ để xác thực quy trình trước khi cam kết triển khai lớn hơn.
Một triển khai an toàn thường nhàm chán theo thiết kế. Đó là dấu hiệu tốt. Mọi người nên biết chuyện gì xảy ra tiếp theo, ai chịu trách nhiệm, và phải làm gì khi có chuyện không theo đường bình thường.
Hãy chuyển khỏi email khi các phê duyệt liên quan hơn một hoặc hai người, phụ thuộc vào thời hạn, hoặc thường cần theo dõi. Nếu mọi người liên tục hỏi trạng thái, phê duyệt sai phiên bản, hoặc mất yêu cầu trong hộp thư, email đang tiêu tốn thời gian và tạo rủi ro.
Ghi lại quy trình thực tế như nó đang diễn ra hôm nay. Xem qua vài chuỗi phê duyệt gần đây và viết ra cách bắt đầu yêu cầu, ai duyệt, thông tin cần có, chỗ nào lặp vòng, và cách kết thúc. Điều này giúp bạn xây dựng quy trình sạch thay vì sao chép hỗn loạn trong hộp thư vào công cụ mới.
Bắt đầu với một tập trạng thái nhỏ mà mọi người hiểu ngay. Trong nhiều trường hợp, bốn hoặc năm trạng thái là đủ, ví dụ: Draft, Waiting for approval, Approved, Rejected và Needs changes. Nếu hai nhãn gần như giống nhau, hãy bỏ một nhãn.
Thông thường không. Trạng thái nên cho biết tình trạng của yêu cầu, không phải ai đang giữ nó. Nhãn như Waiting for approval rõ hơn With finance, vì ownership có thể thay đổi trong khi trạng thái vẫn giữ nguyên.
Cho mỗi bước một chủ sở hữu rõ ràng và một người dự phòng. Nếu người duyệt chính vắng mặt, người dự phòng sẽ tiếp quản theo quy tắc đơn giản, ví dụ sau một ngày làm việc. Điều đó ngăn yêu cầu bị treo vô thời hạn.
Đặt ngày hoàn thành cho từng bước, không chỉ cho toàn bộ yêu cầu. Đồng hồ nên bắt đầu khi yêu cầu vào trạng thái đó. Nếu trễ hạn, hành động tiếp theo phải được định trước, ví dụ gửi nhắc nhở một lần rồi nâng cấp cho người dự phòng hoặc trưởng nhóm.
Gửi yêu cầu trở lại quy trình với trạng thái rõ ràng như Needs more info hoặc Waiting for requester. Làm cho người yêu cầu trở thành chủ sở hữu tích cực lại và tạm dừng đồng hồ cho đến khi thông tin thiếu được bổ sung. Cách này sạch hơn so với xử lý qua email phụ.
Không, các yêu cầu khẩn cấp nên có con đường riêng nhưng hẹp. Giữ quy tắc chặt để người ta không gắn nhãn mọi thứ là khẩn cấp. Dành cho các trường hợp rõ ràng như ảnh hưởng khách hàng, thời hạn tuân thủ, hoặc công việc cần xử lý ngay.
Sai lầm phổ biến nhất là sao chép quy trình email nguyên trạng. Các vấn đề khác gồm quá nhiều trạng thái, quá nhiều người duyệt, ownership mơ hồ, và quy tắc ngoại lệ chỉ được định nghĩa sau khi triển khai. Bắt đầu đơn giản và sửa những bước yếu trước.
Chạy thử nghiệm nhỏ với một đội và một loại yêu cầu trước khi triển khai rộng. Theo dõi chỗ mọi người vẫn quay về email hoặc chat, rồi điều chỉnh trạng thái, bàn giao và thời hạn. Nếu muốn tạo nguyên mẫu nhanh, Koder.ai có thể giúp chuyển quy trình ngôn ngữ thường thành công cụ hoạt động mà không cần chu kỳ phát triển dài.
