Cách đánh giá quy trình trước khi số hóa

Đánh giá quy trình trước khi số hóa là hoạt động kiểm tra có hệ thống nhằm xác định quy trình có rõ mục tiêu, đủ ổn định, có thể chuẩn hóa, đo lường và kiểm soát hay chưa. Kết quả đánh giá không chỉ trả lời câu hỏi “có nên đưa quy trình lên phần mềm không”, mà còn chỉ ra phần nào cần giữ nguyên, phần nào cần cải tiến, phần nào cần tự động hóa và phần nào vẫn phải do con người xử lý.

Một quy trình đủ điều kiện số hóa thường phải vượt qua năm yêu cầu cốt lõi:

·         Có mục tiêu và đầu ra xác định

·         Có trình tự xử lý rõ ràng

·         Có vai trò và trách nhiệm cụ thể

·         Có dữ liệu đầu vào đủ tin cậy

·         Có quy tắc xử lý ngoại lệ và tiêu chí đo lường

Vì sao phải đánh giá quy trình trước khi số hóa?

Số hóa không tự động tạo ra một quy trình tốt. Phần mềm chỉ thực thi logic đã được thiết kế hoặc cấu hình. Nếu logic ban đầu thiếu rõ ràng, hệ thống sẽ tiếp tục tái tạo sự thiếu rõ ràng đó dưới một hình thức khó thay đổi hơn.

Ví dụ, một quy trình phê duyệt có năm cấp ký nhưng không ai giải thích được giá trị kiểm soát của từng cấp. Nếu đưa nguyên trạng lên phần mềm, doanh nghiệp có thể rút ngắn thời gian chuyển hồ sơ giữa các cấp nhưng vẫn giữ nguyên năm lần chờ duyệt. Vấn đề cốt lõi không nằm ở tốc độ luân chuyển tài liệu mà ở cấu trúc phê duyệt.

Đánh giá trước khi triển khai phần mềm giúp hạn chế bốn nhóm rủi ro chính:

·         Số hóa các bước không tạo giá trị

·         Cấu hình sai vai trò hoặc thẩm quyền

·         Tạo hệ thống quá cứng trước các tình huống ngoại lệ

·         Đầu tư vào chức năng không giải quyết được điểm nghẽn thực tế

Chi phí sửa một quy trình trên sơ đồ thường thấp hơn nhiều so với sửa quy trình sau khi đã cấu hình biểu mẫu, phân quyền, luồng phê duyệt, tích hợp dữ liệu và đào tạo người dùng.

Bước 1: Xác định mục tiêu và phạm vi của quy trình

Trước khi phân tích từng thao tác, cần xác định quy trình tồn tại để tạo ra kết quả gì. Nếu không có đầu ra rõ ràng, rất khó kết luận bước nào cần thiết hoặc bước nào có thể loại bỏ.

Một phạm vi quy trình đầy đủ cần trả lời được:

·         Sự kiện nào kích hoạt quy trình

·         Quy trình bắt đầu tại bước nào

·         Kết quả cuối cùng cần tạo ra là gì

·         Quy trình kết thúc khi điều kiện nào được đáp ứng

·         Bộ phận hoặc đối tượng nào tham gia

·         Trường hợp nào không thuộc phạm vi quy trình

Ví dụ, với quy trình mua hàng, “nhận được hàng” chưa chắc là điểm kết thúc. Quy trình có thể chỉ hoàn tất khi hàng đã được kiểm tra, chứng từ được đối chiếu và nghĩa vụ thanh toán được ghi nhận.

Ranh giới không rõ sẽ dẫn đến việc các nhóm dự án hiểu khác nhau về cùng một quy trình. Hệ quả là phần mềm có thể bỏ sót một đoạn xử lý quan trọng hoặc cấu hình trùng chức năng giữa nhiều phân hệ.

Bước 2: Mô tả quy trình đang vận hành trên thực tế

Không nên chỉ dựa vào quy định, quy chế hoặc tài liệu quy trình hiện có. Quy trình trên giấy thường thể hiện cách công việc được kỳ vọng sẽ diễn ra, trong khi người dùng thực tế có thể đang áp dụng nhiều bước bổ sung, đường tắt hoặc phương án xử lý không được ghi nhận.

Quy trình hiện trạng cần được mô tả theo chuỗi:

1.    Đầu vào

2.    Hoạt động xử lý

3.    Người hoặc bộ phận thực hiện

4.    Quyết định được đưa ra

5.    Dữ liệu được tạo hoặc cập nhật

6.    Điểm bàn giao

7.    Đầu ra

Có thể thu thập hiện trạng thông qua phỏng vấn, quan sát thao tác, kiểm tra hồ sơ, phân tích email, biểu mẫu, bảng tính và dữ liệu thời gian xử lý.

Khi mô tả, cần phân biệt ba loại thông tin:

·         Quy trình chính thức được quy định

·         Quy trình thực tế đang được thực hiện

·         Quy trình mong muốn sau cải tiến

Trộn lẫn ba trạng thái này sẽ khiến nhóm dự án không biết mình đang số hóa hiện trạng hay đang thiết kế một quy trình mới.

Bước 3: Kiểm tra giá trị của từng bước

Mỗi bước trong quy trình cần được kiểm tra bằng câu hỏi: bước này tạo ra giá trị gì cho đầu ra, khách hàng hoặc hoạt động kiểm soát?

Một bước có thể được giữ lại khi nó thực hiện ít nhất một chức năng cần thiết:

·         Tạo hoặc biến đổi đầu ra

·         Kiểm tra chất lượng

·         Kiểm soát rủi ro

·         Đáp ứng yêu cầu pháp lý hoặc quản trị

·         Cung cấp thông tin cần thiết cho bước tiếp theo

Các bước thường cần xem xét lại gồm:

·         Nhập lại dữ liệu đã tồn tại ở hệ thống khác

·         Chuyển tiếp hồ sơ mà không xử lý

·         Xin nhiều chữ ký cho cùng một mục đích

·         Kiểm tra lặp lại cùng một thông tin

·         Lập báo cáo thủ công từ dữ liệu đã có

·         Chờ xử lý nhưng không có điều kiện ưu tiên

·         Sao chép dữ liệu giữa nhiều bảng tính

Không phải mọi bước không tạo giá trị trực tiếp đều cần loại bỏ. Một bước kiểm soát có thể không làm thay đổi sản phẩm hoặc dịch vụ nhưng vẫn cần thiết để hạn chế sai sót. Điều quan trọng là phải xác định rõ rủi ro mà bước kiểm soát đó đang xử lý.

Bước 4: Phát hiện điểm nghẽn và nguyên nhân gốc

Điểm nghẽn là vị trí làm giảm năng lực xử lý của toàn bộ quy trình. Nó có thể xuất hiện dưới dạng tồn đọng hồ sơ, thời gian chờ kéo dài, tỷ lệ sửa lại cao hoặc phụ thuộc vào một cá nhân.

Cần đo tối thiểu các chỉ số sau nếu dữ liệu cho phép:

·         Tổng thời gian từ khi bắt đầu đến khi kết thúc

·         Thời gian xử lý thực tế

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

·         Số lần bàn giao

·         Số lần hồ sơ bị trả lại

·         Tỷ lệ sai sót

·         Số lượng hồ sơ tồn đọng

·         Khối lượng công việc theo từng vai trò

Không nên mặc định mọi điểm chậm đều cần tự động hóa. Một bước phê duyệt chậm có thể xuất phát từ hồ sơ đầu vào thiếu thông tin, trách nhiệm không rõ hoặc người phê duyệt không nhận được tiêu chí ra quyết định.

Phần mềm chỉ giải quyết tốt điểm nghẽn khi nguyên nhân nằm ở thao tác lặp lại, luân chuyển thông tin, tổng hợp dữ liệu, theo dõi trạng thái hoặc kiểm tra theo quy tắc. Nếu nguyên nhân là xung đột trách nhiệm, thiếu năng lực hoặc chính sách chưa rõ, doanh nghiệp cần xử lý vấn đề quản trị trước.

Bước 5: Đánh giá mức độ chuẩn hóa

Phần mềm vận hành hiệu quả khi các trường hợp giống nhau được xử lý theo cùng một logic. Vì vậy, cần kiểm tra mức độ thống nhất của quy trình giữa các cá nhân, phòng ban, chi nhánh hoặc nhóm sản phẩm.

Một quy trình có khả năng chuẩn hóa tốt khi:

·         Các bước chính được thực hiện nhất quán

·         Tiêu chí ra quyết định có thể mô tả rõ

·         Biểu mẫu và dữ liệu đầu vào thống nhất

·         Vai trò không thay đổi tùy từng hồ sơ

·         Ngoại lệ chiếm tỷ lệ hợp lý và có thể phân loại

·         Kết quả xử lý có thể kiểm tra

Các dấu hiệu cho thấy quy trình chưa ổn định gồm:

·         Mỗi nhân viên thực hiện theo một cách khác nhau

·         Quyết định phụ thuộc chủ yếu vào kinh nghiệm cá nhân

·         Nhiều quy tắc chỉ được truyền miệng

·         Biểu mẫu thay đổi liên tục

·         Quy trình thường xuyên bị bỏ qua

·         Không thống nhất được ai có quyền quyết định

Trong trường hợp này, triển khai phần mềm quá sớm có thể tạo ra nhiều yêu cầu tùy chỉnh. Hệ thống càng tùy chỉnh sâu, chi phí bảo trì và thay đổi về sau càng lớn.

Bước 6: Kiểm tra vai trò, trách nhiệm và quyền quyết định

Mỗi hoạt động cần có một chủ thể chịu trách nhiệm rõ ràng. Nếu một bước có nhiều người cùng chịu trách nhiệm nhưng không ai chịu trách nhiệm cuối cùng, phần mềm khó xác định người nhận việc, thời hạn xử lý và cơ chế nhắc việc.

Cần làm rõ:

·         Ai thực hiện

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

·         Ai có quyền phê duyệt

·         Ai cần được tham vấn

·         Ai cần được thông báo

·         Ai được quyền thay thế khi người phụ trách vắng mặt

Đặc biệt, phải tách biệt ba khái niệm thường bị nhầm lẫn:

·         Người nhập hoặc chuẩn bị dữ liệu

·         Người kiểm tra tính hợp lệ

·         Người đưa ra quyết định

Việc tách vai trò giúp xây dựng phân quyền phù hợp và hạn chế một cá nhân tự tạo, tự kiểm tra rồi tự phê duyệt cùng một giao dịch.

Tuy nhiên, không nên tạo quá nhiều vai trò chỉ để mô phỏng cơ cấu tổ chức. Vai trò trên phần mềm cần phản ánh trách nhiệm trong quy trình, không nhất thiết phản ánh toàn bộ chức danh hành chính.

Bước 7: Đánh giá dữ liệu đầu vào và đầu ra

Một quy trình không thể vận hành ổn định trên phần mềm nếu dữ liệu đầu vào thiếu, sai, không thống nhất hoặc không có nguồn xác định.

Với mỗi trường dữ liệu quan trọng, cần làm rõ:

·         Dữ liệu được tạo ở đâu

·         Ai chịu trách nhiệm nhập hoặc xác nhận

·         Định dạng dữ liệu là gì

·         Trường nào bắt buộc

·         Quy tắc kiểm tra hợp lệ là gì

·         Dữ liệu đã tồn tại ở hệ thống nào

·         Dữ liệu được sử dụng ở bước nào

·         Dữ liệu cần lưu trong bao lâu

Không nên yêu cầu người dùng nhập lại thông tin mà hệ thống có thể lấy từ nguồn đáng tin cậy khác. Tuy nhiên, việc tích hợp chỉ có ý nghĩa khi đã xác định được nguồn dữ liệu chuẩn và quyền sở hữu dữ liệu.

Dữ liệu đầu ra cũng cần được định nghĩa cụ thể. Thay vì yêu cầu chung chung như “cần báo cáo đầy đủ”, nên xác định rõ báo cáo phục vụ quyết định nào, ai sử dụng, sử dụng khi nào và cần các chỉ số nào.

Bước 8: Phân loại quy tắc và điểm ra quyết định

Mọi nhánh rẽ trong quy trình cần được chuyển thành điều kiện có thể hiểu và kiểm tra. Những mô tả như “trường hợp quan trọng”, “khi cần thiết” hoặc “tùy tình hình” chưa đủ để cấu hình phần mềm.

Mỗi điểm quyết định nên trả lời được:

·         Thông tin nào được sử dụng

·         Điều kiện nào dẫn đến từng kết quả

·         Ai có quyền quyết định

·         Quyết định có cần lưu lý do không

·         Có trường hợp ghi đè quy tắc hay không

·         Ai được quyền ghi đè

·         Quyết định ảnh hưởng đến bước tiếp theo thế nào

Có thể chia quy tắc thành ba nhóm:

Quy tắc có thể tự động hóa

Đây là những điều kiện rõ ràng, lặp lại và có dữ liệu đầu vào đáng tin cậy. Ví dụ, tự động chuyển hồ sơ đến cấp phê duyệt tương ứng theo giá trị giao dịch.

Quy tắc hỗ trợ quyết định

Hệ thống có thể tổng hợp dữ liệu, cảnh báo hoặc đề xuất, nhưng con người vẫn đưa ra quyết định cuối cùng. Nhóm này phù hợp với các tình huống cần đánh giá chuyên môn.

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

Đây là những quyết định phụ thuộc vào bối cảnh, thương lượng, đạo đức nghề nghiệp hoặc thông tin khó cấu trúc. Không nên ép toàn bộ nhóm này thành quy tắc cứng chỉ để đạt mục tiêu tự động hóa.

Bước 9: Nhận diện và thiết kế cách xử lý ngoại lệ

Quy trình trên sơ đồ thường mô tả trường hợp thuận lợi, trong khi phần lớn khó khăn khi triển khai phần mềm lại nằm ở ngoại lệ.

Ngoại lệ có thể bao gồm:

·         Thiếu dữ liệu bắt buộc

·         Hồ sơ không đạt điều kiện

·         Người phê duyệt vắng mặt

·         Giao dịch vượt thẩm quyền

·         Hệ thống tích hợp không phản hồi

·         Yêu cầu cần xử lý khẩn cấp

·         Hồ sơ bị hủy hoặc thu hồi

·         Quyết định cần được điều chỉnh sau phê duyệt

Với mỗi ngoại lệ, cần xác định:

·         Cách phát hiện

·         Người chịu trách nhiệm xử lý

·         Thời gian xử lý

·         Cách quay lại quy trình chính

·         Dữ liệu cần lưu để truy vết

·         Trường hợp cần báo cáo hoặc cảnh báo

Không nên thiết kế một nhánh riêng cho mọi tình huống hiếm gặp. Quá nhiều nhánh sẽ làm quy trình phức tạp và khó bảo trì. Các ngoại lệ tương tự nên được gom thành nhóm và xử lý bằng một cơ chế chung khi có thể.

Bước 10: Xác định chỉ số đánh giá quy trình

Nếu không có chỉ số trước khi số hóa, doanh nghiệp sẽ khó chứng minh phần mềm có cải thiện quy trình hay không.

Chỉ số nên phản ánh ít nhất bốn khía cạnh:

Thời gian

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

·         Thời gian chờ

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

Chất lượng

·         Tỷ lệ sai sót

·         Tỷ lệ hồ sơ phải sửa hoặc bổ sung

·         Tỷ lệ kết quả đạt yêu cầu ngay lần đầu

Năng suất

·         Số hồ sơ xử lý trên mỗi nhân sự

·         Số thao tác thủ công trên mỗi hồ sơ

·         Khối lượng tồn đọng

Kiểm soát

·         Tỷ lệ hồ sơ có đủ dấu vết phê duyệt

·         Số trường hợp vượt thời hạn

·         Số ngoại lệ phát sinh

·         Tỷ lệ tuân thủ quy trình

Cần ghi nhận số liệu hiện trạng làm đường cơ sở trước khi triển khai. Sau khi phần mềm đi vào vận hành, kết quả mới có thể được so sánh với cùng một định nghĩa và cùng một phạm vi đo.

Bước 11: Đánh giá mức độ phù hợp để tự động hóa

Không phải toàn bộ quy trình đều cần được tự động hóa ở cùng một mức độ. Có thể phân chia từng hoạt động theo bốn hướng xử lý:

1.    Loại bỏ

2.    Đơn giản hóa

3.    Chuẩn hóa

4.    Tự động hóa

Thứ tự này rất quan trọng. Không nên tự động hóa một bước có thể loại bỏ, cũng không nên cấu hình một bước chưa được chuẩn hóa.

Một hoạt động có tiềm năng tự động hóa cao khi:

·         Có tần suất lặp lại lớn

·         Sử dụng dữ liệu có cấu trúc

·         Có quy tắc xử lý rõ ràng

·         Ít phụ thuộc vào phán đoán

·         Kết quả có thể kiểm tra

·         Khối lượng công việc đủ để tạo lợi ích

·         Sai sót thủ công đang gây hậu quả đáng kể

Ngược lại, một hoạt động cần cân nhắc giữ con người trong vòng xử lý khi:

·         Quyết định phụ thuộc nhiều vào bối cảnh

·         Dữ liệu đầu vào không đầy đủ

·         Ngoại lệ xuất hiện thường xuyên

·         Hậu quả của quyết định sai rất lớn

·         Cần giải thích, thương lượng hoặc chịu trách nhiệm chuyên môn

Bước 12: Chấm điểm mức sẵn sàng số hóa

Doanh nghiệp có thể sử dụng thang điểm từ 0 đến 2 cho từng tiêu chí:

·         0 điểm: Chưa xác định hoặc không đáp ứng

·         1 điểm: Đã có nhưng chưa đầy đủ hoặc chưa ổn định

·         2 điểm: Đã rõ ràng, thống nhất và có thể kiểm chứng

Bảng tiêu chí đánh giá

Với 12 tiêu chí, tổng điểm tối đa là 24. Có thể diễn giải kết quả như sau:

·         Từ 20 đến 24 điểm: Có mức sẵn sàng cao, có thể chuyển sang thiết kế giải pháp và thử nghiệm

·         Từ 14 đến 19 điểm: Có thể số hóa một phần nhưng cần xử lý các khoảng trống quan trọng

·         Dưới 14 điểm: Chưa nên cấu hình toàn bộ quy trình, cần ưu tiên chuẩn hóa và cải tiến

Điểm số chỉ là công cụ hỗ trợ thảo luận, không phải quyết định tự động. Một quy trình có tổng điểm cao nhưng thiếu kiểm soát ở một khâu có rủi ro nghiêm trọng vẫn chưa nên triển khai.

Bước 13: Kiểm tra quy trình bằng tình huống thực tế

Trước khi cấu hình chính thức, cần chạy thử quy trình bằng các hồ sơ đại diện. Không nên chỉ kiểm tra trường hợp thuận lợi.

Bộ tình huống tối thiểu nên bao gồm:

·         Một trường hợp thông thường

·         Một trường hợp thiếu dữ liệu

·         Một trường hợp bị từ chối

·         Một trường hợp vượt thẩm quyền

·         Một trường hợp cần xử lý khẩn cấp

·         Một trường hợp bị hủy giữa chừng

·         Một trường hợp người phụ trách vắng mặt

·         Một trường hợp hệ thống liên quan không phản hồi

Mỗi tình huống cần được đi từ đầu đến cuối để kiểm tra:

·         Quy trình có xác định được bước tiếp theo không

·         Vai trò có biết mình phải làm gì không

·         Dữ liệu có đủ để ra quyết định không

·         Ngoại lệ có đường xử lý và điểm quay lại không

·         Kết quả có được lưu vết đầy đủ không

Nếu nhóm thực hiện phải giải thích bằng câu “trường hợp này thường sẽ hỏi người có kinh nghiệm”, đó là dấu hiệu tri thức vận hành chưa được chuyển thành quy tắc hoặc hướng dẫn rõ ràng.

Khi nào quy trình đủ điều kiện đưa lên phần mềm?

Một quy trình có thể chuyển sang giai đoạn thiết kế phần mềm khi đáp ứng đồng thời các điều kiện chính:

·         Mục tiêu, phạm vi và đầu ra đã thống nhất

·         Các bước chính đã được mô tả theo hiện trạng và trạng thái mong muốn

·         Bước thừa và điểm nghẽn quan trọng đã được xử lý

·         Vai trò, trách nhiệm và quyền quyết định đã rõ

·         Dữ liệu đầu vào có nguồn và quy tắc kiểm tra

·         Các quy tắc chính có thể diễn đạt thành điều kiện

·         Ngoại lệ quan trọng có phương án xử lý

·         Chỉ số đánh giá trước và sau triển khai đã được xác định

·         Người sở hữu quy trình đã phê duyệt phiên bản mục tiêu

·         Quy trình đã được kiểm tra bằng các tình huống đại diện

Sẵn sàng số hóa không có nghĩa là quy trình phải hoàn hảo hoặc không còn ngoại lệ. Điều cần thiết là quy trình phải đủ rõ để nhóm nghiệp vụ và nhóm triển khai phần mềm có cùng cách hiểu về mục tiêu, luồng xử lý, dữ liệu, trách nhiệm và giới hạn tự động hóa.

Đánh giá quy trình trước khi số hóa cần bắt đầu từ bản chất công việc, không bắt đầu từ danh sách tính năng của phần mềm. Doanh nghiệp nên xác định mục tiêu, quan sát hiện trạng, loại bỏ bước không cần thiết, chuẩn hóa dữ liệu, làm rõ trách nhiệm và kiểm tra ngoại lệ trước khi cấu hình hệ thống.

Nguyên tắc quan trọng nhất là: loại bỏ trước, đơn giản hóa sau, chuẩn hóa tiếp theo và chỉ tự động hóa khi logic đã đủ rõ. Cách tiếp cận này giúp phần mềm giải quyết đúng vấn đề, giảm tùy chỉnh không cần thiết và tạo cơ sở đo lường hiệu quả sau triển khai.