Có nên chuẩn hóa trước khi tự động hóa?

Nếu quy trình đầu vào còn mơ hồ, mỗi nhân viên làm một cách, dữ liệu thiếu cấu trúc và quy tắc xử lý thường xuyên thay đổi, tự động hóa có thể khiến sai sót xảy ra nhanh hơn, trên quy mô lớn hơn và khó sửa hơn. Ngược lại, khi quy trình đã có đầu vào, đầu ra, trách nhiệm, quy tắc và tiêu chí kiểm soát rõ ràng, công nghệ mới có một nền tảng ổn định để vận hành.

Tuy nhiên, “chuẩn hóa trước” không có nghĩa doanh nghiệp phải hoàn thiện quy trình đến mức tuyệt đối rồi mới được sử dụng công nghệ. Cách tiếp cận phù hợp hơn là chuẩn hóa đến mức đủ để kiểm soát, tự động hóa từng phần ổn định, đo lường kết quả và tiếp tục cải tiến.

Chuẩn hóa quy trình trước khi tự động hóa là gì?

Chuẩn hóa quy trình là xác lập một phương thức thực hiện thống nhất, có thể lặp lại và đang được xem là cách làm tốt nhất tại thời điểm hiện tại. Một quy trình được chuẩn hóa thường làm rõ:

·         Sự kiện hoặc điều kiện khởi động quy trình

·         Đầu vào cần có

·         Các bước xử lý chính

·         Thứ tự và mối quan hệ giữa các bước

·         Người hoặc bộ phận chịu trách nhiệm

·         Quy tắc ra quyết định

·         Đầu ra cần tạo

·         Tiêu chí kiểm tra chất lượng

·         Các ngoại lệ và cách xử lý

·         Chỉ số dùng để đánh giá hiệu quả

Chuẩn hóa không chỉ là viết tài liệu hướng dẫn. Một quy trình chỉ thực sự được chuẩn hóa khi cách làm đã thống nhất trên thực tế, người thực hiện hiểu và tuân thủ nó, còn kết quả có thể được quan sát hoặc đo lường.

Trong tư duy Lean, công việc tiêu chuẩn hóa được xem là cách thực hiện tốt nhất hiện biết, đồng thời là đường cơ sở để tiếp tục cải tiến. Tiêu chuẩn vì vậy không phải trạng thái cố định vĩnh viễn mà là một phiên bản có kiểm soát, có thể được thay thế khi xuất hiện cách làm tốt hơn.

Tự động hóa là việc sử dụng công nghệ, phần mềm hoặc thiết bị để thực hiện công việc với mức can thiệp của con người thấp hơn. Khi tự động hóa, doanh nghiệp phải chuyển cách làm thành các điều kiện, quy tắc, luồng dữ liệu và hành động cụ thể mà hệ thống có thể thực thi.

Do đó, chuẩn hóa và tự động hóa có quan hệ trực tiếp:

Chuẩn hóa xác định hệ thống cần làm gì; tự động hóa giúp hệ thống thực hiện điều đó nhanh, ổn định và có khả năng mở rộng.

Vì sao phải chuẩn hóa trước khi tự động hóa?

Tự động hóa không sửa được một quy trình sai về bản chất

Một quy trình có thể tồn tại nhiều loại lãng phí:

·         Phê duyệt không tạo thêm giá trị

·         Nhập lại cùng một dữ liệu ở nhiều hệ thống

·         Chuyển giao qua quá nhiều bộ phận

·         Kiểm tra lặp lại

·         Thu thập thông tin không phục vụ quyết định

·         Xử lý lại do dữ liệu đầu vào không đầy đủ

·         Chờ đợi vì trách nhiệm không rõ ràng

Nếu tự động hóa ngay, doanh nghiệp có thể rút ngắn thời gian thực hiện các bước này nhưng vẫn giữ nguyên sự lãng phí. Trong trường hợp đó, công nghệ chỉ làm cho một quy trình chưa hợp lý chạy nhanh hơn.

Chẳng hạn, một yêu cầu mua hàng phải đi qua năm cấp phê duyệt dù ba cấp trong số đó luôn phê duyệt mà không bổ sung kiểm soát nào. Tự động gửi yêu cầu qua năm cấp có thể giảm thời gian chuyển tiếp, nhưng không giải quyết câu hỏi quan trọng hơn: cả năm cấp có thực sự cần thiết hay không?

Vì vậy, trước khi tự động hóa cần phân biệt ba hoạt động:

1.    Loại bỏ bước không cần thiết

2.    Chuẩn hóa những bước còn cần thiết

3.    Tự động hóa phần công việc đã đủ rõ ràng

Trình tự này giúp doanh nghiệp tránh đầu tư công nghệ để duy trì những thao tác vốn nên được loại bỏ.

Hệ thống cần một logic xử lý rõ ràng

Con người có thể xử lý những chỉ dẫn mơ hồ bằng kinh nghiệm, trao đổi trực tiếp hoặc phán đoán theo bối cảnh. Phần mềm không có khả năng đó trừ khi các điều kiện đã được chuyển thành logic cụ thể.

Một quy định như “đơn hàng lớn cần được cấp trên xem xét” chưa đủ để tự động hóa. Hệ thống cần biết:

·         “Lớn” là từ giá trị nào

·         Giá trị được tính trước hay sau thuế

·         Cấp trên nào có quyền phê duyệt

·         Trường hợp nào cần thêm bộ phận tài chính

·         Thời hạn phản hồi là bao lâu

·         Chuyện gì xảy ra khi người phê duyệt vắng mặt

·         Yêu cầu bị từ chối sẽ quay về bước nào

Chuẩn hóa buộc tổ chức chuyển tri thức ngầm trong đầu nhân viên thành quy tắc có thể mô tả và kiểm tra. Đây là điều kiện quan trọng để thiết kế workflow, RPA, hệ thống quản trị quy trình hoặc giải pháp tích hợp.

Chuẩn hóa làm giảm biến thể mà hệ thống phải xử lý

Biến thể là sự khác nhau trong cách một quy trình được thực hiện. Biến thể có thể xuất hiện ở:

·         Định dạng dữ liệu đầu vào

·         Tên và cấu trúc tài liệu

·         Thứ tự thao tác

·         Tiêu chí phê duyệt

·         Cách phân loại trường hợp

·         Cách xử lý ngoại lệ

·         Hệ thống hoặc biểu mẫu được sử dụng

Biến thể càng cao, giải pháp tự động hóa càng phải có nhiều nhánh điều kiện. Điều này làm tăng độ phức tạp phát triển, kiểm thử, vận hành và bảo trì.

Trong đánh giá tiềm năng tự động hóa của UiPath, mức độ cấu trúc của dữ liệu đầu vào và mức biến thiên của quy trình là hai yếu tố trực tiếp ảnh hưởng đến khả năng một quy trình có thể được robot thực hiện.

Chuẩn hóa không nhất thiết loại bỏ mọi biến thể. Mục tiêu là tách chúng thành ba nhóm:

·         Luồng chính có thể xử lý theo một cách thống nhất

·         Các biến thể hợp lệ có quy tắc rõ ràng

·         Ngoại lệ cần con người đánh giá

Khi ba nhóm này được phân biệt, doanh nghiệp có thể tự động hóa luồng chính, thiết kế nhánh xử lý cho biến thể hợp lệ và chuyển ngoại lệ đến đúng người phụ trách.

Chuẩn hóa tạo đường cơ sở để đo hiệu quả

Doanh nghiệp không thể kết luận tự động hóa thành công chỉ vì hệ thống đã hoạt động. Cần so sánh kết quả trước và sau triển khai bằng các chỉ số như:

·         Thời gian xử lý trung bình

·         Thời gian chờ

·         Tỷ lệ hoàn thành đúng hạn

·         Tỷ lệ sai sót

·         Tỷ lệ phải xử lý lại

·         Chi phí trên mỗi giao dịch

·         Số trường hợp cần can thiệp thủ công

·         Tỷ lệ ngoại lệ

·         Mức độ tuân thủ

·         Năng lực xử lý trong một khoảng thời gian

Nếu quy trình trước tự động hóa không có cách thực hiện thống nhất, dữ liệu đo lường sẽ phản ánh nhiều cách làm khác nhau. Khi đó, doanh nghiệp khó xác định phần cải thiện đến từ công nghệ, phần nào đến từ thay đổi nhân sự và phần nào chỉ là dao động tự nhiên.

Cách tiếp cận theo quá trình của ISO 9001 nhấn mạnh việc xác định các hoạt động liên quan, kiểm soát đầu ra, theo dõi, đo lường và đánh giá hiệu suất để hiểu quy trình hoạt động ra sao và có thể cải tiến ở đâu.

Chuẩn hóa tạo ra đường cơ sở chung. Nhờ đó, doanh nghiệp có thể đánh giá tác động thực tế của tự động hóa thay vì dựa vào cảm nhận.

Chuẩn hóa giúp xác định đúng phạm vi tự động hóa

Không phải mọi bước trong một quy trình đều nên tự động hóa. Một quy trình thường gồm hỗn hợp các hoạt động:

·         Công việc lặp lại dựa trên quy tắc

·         Quyết định cần phán đoán

·         Trao đổi cần sự đồng cảm hoặc thương lượng

·         Kiểm tra tuân thủ

·         Xử lý ngoại lệ

·         Hoạt động có tần suất thấp

·         Thao tác phụ thuộc vào dữ liệu chưa số hóa

Khi chưa chuẩn hóa, các hoạt động này thường bị trộn lẫn. Doanh nghiệp dễ lựa chọn phạm vi quá lớn và cố xây dựng một giải pháp bao phủ mọi tình huống.

Sau khi lập bản đồ và chuẩn hóa quy trình, tổ chức có thể nhìn thấy:

·         Bước nào ổn định và lặp lại

·         Bước nào có quy tắc rõ ràng

·         Bước nào tạo ra nhiều thời gian chờ

·         Bước nào có tỷ lệ lỗi cao

·         Bước nào cần giữ quyền quyết định của con người

·         Bước nào chưa đủ dữ liệu để tự động hóa

Nhờ đó, phạm vi triển khai trở nên nhỏ hơn nhưng có khả năng thành công cao hơn.

Chuẩn hóa giảm chi phí thay đổi và bảo trì

Chi phí tự động hóa không kết thúc sau khi đưa hệ thống vào sử dụng. Mỗi thay đổi trong biểu mẫu, chính sách, thứ tự thao tác, cấu trúc dữ liệu hoặc hệ thống liên quan đều có thể yêu cầu sửa logic, kiểm thử lại và cập nhật tài liệu.

Nếu quy trình chưa ổn định, các thay đổi diễn ra liên tục. Đội dự án có thể rơi vào vòng lặp:

·         Vừa xây xong thì nghiệp vụ đổi cách làm

·         Vừa kiểm thử thì xuất hiện một ngoại lệ mới

·         Vừa triển khai thì một bộ phận sử dụng biểu mẫu khác

·         Vừa tích hợp thì nguồn dữ liệu thay đổi

·         Vừa đào tạo xong thì quy tắc phê duyệt được điều chỉnh

Lúc này, chi phí bảo trì tăng không hẳn vì công nghệ kém mà vì đối tượng được tự động hóa chưa ổn định.

Chuẩn hóa giúp thiết lập quyền sở hữu quy trình và cơ chế kiểm soát thay đổi. Khi cần điều chỉnh, doanh nghiệp có thể đánh giá tác động, cập nhật phiên bản và triển khai thay đổi có kế hoạch thay vì sửa hệ thống theo từng yêu cầu phát sinh.

Điều gì xảy ra nếu tự động hóa một quy trình chưa chuẩn hóa?

Sai sót được nhân rộng nhanh hơn

Một người thực hiện sai có thể tạo ra một số lượng lỗi giới hạn. Một hệ thống thực hiện sai có thể lặp lại lỗi trên toàn bộ giao dịch mà nó xử lý.

Nếu quy tắc phân loại khách hàng sai, hệ thống có thể áp dụng sai chính sách cho hàng nghìn hồ sơ. Nếu công thức kiểm tra hóa đơn thiếu một điều kiện, mọi hóa đơn đáp ứng điều kiện đó đều có thể bị xử lý không chính xác.

Khả năng vận hành nhanh và nhất quán chỉ là lợi ích khi logic cơ sở đúng. Nếu logic sai, hai đặc tính đó làm tăng quy mô ảnh hưởng.

Ngoại lệ biến thành lỗi hệ thống

Trong quy trình chưa chuẩn hóa, ngoại lệ thường được xử lý bằng trao đổi cá nhân. Người thực hiện biết phải gọi cho ai, xin xác nhận ở đâu hoặc bỏ qua bước nào trong một tình huống đặc biệt.

Khi tự động hóa, những tri thức này không tự động được đưa vào hệ thống. Một trường hợp mà nhân viên có thể giải quyết trong vài phút có thể khiến workflow dừng, tạo dữ liệu sai hoặc chuyển yêu cầu đến nhầm bộ phận.

Ngoại lệ không được nhận diện trước cũng làm phát sinh nhiều can thiệp thủ công. Kết quả là quy trình mang danh tự động nhưng nhân viên vẫn phải thường xuyên giám sát và sửa lỗi.

Tổ chức mất khả năng xác định nguyên nhân

Khi hệ thống tạo ra kết quả không đúng, nguyên nhân có thể nằm ở:

·         Quy trình nghiệp vụ

·         Quy tắc được cung cấp cho đội triển khai

·         Dữ liệu đầu vào

·         Thiết kế hệ thống

·         Cấu hình

·         Tích hợp

·         Thao tác của người dùng

·         Một ngoại lệ chưa được mô hình hóa

Nếu quy trình chuẩn không tồn tại, đội nghiệp vụ và đội công nghệ không có một điểm tham chiếu chung để phân tích. Tranh luận dễ chuyển thành câu hỏi “ai làm sai” thay vì “bước nào không đáp ứng tiêu chuẩn”.

Công nghệ khóa chặt cách làm chưa tối ưu

Sau khi một quy trình đã được cấu hình trong hệ thống, thay đổi thường cần ngân sách, thời gian, kiểm thử và phê duyệt. Điều này tạo ra quán tính: tổ chức tiếp tục sử dụng cách làm cũ chỉ vì nó đã được lập trình.

Một quy trình thủ công chưa tốt có thể được điều chỉnh tương đối nhanh. Nhưng khi quy trình đó đã gắn với nhiều hệ thống và tích hợp, việc cải tiến trở nên khó khăn hơn. Vì thế, tự động hóa quá sớm có thể biến một vấn đề vận hành thành một khoản nợ công nghệ dài hạn.

Quy trình cần được chuẩn hóa đến mức nào?

Không cần chờ đến khi quy trình hoàn hảo. Trên thực tế, không có quy trình nào đạt trạng thái tối ưu vĩnh viễn. Mức chuẩn hóa phù hợp là mức đủ để hệ thống có thể thực hiện luồng chính một cách có kiểm soát.

Trước khi tự động hóa, quy trình nên đáp ứng tối thiểu các điều kiện sau:

Mục tiêu và đầu ra đã rõ ràng

Các bên liên quan thống nhất quy trình nhằm tạo ra kết quả gì và thế nào được xem là hoàn thành đúng.

Luồng chính có thể mô tả

Phần lớn trường hợp đi qua một chuỗi bước tương đối ổn định, không phụ thuộc hoàn toàn vào kinh nghiệm riêng của từng cá nhân.

Quy tắc quyết định có thể diễn đạt

Các điều kiện như phê duyệt, phân loại, chuyển tuyến hoặc từ chối có thể được mô tả bằng tiêu chí cụ thể.

Đầu vào có tiêu chuẩn tối thiểu

Dữ liệu cần thiết, trường bắt buộc, định dạng, nguồn cung cấp và yêu cầu chất lượng đã được xác định.

Vai trò và quyền hạn được phân công

Mỗi bước có người hoặc bộ phận chịu trách nhiệm; quyền phê duyệt và cơ chế thay thế khi vắng mặt được làm rõ.

Ngoại lệ phổ biến đã được nhận diện

Doanh nghiệp không cần dự đoán mọi tình huống hiếm gặp, nhưng phải biết những ngoại lệ thường xuyên và cách chuyển chúng sang xử lý thủ công.

Có chỉ số đường cơ sở

Tổ chức có dữ liệu đủ để biết quy trình hiện tại mất bao lâu, có bao nhiêu lỗi hoặc tốn bao nhiêu nguồn lực.

Có chủ sở hữu quy trình

Một cá nhân hoặc vai trò có thẩm quyền quyết định tiêu chuẩn, phê duyệt thay đổi và chịu trách nhiệm về hiệu quả tổng thể.

Nếu chưa đáp ứng các điều kiện này, tổ chức nên ưu tiên làm rõ quy trình trước khi đầu tư lớn vào tự động hóa.

Chuẩn hóa trước khi tự động hóa không có nghĩa là chuẩn hóa mọi thứ

Một sai lầm phổ biến là cố buộc mọi tình huống đi qua cùng một luồng. Điều này có thể làm quy trình cứng nhắc và loại bỏ những khác biệt có giá trị.

Doanh nghiệp cần phân biệt:

·         Biến thể không cần thiết: Phát sinh vì mỗi người có thói quen riêng, biểu mẫu khác nhau hoặc trách nhiệm chưa rõ

·         Biến thể cần thiết: Phát sinh do loại khách hàng, mức rủi ro, yêu cầu pháp lý hoặc đặc điểm giao dịch khác nhau

·         Ngoại lệ: Trường hợp không nên được xử lý hoàn toàn bằng quy tắc thông thường

Mục tiêu của chuẩn hóa là loại bỏ biến thể không cần thiết, thiết kế quy tắc cho biến thể hợp lệ và tạo điểm chuyển giao phù hợp cho ngoại lệ. Mục tiêu không phải biến mọi công việc thành một chuỗi thao tác máy móc.

Tiêu chuẩn cũng không nên được xem là “cách duy nhất mãi mãi”. Lean Enterprise Institute mô tả công việc tiêu chuẩn hóa như một nền tảng cho cải tiến liên tục: cách làm hiện tại được ghi nhận để bất thường trở nên dễ quan sát và cách làm mới có thể được đánh giá trên cùng một đường cơ sở.

Có trường hợp nào nên tự động hóa trước khi toàn bộ quy trình được chuẩn hóa?

Có. Doanh nghiệp có thể tự động hóa trước một số phần khi toàn bộ quy trình chưa hoàn toàn ổn định, miễn là phạm vi được kiểm soát.

Tự động hóa một tác vụ độc lập và ổn định

Một quy trình đầu cuối có thể còn nhiều biến thể, nhưng một số tác vụ bên trong đã rất rõ ràng, chẳng hạn:

·         Sao chép dữ liệu giữa hai hệ thống

·         Kiểm tra trường bắt buộc

·         Gửi thông báo theo trạng thái

·         Tạo báo cáo định kỳ

·         Đối chiếu các mã định danh

·         Lưu trữ tài liệu theo quy tắc tên thống nhất

Có thể tự động hóa riêng những tác vụ này mà không cần chờ toàn bộ quy trình hoàn thiện.

Dùng công nghệ để quan sát quy trình hiện tại

Process mining, task mining hoặc nhật ký hệ thống có thể được dùng để phát hiện các luồng thực tế, điểm nghẽn và biến thể trước khi xác định tiêu chuẩn cuối cùng.

Trong trường hợp này, công nghệ chưa thay thế quy trình mà hỗ trợ doanh nghiệp hiểu quy trình. Kết quả quan sát sau đó được dùng để lựa chọn luồng cần chuẩn hóa và phạm vi đáng tự động hóa.

Thử nghiệm trong phạm vi nhỏ

Một nhóm có thể triển khai thử trên:

·         Một loại giao dịch

·         Một chi nhánh

·         Một nhóm khách hàng

·         Một sản phẩm

·         Một khoảng giá trị

·         Một luồng có ít ngoại lệ

Pilot cho phép doanh nghiệp kiểm chứng giả định, thu thập dữ liệu và điều chỉnh tiêu chuẩn trước khi mở rộng.

Quy trình cần phản ứng khẩn cấp

Trong một số tình huống, tổ chức cần giảm tải ngay hoặc đáp ứng yêu cầu vận hành cấp bách. Có thể chấp nhận tự động hóa tạm thời nếu:

·         Phạm vi rủi ro được giới hạn

·         Có cơ chế giám sát

·         Kết quả có thể đảo ngược

·         Con người phê duyệt các quyết định quan trọng

·         Giải pháp tạm thời được đánh dấu rõ

·         Có kế hoạch rà soát sau giai đoạn khẩn cấp

Ngoại lệ này không phủ nhận nguyên tắc chuẩn hóa trước. Nó chỉ thay đổi mức chuẩn hóa cần thiết và cách kiểm soát rủi ro.

Cách chuẩn hóa quy trình trước khi tự động hóa

Bước 1: Xác định mục tiêu kinh doanh

Không bắt đầu bằng câu hỏi “công cụ nào có thể tự động hóa quy trình này?”. Hãy bắt đầu bằng vấn đề cần giải quyết:

·         Thời gian xử lý quá dài

·         Chi phí cao

·         Tỷ lệ lỗi lớn

·         Khả năng truy vết thấp

·         Nhân sự dành quá nhiều thời gian cho thao tác lặp lại

·         Khách hàng phải chờ đợi

·         Quy trình không tuân thủ chính sách

Mục tiêu rõ ràng giúp tránh lựa chọn công nghệ chỉ vì nó đang phổ biến.

Bước 2: Quan sát quy trình thực tế

Không nên chỉ dựa vào tài liệu hiện có. Quy trình được mô tả và quy trình thực tế có thể khác nhau.

Cần quan sát người thực hiện, xem dữ liệu hệ thống, phỏng vấn các vai trò liên quan và thu thập các trường hợp ngoại lệ. Mục tiêu là hiểu “công việc đang diễn ra thế nào”, không phải “công việc đáng lẽ phải diễn ra thế nào”.

Bước 3: Lập bản đồ trạng thái hiện tại

Bản đồ nên thể hiện:

·         Điểm bắt đầu và kết thúc

·         Từng bước xử lý

·         Thời gian thực hiện và thời gian chờ

·         Vai trò tham gia

·         Hệ thống được sử dụng

·         Điểm ra quyết định

·         Luồng làm lại

·         Ngoại lệ

·         Dữ liệu đầu vào và đầu ra

Ở bước này, doanh nghiệp thường nhận ra rằng vấn đề không nằm ở tốc độ thao tác mà ở thời gian chờ, chuyển giao hoặc dữ liệu thiếu.

Bước 4: Loại bỏ và đơn giản hóa

Đánh giá từng bước bằng các câu hỏi:

·         Bước này tạo ra giá trị hoặc kiểm soát rủi ro gì?

·         Có thể loại bỏ mà không ảnh hưởng đến đầu ra không?

·         Có thể gộp với bước khác không?

·         Có thể thu thập dữ liệu một lần thay vì nhiều lần không?

·         Có thể giảm số cấp phê duyệt không?

·         Có thể xử lý song song thay vì tuần tự không?

·         Có thể loại bỏ báo cáo không được sử dụng không?

Tự động hóa chỉ nên được xem xét sau khi những bước không cần thiết đã được loại bỏ hoặc có lý do rõ ràng để giữ lại.

Bước 5: Thiết kế quy trình chuẩn

Quy trình tương lai cần xác định:

·         Luồng chính

·         Quy tắc quyết định

·         Vai trò

·         Điểm kiểm soát

·         Dữ liệu chuẩn

·         Thời hạn xử lý

·         Nhánh ngoại lệ

·         Kết quả đầu ra

·         Cách ghi nhận trạng thái

Tài liệu hóa ở mức vừa đủ để người thực hiện, chủ sở hữu quy trình và đội công nghệ hiểu cùng một logic.

Bước 6: Chạy thử bằng phương thức thủ công

Trước khi lập trình, có thể vận hành quy trình chuẩn bằng con người trong một khoảng thời gian hoặc trên một nhóm giao dịch.

Chạy thử giúp xác định:

·         Quy tắc có khả thi không

·         Có bước nào thiếu thông tin không

·         Ngoại lệ nào chưa được nhận diện

·         Trách nhiệm có rõ không

·         Dữ liệu có đáp ứng yêu cầu không

·         Chỉ số có thể thu thập không

Nếu con người vẫn không thể thực hiện quy trình một cách nhất quán, hệ thống cũng khó có thể thực hiện ổn định.

Bước 7: Chọn phạm vi tự động hóa

Ưu tiên các phần có đặc điểm:

·         Khối lượng đủ lớn

·         Lặp lại thường xuyên

·         Quy tắc rõ

·         Dữ liệu số hóa

·         Ít biến thể không kiểm soát

·         Tỷ lệ ngoại lệ chấp nhận được

·         Lợi ích có thể đo

·         Rủi ro có thể kiểm soát

Không nhất thiết tự động hóa toàn bộ quy trình ngay lần đầu.

Bước 8: Thiết kế cơ chế xử lý ngoại lệ

Mọi giải pháp cần trả lời:

·         Khi nào hệ thống phải dừng

·         Ai nhận cảnh báo

·         Dữ liệu nào được chuyển cho người xử lý

·         Người xử lý có thể sửa hoặc tiếp tục từ đâu

·         Kết quả xử lý thủ công có được ghi nhận không

·         Ngoại lệ lặp lại có được đưa vào cải tiến không

Một giải pháp tốt không phải giải pháp không bao giờ gặp ngoại lệ, mà là giải pháp phát hiện và chuyển giao ngoại lệ có kiểm soát.

Bước 9: Đo lường và cải tiến

Sau khi triển khai, so sánh kết quả với đường cơ sở. Không chỉ đo tốc độ mà cần theo dõi cả:

·         Chất lượng

·         Tỷ lệ ngoại lệ

·         Mức can thiệp thủ công

·         Chi phí bảo trì

·         Trải nghiệm người dùng

·         Mức tuân thủ

·         Sự ổn định của hệ thống

Khi quy trình thay đổi, tiêu chuẩn, tài liệu, logic hệ thống và chỉ số kiểm soát phải được cập nhật đồng bộ.

Mô hình phù hợp: ổn định, chuẩn hóa, tự động hóa và cải tiến

Trình tự thực tế không nên được hiểu như một dự án tuyến tính kết thúc sau khi cài đặt phần mềm. Một vòng lặp phù hợp hơn là:

1.    Quan sát và ổn định luồng công việc

2.    Loại bỏ bước không tạo giá trị

3.    Xác lập tiêu chuẩn hiện tại

4.    Tự động hóa phần đủ ổn định

5.    Đo kết quả và ngoại lệ

6.    Cải tiến tiêu chuẩn

7.    Cập nhật hệ thống

8.    Mở rộng phạm vi khi có đủ bằng chứng

Cách tiếp cận này giải quyết được hai rủi ro đối lập:

·         Tự động hóa quá sớm khi quy trình còn hỗn loạn

·         Chờ đợi một quy trình “hoàn hảo” nên không bao giờ triển khai

Lean Enterprise Institute cũng nhấn mạnh trình tự quan sát điều kiện hiện tại, thiết lập tiêu chuẩn ổn định rồi mới cải tiến, bởi tiêu chuẩn tạo ra đường cơ sở để nhận biết thay đổi có thực sự tốt hơn hay không.

Checklist đánh giá một quy trình đã sẵn sàng tự động hóa chưa

Một quy trình có mức sẵn sàng tương đối tốt khi phần lớn câu trả lời dưới đây là “Có”:

·         Mục tiêu kinh doanh đã được xác định

·         Chủ sở hữu quy trình đã được chỉ định

·         Điểm bắt đầu và kết thúc rõ ràng

·         Luồng chính được các bên thống nhất

·         Những bước không cần thiết đã được xem xét loại bỏ

·         Quy tắc quyết định có thể mô tả

·         Đầu vào chủ yếu ở dạng số và có cấu trúc

·         Nguồn dữ liệu đáng tin cậy

·         Vai trò và quyền phê duyệt rõ ràng

·         Ngoại lệ phổ biến đã được nhận diện

·         Có cơ chế chuyển ngoại lệ cho con người

·         Có dữ liệu đường cơ sở

·         Lợi ích kỳ vọng có thể đo lường

·         Rủi ro khi hệ thống xử lý sai đã được đánh giá

·         Quy trình không thay đổi liên tục

·         Có cơ chế quản lý phiên bản và thay đổi

Nếu có nhiều câu trả lời “Không”, giải pháp phù hợp có thể chưa phải tự động hóa toàn bộ. Doanh nghiệp nên chuẩn hóa thêm hoặc chỉ chọn một tác vụ ổn định để thử nghiệm.

Chuẩn hóa trước khi tự động hóa là nguyên tắc giúp doanh nghiệp bảo đảm công nghệ đang khuếch đại một cách làm hợp lý, thay vì khuếch đại sự lãng phí và sai sót.

Điểm quan trọng không phải chờ quy trình hoàn hảo. Doanh nghiệp cần chuẩn hóa đến mức xác định được luồng chính, quy tắc, dữ liệu, trách nhiệm, ngoại lệ và chỉ số đánh giá. Sau đó, có thể tự động hóa theo từng phạm vi nhỏ, giữ con người tại những điểm cần phán đoán và tiếp tục cải tiến dựa trên dữ liệu vận hành.

Một câu hỏi hữu ích trước mỗi dự án là:

Nếu chưa có phần mềm, tổ chức có thể mô tả và thực hiện quy trình này một cách nhất quán hay chưa?

Nếu câu trả lời là chưa, ưu tiên đầu tiên thường không phải lựa chọn công cụ, mà là làm rõ và chuẩn hóa quy trình cần được công cụ thực hiện.