Cách điều chỉnh quy trình khi triển khai công nghệ mới

Vì vậy, điều chỉnh quy trình không nên bắt đầu bằng câu hỏi “đưa phần mềm vào bước nào”, mà bằng việc xác định chức năng mới làm thay đổi đầu vào, hoạt động, quyết định, trách nhiệm, kiểm soát và đầu ra nào. ISO 9001:2015 tiếp cận quy trình như tập hợp các hoạt động liên quan sử dụng đầu vào để tạo kết quả dự kiến, đồng thời nhấn mạnh việc quản lý quan hệ giữa các quy trình và áp dụng tư duy dựa trên rủi ro.

Thiết kế lại quy trình theo chức năng mới thay vì số hóa nguyên trạng

Sai lầm phổ biến khi triển khai công nghệ là giữ nguyên quy trình hiện tại rồi chuyển từng bước lên hệ thống. Cách này có thể số hóa được thao tác nhưng vẫn giữ lại những bước vốn chỉ tồn tại vì giới hạn của phương thức cũ.

Ví dụ, một quy trình trước đây có ba bước: nhân viên nhập yêu cầu, quản lý kiểm tra dữ liệu, sau đó chuyển hồ sơ sang bộ phận khác. Nếu hệ thống mới có thể lấy dữ liệu trực tiếp từ nguồn chuẩn và tự kiểm tra các điều kiện xác định trước, việc giữ nguyên cả ba bước không còn hợp lý. Phần kiểm tra thủ công có thể được loại bỏ hoặc chuyển thành xử lý ngoại lệ.

Mỗi chức năng công nghệ mới nên được đối chiếu với quy trình hiện tại theo sáu khả năng:

·         Loại bỏ bước không còn tạo giá trị

·         Tự động hóa thao tác có quy tắc rõ ràng

·         Gộp các bước không còn cần bàn giao riêng

·         Tách tác vụ nếu công nghệ tạo ra các nhánh xử lý khác nhau

·         Sắp xếp lại thứ tự khi dữ liệu hoặc quyết định có thể xuất hiện sớm hơn

·         Bổ sung bước kiểm soát mới nếu công nghệ tạo thêm rủi ro hoặc quyền truy cập

Điều này không có nghĩa càng tự động hóa nhiều càng tốt. Tác vụ có yêu cầu đánh giá ngữ cảnh, quyết định khó chuẩn hóa hoặc hậu quả sai sót cao vẫn có thể cần sự tham gia của con người. Điểm cần thay đổi là cách phân công công việc giữa hệ thống và con người, không phải mặc định chuyển mọi thao tác cho hệ thống.

Đối chiếu quy trình hiện tại và quy trình mục tiêu để xác định chính xác điểm thay đổi

Trước khi sửa quy trình, doanh nghiệp cần có hai trạng thái rõ ràng: As-Is là cách nghiệp vụ đang vận hành và To-Be là cách nghiệp vụ sẽ vận hành sau khi công nghệ được áp dụng.

Bản đồ As-Is không nên chỉ liệt kê tên các bước. Với từng bước quan trọng, cần xác định ít nhất:

·         Đầu vào được lấy từ đâu

·         Ai thực hiện hoặc ra quyết định

·         Hệ thống nào đang được sử dụng

·         Quy tắc nghiệp vụ nào được áp dụng

·         Dữ liệu nào được tạo hoặc cập nhật

·         Có bàn giao cho đơn vị nào

·         Điểm kiểm soát nằm ở đâu

·         Trường hợp nào phải xử lý ngoại lệ

Sau đó, từng khả năng của công nghệ mới được đặt lên bản đồ này. Nếu hệ thống có thể tự xác thực dữ liệu, điểm kiểm tra thủ công phải được xem xét lại. Nếu hệ thống cung cấp dữ liệu thời gian thực, bước tổng hợp định kỳ có thể không còn cần thiết. Nếu quy trình mới sử dụng workflow tự động, cơ chế chuyển việc giữa các phòng ban cũng phải thay đổi.

Một ma trận tác động có thể ghi nhận cho từng thay đổi: bước hiện tại → chức năng mới → cách xử lý mới → vai trò bị ảnh hưởng → dữ liệu bị ảnh hưởng → kiểm soát cần thay đổi → ngoại lệ cần xử lý. Cách này ngăn tình trạng sửa sơ đồ quy trình nhưng bỏ quên quyền hạn, biểu mẫu, dữ liệu hoặc quy tắc vận hành phía sau.

Quy trình To-Be chỉ nên được chốt khi mỗi thay đổi đều trả lời được ba câu hỏi: bước cũ còn cần không, chức năng mới thay thế phần nào và phần việc còn lại thuộc về ai.

Phân lại trách nhiệm, quyền quyết định và điểm kiểm soát

Khi công nghệ tiếp nhận một phần công việc, trách nhiệm không tự động biến mất. Nó chuyển từ việc thực hiện thao tác sang việc thiết lập quy tắc, giám sát kết quả, xử lý ngoại lệ hoặc chịu trách nhiệm về quyết định.

Ví dụ, khi hệ thống tự phê duyệt các giao dịch đáp ứng một bộ điều kiện, người quản lý có thể không còn kiểm tra từng giao dịch. Tuy nhiên, tổ chức vẫn phải xác định ai có quyền sửa điều kiện phê duyệt, ai theo dõi giao dịch bị từ chối, ai xử lý trường hợp vượt ngưỡng và ai chịu trách nhiệm khi quy tắc cấu hình sai.

Vì vậy, với từng bước To-Be cần phân biệt rõ:

·         Ai sở hữu nghiệp vụ

·         Ai thực hiện công việc còn lại

·         Hệ thống tự động thực hiện phần nào

·         Ai được phép thay đổi quy tắc hoặc cấu hình

·         Ai phê duyệt ngoại lệ

·         Ai giám sát kết quả

·         Ai chịu trách nhiệm cuối cùng

Quyền truy cập cũng phải được điều chỉnh theo vai trò mới. NIST SP 800-171r3 áp dụng nguyên tắc đặc quyền tối thiểu: người dùng hoặc tiến trình chỉ nên có quyền cần thiết cho nhiệm vụ được giao và quyền đã cấp phải được rà soát, điều chỉnh hoặc loại bỏ khi không còn cần thiết. Tài liệu này cũng yêu cầu việc hạn chế quyền liên quan đến thay đổi hệ thống phải được xác định, lập tài liệu, phê duyệt và thực thi.

Do đó, không nên giữ nguyên ma trận phân quyền cũ sau khi quy trình đã thay đổi. Một vai trò không còn nhập dữ liệu không có nghĩa vai trò đó vẫn cần quyền chỉnh sửa dữ liệu; ngược lại, người xử lý ngoại lệ có thể cần một quyền mới mà quy trình cũ chưa tồn tại.

Thiết kế lại luồng dữ liệu, tích hợp và cách xử lý ngoại lệ

Nhiều quy trình sau triển khai công nghệ thất bại không phải vì luồng xử lý chính sai, mà vì dữ liệu và ngoại lệ chưa được thiết kế đầy đủ.

Khi một bước được tự động hóa, cần xác định dữ liệu nào kích hoạt bước đó, nguồn dữ liệu nào được xem là nguồn chuẩn, hệ thống nào được phép cập nhật dữ liệu và điều gì xảy ra khi dữ liệu thiếu, sai hoặc không đồng bộ.

Một quy trình To-Be cần làm rõ:

·         Dữ liệu đầu vào bắt buộc

·         Nguồn dữ liệu chính thức

·         Thời điểm dữ liệu được tạo hoặc cập nhật

·         Hệ thống chịu trách nhiệm lưu bản ghi gốc

·         Quy tắc kiểm tra dữ liệu

·         Cách xử lý khi tích hợp thất bại

·         Cách xử lý dữ liệu trùng, thiếu hoặc mâu thuẫn

·         Cơ chế ghi nhận lịch sử thay đổi

Đặc biệt, happy path không đủ để mô tả quy trình thực tế. Nếu công nghệ chỉ xử lý tốt trường hợp chuẩn nhưng không có nhánh cho lỗi tích hợp, hồ sơ thiếu thông tin, yêu cầu vượt ngưỡng hay quyết định cần can thiệp thủ công, công việc sẽ quay trở lại email, bảng tính hoặc trao đổi ngoài hệ thống.

Ngoại lệ vì thế phải được thiết kế như một phần chính thức của quy trình. Mỗi ngoại lệ cần có điều kiện kích hoạt, người tiếp nhận, thời hạn xử lý, quyền quyết định và cách đưa giao dịch trở lại luồng chuẩn.

Việc thay đổi công nghệ cũng có thể ảnh hưởng trực tiếp đến an toàn và kiểm soát của hệ thống. NIST lưu ý rằng thay đổi phần cứng, phần mềm, firmware hoặc thủ tục vận hành có thể tạo tác động đáng kể tới an ninh; vì vậy việc thay đổi cần được kiểm soát và chỉ những cá nhân phù hợp, được ủy quyền mới được thực hiện.

Thử nghiệm quy trình mới trước khi triển khai trên toàn bộ hoạt động

Kiểm thử phần mềm và kiểm thử quy trình không phải một việc. Phần mềm có thể hoạt động đúng theo đặc tả nhưng quy trình To-Be vẫn không vận hành được trong điều kiện thực tế.

Kiểm thử quy trình cần chạy một giao dịch từ đầu đến cuối qua toàn bộ chuỗi người dùng – hệ thống – dữ liệu – tích hợp – phê duyệt – ngoại lệ – đầu ra. Mục tiêu là xác định liệu cách làm mới có thực sự tạo ra kết quả nghiệp vụ mong muốn hay chỉ làm cho từng chức năng kỹ thuật hoạt động riêng lẻ.

Các tình huống thử nghiệm nên bao gồm cả trường hợp bình thường và trường hợp bất thường:

·         Giao dịch đầy đủ dữ liệu

·         Dữ liệu thiếu hoặc sai định dạng

·         Giao dịch vượt điều kiện thông thường

·         Người có thẩm quyền vắng mặt

·         Tích hợp giữa hai hệ thống bị gián đoạn

·         Người dùng không có quyền phù hợp

·         Quy tắc nghiệp vụ trả về kết quả không xác định

·         Giao dịch cần quay lại bước trước

·         Yêu cầu phải hủy hoặc phục hồi trạng thái

Không có một tỷ lệ pilot hoặc ngưỡng lỗi chung phù hợp cho mọi doanh nghiệp. Phạm vi thử nghiệm phải dựa trên mức độ rủi ro, số lượng nhánh nghiệp vụ, mức độ phụ thuộc hệ thống và hậu quả nếu quy trình mới thất bại.

Đối với thay đổi có ảnh hưởng lớn, triển khai giới hạn theo nhóm người dùng, đơn vị hoặc loại giao dịch giúp kiểm chứng quy trình To-Be trong môi trường thật trước khi mở rộng. Các lỗi phát hiện trong giai đoạn này phải dẫn tới sửa quy trình, cấu hình hoặc trách nhiệm tương ứng, thay vì chỉ đào tạo người dùng cách né lỗi.

Chuẩn hóa quy trình mới và đo hiệu quả sau khi vận hành

Go-live không phải thời điểm kết thúc điều chỉnh quy trình. Chỉ khi có dữ liệu vận hành thực tế mới có thể xác định các giả định trong thiết kế To-Be có đúng hay không.

Quy trình mới cần được chuẩn hóa đồng bộ ở các thành phần liên quan: sơ đồ quy trình, hướng dẫn thao tác, vai trò và quyền hạn, quy tắc nghiệp vụ, biểu mẫu, điểm kiểm soát, cách xử lý ngoại lệ và tài liệu đào tạo. Nếu tài liệu chính thức vẫn mô tả cách làm cũ, tổ chức sẽ tồn tại song song hai quy trình: quy trình trên hệ thống và quy trình mà nhân viên tin rằng họ phải thực hiện.

Hiệu quả sau triển khai nên được đánh giá bằng cách so sánh cùng một chỉ số trước và sau thay đổi. Tùy nghiệp vụ, các chỉ số có thể gồm:

·         Thời gian xử lý từ đầu đến cuối

·         Thời gian chờ giữa các bước

·         Số lần bàn giao

·         Tỷ lệ giao dịch phải xử lý thủ công

·         Tỷ lệ lỗi hoặc phải làm lại

·         Số ngoại lệ

·         Tỷ lệ giao dịch hoàn tất đúng thời hạn

·         Khối lượng giao dịch trên mỗi đơn vị nguồn lực

Không nên đặt một mức cải thiện phần trăm chung cho mọi quy trình. Giá trị cần được so với baseline của chính quy trình trước triển khai và mục tiêu nghiệp vụ đã xác định. Một công nghệ giúp giảm thời gian thao tác nhưng làm tăng lỗi hoặc ngoại lệ chưa chắc tạo ra cải thiện tổng thể.

ISO mô tả cách tiếp cận quy trình theo chu trình Plan–Do–Check–Act: xác định mục tiêu và cách thực hiện, triển khai, theo dõi hoặc đo lường kết quả, sau đó hành động để cải thiện. Vì vậy, sau go-live cần có chu kỳ rà soát để loại tiếp các bước không còn cần thiết, điều chỉnh quy tắc tự động và cập nhật điểm kiểm soát khi dữ liệu vận hành cho thấy quy trình thực tế khác thiết kế ban đầu.

Điều chỉnh quy trình khi triển khai công nghệ không phải là sửa một vài bước để “khớp phần mềm”. Công việc cốt lõi là thiết kế lại cách nghiệp vụ vận hành dựa trên chức năng mới: xác định bước nào biến mất hoặc thay đổi, phân lại việc giữa con người và hệ thống, thiết kế quyền quyết định, tổ chức lại dữ liệu và kiểm soát, chuẩn hóa ngoại lệ rồi kiểm chứng bằng vận hành thực tế.

Một quy trình mới chỉ thực sự phù hợp khi công nghệ, trách nhiệm, dữ liệu và kiểm soát cùng vận hành theo một logic thống nhất. Nếu chỉ thay công cụ mà giữ nguyên cách làm cũ, tổ chức có thể có một hệ thống mới nhưng vẫn vận hành bằng quy trình cũ; ngược lại, khi quy trình được thiết kế theo đúng khả năng và giới hạn của công nghệ, thay đổi mới có thể chuyển thành cải thiện vận hành có thể đo lường và duy trì.